Porteus

Please test the alpha of the gui for usm. It is very basic (not pretty yet) but has the functionality for getting packages and some porteus module tools. Please give feedback on the usability and aesthetics of the gui so i can improve it. Many parts simply call the CLI version and display an embedded terminal. I will change this for some parts such as updates but it will remain as an embedded terminal for the process of resolving dependencies.

The CLI and GUI will eventually be rewritten as one single script with optimized code.

You will require the CLI version to be in place before activating and running this module. Thanks.

https://dl.dropboxusercontent.com/u/686 ... arch-1.xzm

"CLI and GUI will eventually be rewritten as one single script" Ewww, bad idea. Optimized code, yes.

Ewww, bad idea.

Can you qualify this please? I've already started so now is the time speak up.

Part of optimizing the code IS creating one script. Both the CLI and GUI will call the same functions instead of having to write them twice. This makes internationalization much easier to as translators work less. Lastly it gives me one script to maintain instead of two. Please point out the cons, there are bound to be some i havn't thought of.

try this with gui :
search bind --> ok
download bind-9;9;4 and idnkit --> done
then I get ":" and a blinking cursor
have to clic Return button to continue testing

This is the intended behavior. It simply opens a terminal and runs the CLI version to download the packages. Unfortunately I havn't found a way to return to the original screen once the terminal has finished it's job, hence the return button.

Do you think it is not very intuitive?

ok
I was very happy to have tried and understood the cli version before
thinks an option should be so that after downloading the call to create xzm be a following choice
rather to clic on tool button

Thanks bour59, I will add a dialog to ask if modules should be created after download.

I am working on removing the terminal from the GUI. I wasn't quite comfortable with having it there but it saved a lot of extra coding. I've decided to do the extra coding and show the user a real GUI instead of the console. This will also solve a few other issues. It will take a little more time, but will be more usable. Since there has been no elaboration on why merging a CLI and GUI script into one usable script is a bad idea, I have continued and found it to be quite usable. The script will sense if it is being run directly or via a menu item and will react accordingly. When the CLI is run directly then only the code for the CLI will run. Nothing will be exported for the GUI as it is all skipped using 'if' clauses.

Another benefit is it allows me to export less text to .po files for i18n usage. I will also be able to upload source code to a version tracker such as git and users can test latest versions by pulling from git and building with 'make install' which will support DESTDIR if you prefer to make a module. In simpler words, it will be more efficient, manageable and prettier.

Still havn't solved how i can automate the updating of repositories, but that can come later. In the future if anyone is interested in maintaining a 'slackware type' repository for porteus that would be great. I would expect to see all the packages that don't exist in the repos that USM already uses. The maintainer would have to maintain for both 64 and 32 bit and be familiar with slackware packages and how to create them. If we can start to hand out tasks to the community it will help take a load off.

Excuse me for my slow response.

1.[gtkusm]: 'alt+character'
I tried change for using same English character.

example:
"_'$(gettext "Tools")'"
-->
"'$(gettext "_Tools")'"

.po
msgid "Tools"
msgstr "ツール"
-->
msgid "_Tools"
msgstr "ツール(_T)"

2.[usm]: bold
Bold characters do not be displayed on the terminal window of 'gtkusm'.
I tried change following.

#====[usm]====
28,33c28,33
< txtbld=$(tput bold) # Bold
< txtred=$(tput setaf 1)${txtbld} # Red
< txtgreen=$(tput setaf 2)${txtbld} # green
< txtblue=$(tput setaf 4)${txtbld} # blue
< txtpink=$(tput setaf 5)${txtbld} # pink
< txtcyan=$(tput setaf 6)${txtbld} # cyan
---
> txtbld=$(tput setaf 6) #$(tput bold) # Bold
> txtred=$(tput setaf 1) #${txtbld} # Red
> txtgreen=$(tput setaf 2) #${txtbld} # green
> txtblue=$(tput setaf 4) #${txtbld} # blue
> txtpink=$(tput setaf 5) #${txtbld} # pink
> txtcyan=$(tput setaf 6) #${txtbld} # cyan
#=============

3.[usm],[gtkusm]: export TEXTDOMAIN=usm; export TEXTDOMAIN=gtkusm
I do not know well how to set environment variabl TEXTDOMAIN value of "usm" for usm program and "gtkusm" for gtkusm program at same time.
I tried the most easy following way.

#====[usm]====
2c2
<
---
> export TEXTDOMAIN=usm
#=============

#====[gtkusm]====
2c2
<
---
> export TEXTDOMAIN=gtkusm
#=============

4.[gtkusm]: gtkusm.po
Japanese po for gtkusm
md5sum: 5b71601f3d08baf0647f22d97c0d7970 gtkusm.po
http://www.mediafire.com/download/sam2p ... /gtkusm.po

5.[usm]: usm.po
update Japanese po for usm
md5sum: cf6659da5667b14ebb7e3649f9698e9b usm.po
http://www.mediafire.com/download/v35ij ... 9y4/usm.po

Where does one get the usm gui?

@francois
I use this one :
by brokenman » 20 Feb 2014, 02:56
https://dl.dropboxusercontent.com/u/686 ... arch-1.xzm

Thanks.

Great work, indeed

BUGS, I found that the 'usm -g <whatever-having-dashes-in-package-name>' fails to find and, or fetch package; though search is working fine.

OTOH, the formatting/indentation in shell script usm is very poor

BTW, would you mind I submit a patch after proper formatting/indentation; all tabs converted to 2 or 4 spaces. What do you suggest?

Thanks people. Please hold off on any patching or translating for now. I am in the process of rewriting to integrate the CLI/GUI (and am taking care of indentation bdheeman) which means a substantial code change. I copied and pasted many of my previous functions into the script hence the bad formatting.

@brokenman

I expect your new integrated 'usm'.
Thanks.