MintPup (Trusty LTS)

A home for all kinds of Puppy related projects
Post Reply
Message
Author
mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#106 Post by mcewanw »

EDIT: But I do think it is good to have a menu that can be generated from desktop files, rather than just the debian method. BaCon syntax looks relatively easy (compared to bash even).

I haven't tried this (yet), since I am no longer familiar with BASIC (like alone BaCon) but after a quick look at the syntax I think 'something' like the following modification to mk-jwm.main.bac should add the xterm -e only when specified in desktop file. The only change (2 or 3 lines of code) is the use of variable termi$ and an extra CASE followed by concatenation in exe$. Most of the following is identical to original lines 35 onwards in the source:

Code: Select all

												'#####  LOOP:  Make raw menu.
FOR i = 0 TO DtSz-1
	name$ = "" : genname$ = ""
	exe$ = "" : ico$ = "" : cat$ = "" : termi$ = ""

	'###	This assumes the "Exec=" line has ONLY [/path/]file, no extra crap.
	OPEN DT$[i] FOR READING AS file_
		WHILE NOT(ENDFILE(file_)) DO
			IF ENDFILE(file_) THEN BREAK
			READLN txt$ FROM file_
			sep = INSTR(txt$, "=")
			Var$ = MID$(txt$, sep+1)

			SELECT LEFT$(txt$, sep)
				CASE "Name=" : name$ = Var$
				CASE "GenericName=" : genname$ = Var$
				CASE "Terminal=" : IF Var$ = "true" THEN termi$ = "xterm -e "
				CASE "Exec="
					exe$ = termi$ & Var$
					termi$ = ""
				CASE "Icon=" : ico$ = Var$
But at this exact moment I have never even tried compiling BaCon program...

Also, the hard-coded 'xterm -e' above wouldn't be the best either.

If I can get it working I'll let you know anyway.

William

EDIT2: I'm sure Terry could fix this in ten seconds...
EDIT3: I note that /usr/share/applications dir is hardcoded in existing implementation.
EDIT4: Instead of hardcoding xterm -e above should, if possible, use default terminal command really (in case some other terminal rather than xterm is installed). That may be tricky though since other terminals may use different option that -e to run executables.
Last edited by mcewanw on Fri 21 Aug 2015, 00:14, edited 2 times in total.
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#107 Post by mcewanw »

Hi again Toni,

I see it is all pretty complicated and note that the program /usr/bin/mjwm is an executable for creating JWM menu from desktop files by Chirantan Mitra. Is there a problem with that method that made it better to invent a new wheel (method)?

EDIT: From what you said, I presume Terry's scripts end up being faster at generating a suitable menu? Might be worth trying to develop them if so (particularly since the core of it all seems to be that one script of only around 170 lines of code total - mk-jwm.main.bac).

William
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#108 Post by saintless »

Hi William.
mcewanw wrote:EDIT: But I do think it is good to have a menu that can be generated from desktop files, rather than just the debian method.
I don't see problem using the official debian update-menus method and it is the only working method if you change Jwm with IceWM. For example rox-filer package in ubuntu doesn't include .desktop file but only /usr/share/menu file.
BTW my vote was for the official debian method from the start and I don't care if it doesn't support main categories different icons or adds more sub-menus. It is well tested over the years and supports localization.
Also, the hard-coded 'xterm -e' above wouldn't be the best either.
It is not solution in my opinion. we have one more script from Terry for converting /usr/share/menu files in /usr/share/applications desktop files and it was auto-running in first DD-Jwm versions but didn't work well using apt-get upgrade command and some desktop files were removed while updating the menus. I don't think adding option to auto-edit desktop files adding "xterm -e" is good idea. We have menumaker and desktop-file-editor for this.
mcewanw wrote:I see it is all pretty complicated and note that the program /usr/bin/mjwm is an executable for creating JWM menu from desktop files by Chirantan Mitra. Is there a problem with that method that made it better to invent a new wheel (method)?
Click System - Menu-MJWM and you have it as default menu.
I added this menu system because it reads the files in ~/.local/share/applications
It generates the menu much slower (test and you will see the difference).
I'm not sure if it reads "Terminal=true" line. Didn't make such test and I already had "xterm -e" in some desktop files.
EDIT: From what you said, I presume Terry's scripts end up being faster at generating a suitable menu? Might be worth trying to develop them if so (particularly since the core of it all seems to be that one script of only around 170 lines of code total - mk-jwm.main.bac).
If you like to try you are welcome. But it will need much testing after any change to confirm the menu system works well.
Also both methods (Terry's and Mitra's) don't support changing localization for the main menu categories (as all special DD scripts don't support localization changes).

I prefer to keep the menu system as it is. If I have to test again the menu systems after making changes I prefer to restore the official debian update-menus method and remove all others.

If you or anyone else likes to change and improve Terry's script and test properly the changes (especially with apt-get upgrade and apt-get dist-upgrade) we can update the repository with new deb package anytime.

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#109 Post by mcewanw »

saintless wrote: I don't think adding option to auto-edit desktop files adding "xterm -e" is good idea. We have menumaker and desktop-file-editor for this.
Hi Toni,

Actually, what I was proposing was to not modify the desktop files at all (then openbox menu should work properly) - by which I mean: not having the added xterm -e in the desktop file itself but instead having the menu generator script detecting "Terminal=true" and more correctly (I feel) having the jwm menu generating program adding xterm -e to the jwm menu itself. But I confess to not having studied the (Terry-version) menu system sufficiently to see if that part is as simple as it seems to me on first glance.

Anyway, I don't myself like debian standard menu, so I might give modification a go, since that change 'seems' to be a tiny one (yes, I understand how tricky the menu generating has been...).

Not so easy maybe to include search for desktop files in other locations (though, I'm hopeful, maybe just a couple of lines of extra code to include $HOME/.local/share/applications - I'm not sure). I'll let you know if I come up with anything that works but otherwise I'm also happy with how things are anyway.

William
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#110 Post by saintless »

mcewanw wrote:Actually, what I was proposing was to not modify the desktop files at all (then openbox menu should work properly) - by which I mean: not having the added xterm -e in the desktop file itself but instead having the menu generator script detecting "Terminal=true" and more correctly (I feel) having the jwm menu generating program adding xterm -e to the jwm menu itself.
Sorry, William, my mistake. Looks better this way.

If you decide to work on this here is the deb package with Terry's menu system:
http://www.smokey01.com/saintless/Debia ... 1_i386.deb
And depending on the above package here is Mitra's mjwm menu system:
http://www.smokey01.com/saintless/Debia ... 1_i386.deb
All DD-Jwm and MintPup have the same packages installed.
It will be easier to explore the content of the debs instead searching the files inside the system.

Toni

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#111 Post by mcewanw »

Hi Toni,

I went to the BaCon website and found that they now provide a deb installation package, which I've installed with dpkg -i. Tried compiling the mk-jwm.main.bac source code I found here:

http://www.smokey01.com/saintless/sourc ... k-menu.zip

and the compile seems to have worked. However, the resulting binary is smaller than the current one, which worries me a bit in case that source file isn't the most uptodate. I've therefore PM'd Terry to check and hope he will reply and maybe even do the job! since he could do this quickly I'm sure.

William
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#112 Post by mcewanw »

Hi again Toni,

The USA may be asleep at this timezone time so it will probably be a while till I hear back from Terry. However, I do have the feeling that the source code you have stored for Terry's files are out of date (or at least mk-jwm.main.bac is...). I think the mk-jwm.main binary you are currently using is probably from this post since the size of the file matches:

http://www.murga-linux.com/puppy/viewto ... 210#766210

The above post including binary of mk-jwm.main is from March 2014 whereas the source file I downloaded from smokey01 source code (mkmenu.zip) for mk-jwm.main.bac is dated 6 April 2013...

Trouble is, it is vital to have up-to-date source code for any and all compiled programs as current situation demonstrates. I do know that the xhippo sources you have are current, but I think it is very very important to double check with the authors to make sure you have latest sources for everything else. I do know that puppy forum member amigo often stresses the importance of correctly archiving source and I thoroughly agree with him, else no further fixes or developments can occur to these utilities/systems.

I'm sure Terry will come through with the most current sources of everything though - always just a worry that even an author can lose such things (I know I often do lose my originals, and often have to rely on backups I've earlier uploaded online - I generally email copies to myself as a first safety measure).

Anyway, I'll wait on Terry coming back to me before proceeding with any further tests/developments on this menu-puppy matter.

William

EDIT: I'm a bit concerned because a search for 'sunburnt' on this forum suggests he hasn't been on here since April (2015). I certainly trust and hope Terry himself is fine and well, that is my first concern, since he is a very longtime Puppy forum contributor so a bit worried about him not being on here for so long this year.
github mcewanw

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#113 Post by sunburnt »

Hi guys... It`s been awhile. I think of you often. I haven`t had much of change in my situation sadly.

The binary size diff. might be BaCon compile stripping I do. It`s been so long I can`t remember.
But if my binary is smaller, that may explain it.

I`ll get the latest BaCon release and post my tools again.


Having it search in /.local/... is easy enough to fix, I`ll look at it.

There`s probably many ways to fix the term. problem. The menu maker could test for Desk Man. and act accordingly.
Let me know what method you think will work the best.

Not modding the .desktop files would be nice, but maybe hard. I seem to recall we did it to fix other problems.
There`s probably a few fixes needed for the menu system. You guys list exactly what needs fixing and any additions.

# A thought I consider with every BaCon app. I write.
If back-end code is written in Bash, it`s easily modified. But BaCon code`s speed is needed for menu generation.
If a Bash file is run, then do as much as possible in it. For some things Bash is the only way to do it ( of course ).

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#114 Post by mcewanw »

Hello Terry,

Glad to see you are well, Terry! Yes, I compiled mk-jwm.main from the source code Toni supplies on smokey01 site:

http://smokey01.com/saintless/source-code/mk-menu.zip

and on the system I'm using, but no it doesn't work (some error about CHANGEDIR). I noted that the mk-jwm.main.bac source file is dated 6 April 2013 though, which seems like it is too old since you have posted a new binary in March 2014 (which is the binary that is currently used I think). So hopefully you can check if we have the correct source code and upload the revised version if we don't.

The version of BaCon I used was the 32bit deb provided on their download site and that worked fine in MintPup (as a test I compiled simple bacon calculator example, and that worked okay):

http://www.basic-converter.org/stable/b ... 1_i386.deb

Have you tried MintPup at all, Terry - it is a nice new spin on the DebianDog work.

Look forward to hearing more from you.

William
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#115 Post by saintless »

Hi William.

Both DEVX modules for DD-Wheezy and Jessie include bacon provided from Terry (inside /opt/bin and /usre/share). I think it is also in MintPup devx but I have to check first.

I think the sources archive on the site is the only one with .bac file inside. I guess you are right the binary in the system is from that post but I can't say if it has changes from the source archive.

The other source archives are mostly bash scripts and the scripts from Fred are changing fast with huge difference from the base script (apt2sfs for example). We have most versions as deb packages and it is easy to extract the script from the debs:
http://smokey01.com/saintless/DebianDog ... /Included/
apt2sfs_1.0.2_i386.deb
apt2sfs_1.0.3_i386.deb
apt2sfs_1.0.4_i386.deb
apt2sfs_1.0.5_i386.deb
apt2sfs_1.0.6_i386.deb

Same for debdog-install:
debdoginstallscripts_1.0.0_i386.deb
debdoginstallscripts_1.0.1_i386.deb
debdoginstallscripts_1.0.2_i386.deb
debdoginstallscripts_1.0.3_i386.deb
debdoginstallscripts_1.0.4_i386.deb
debdoginstallscripts_1.0.5_i386.deb

Same for portablesfs:
portablesfs-loadsfs-fuse_1.0.1_i386.deb
portablesfs-loadsfs-fuse_1.0.2_i386.deb
portablesfs-loadsfs-fuse_1.0.3_i386.deb

I don't think the latest script is always better from the first base version. In DD-Squeeze I use old version for most scripts. But the latest version is always available as deb package.

Toni

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#116 Post by saintless »

Hi Terry.
Nice to see you again :)
sunburnt wrote:Not modding the .desktop files would be nice, but maybe hard. I seem to recall we did it to fix other problems.
The convertion from menu to desktop files was executed from /opt/bin/debmenu-changes, debmenu2desktop, debmenu2desktop.convert
The scripts are included but not running with the menu system anymore. After apt-get upgrade and dist-upgrade many desktop files were deleted for some reason. No need to look at this because I prefer to avoid auto-conversion menu to desktop files in the future. We have tools to create or edit desktop files manually when needed.

About mk-jwm.menu I like the way the menu setup works at the moment.
I don't know how the menu generated from desktop files should work but I remember Fred wrote in OpenBox the menu is generated with higher priority from the files in ~/.local/share/applications and after that from /usr/share/applications. I don't know if this will be easy to fix in mk-jwm.menu.
For me not supporting localization changes in mk-jwm.menu is the main disadvantage and it is not easy to fix with sure. It is main disadvantage because the only advice I can give for having main menu categories in different language is - restore the official Debian menu by typing menu-debian.

Toni
Last edited by saintless on Thu 20 Aug 2015, 07:43, edited 3 times in total.

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#117 Post by mcewanw »

Hi Toni,

Yes, I tried running bacon from MintPup DEVX but command 'bacon' wasn't recognised so I presumed it wasn't there and used the deb from BaCon site (and the DEVX for gcc). The mk-jwm.main seemed to compile successfully but gave CHANGEDIR error on trying to use it as substitute for the one in /opt/bin.

Maybe an old version of bacon is in the DEVX that needs to be run via bash - I don't know, but still, I am sure the mk-jwm.main binary you are using is from March 2014 whereas the mk-jwm.main.bac source file you supply is much older from April 2013.

Of course bash script sources aren't an issue, it is any C or BaCon source files (and any similar needing to be compiled sources) that need to be up to date to be useful (and in the opensource community more generally too).

William
github mcewanw

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#118 Post by saintless »

mcewanw wrote:Yes, I tried running bacon from MintPup DEVX but command 'bacon' wasn't recognised so I presumed it wasn't there...
Yes, just checked. Sorry, it is not included in MintPup DEVX module. Only in both DD modules.

Toni

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#119 Post by saintless »

MintPup repository updated with Fred's progressbar fixes for remastering scripts and mintpup-full-installer and changed gsu-root.
Type (copy/paste) in terminal:

Code: Select all

sudo apt-get update
sudo apt-get install remaster-scripts mintpupinstallscripts
Fixes post information updated.

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#120 Post by mcewanw »

Hi Fred,

I'm also curious how menus are generated from desktop files in openbox. Are they piped in somehow? And/or is there any openbox menu generator used? And in any case, can you list the programs that get run when a new menu needs generated? I want to compare that with how they are being created in jwm.

William
github mcewanw

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#121 Post by sunburnt »

Hi guys;

Here is the Bacon command that grabs the Desktop files list.
You can see the Bash command inside it.

Code: Select all

lstDt$ = CHOP$(EXEC$("ls -1 /usr/share/applications/*.desktop"))
I can add another command for /usr/.local/share/applications/* and merge the two.
Like:

Code: Select all

lstDt$ = lstDt$ & CHOP$(EXEC$("ls -1 /usr/.local/share/applications/*.desktop"))
Do you want the ".local" list first, or last?
Or maybe a different way to handle it would be better?

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#122 Post by fredx181 »

Hi William,
I'm also curious how menus are generated from desktop files in openbox.
I must say first that I don't know exactly how it works, but here's some info:

The menu is generated by '/usr/bin/openbox-menu' (from package openbox-menu), it can make use of either /etc/xdg/menus/lxde-applications.menu or /etc/xdg/menus/xfce-applications.menu.
The latter I used for latest mintpup-openbox setup (version before I used lxde-applications.menu)
Dependencies are either lxmenu-data, (for lxde-applications.menu) or libgarcon-common (for xfce-applications.menu)
Both install also 'Categories' *.desktop files in /usr/share/desktop-directories; the <name>.menu file inside /etc/xdg/menus/ can read from these and the menu will be updated if there's a *.desktop change or addition in /usr/share/applications (or e.g. ~/.local/share/applications).
I can only guess, probably dependency 'libmenu-cache3' does the updating, so it's not depending on 'update-menus' command, which is pretty nice :)

The config file is ~/.config/openbox/menu.xml, containing:

Code: Select all

 <menu id="desktop-app-menu-lxde" label="LxdeApplications" execute="/usr/bin/openbox-menu mintpup-ob-applications.menu" icon="/usr/share/icons/applications.png">
'mintpup-ob-applications.menu' is a modified xfce-applications.menu (still labelled 'LxdeApplications' in menu.xml, but this doesn't really matter)

I've been searching for similar way for Jwm, but couldn't find, yes, there's xdg-menu from Arch Linux;
https://wiki.archlinux.org/index.php/Xdg-menu
Which should work with Jwm, but needs extra perl dependencies.
And there's a python dependent script I've seen a while back, but we probably don't want that.

Still I think it should be possible, there might be a way such as puppy handles it, I've seen here and there.

Terry: Thanks for replying, all the best to you!
One thing:

Code: Select all

/usr/.local/share/applications/*.desktop
Should probably be:

Code: Select all

/usr/local/share/applications/*.desktop
(not ".local", but "local")

Edit: Sorry, reading now I see Icewm listed, not Jwm on:
https://wiki.archlinux.org/index.php/Xdg-menu

Fred

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#123 Post by mcewanw »

sunburnt wrote:Hi guys;

Here is the Bacon command that grabs the Desktop files list.
You can see the Bash command inside it.

Code: Select all

lstDt$ = CHOP$(EXEC$("ls -1 /usr/share/applications/*.desktop"))
I can add another command for /usr/.local/share/applications/* and merge the two.
Like:

Code: Select all

lstDt$ = lstDt$ & CHOP$(EXEC$("ls -1 /usr/.local/share/applications/*.desktop"))
Do you want the ".local" list first, or last?
Or maybe a different way to handle it would be better?
Hi Terry,

Yes, I had also noted that it was that CHOP$ command that provided the list of desktop files and had planned to try adding $HOME/.local/share/applications as you suggest ($HOME not /usr), so I think it would be good if you could manage that. I don't know whether it should be first or last; EDIT: I think .local is correct (i.e. $HOME/.local/share/applications).

Main thing is, are you sure the sources from smokey01 are the most up to date. I wonder why after I compiled the BaCon the resulting program didn't work for me and gave error about CHANGEDIR line?

Thanks for your help.

William
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#124 Post by mcewanw »

Thanks for the info Fred,

I'll check that out further. I take it that the file /usr/bin/openbox-menu is in MintPup. I'm currently in DDopenbox_wheezy and don't see it there.

William
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#125 Post by mcewanw »

Note that I've also tried compiling the smokey01 stored (mk-menu.zip) bacon code mk-jwm.main.bac in DD-openbox-wheezy using its DEVX. Again it seemed to compile using bacon in that DEVX, but again on trying to use the resulting binary mk-jwm.main in /opt/bin, I still get the same runtime error message:

Code: Select all

Runtime error: statement 'CHANGEDIR' at line 25 in 'mk-jwm.main.bac': Unable to change to directory: No such file or directory
I still wonder if I am using the most up to date source code for mk-jwm.main.bac? I don't know BaCon so have difficulty understanding that CHANGEDIR code line in the source code - I did wonder how it knows what its working directory is. The line 25 referred to in mk-jwm.main.bac is:

Code: Select all

CHANGEDIR REPLACE$(ARGUMENT$, "/mk-jwm.main", "")
I've already spent a lot of time on this but don't want to go further, of course, if it turns out I'm using the wrong or old source code.

EDIT: I do note that there is a commented out PRINT statement, which should yield the result of above CHANGEDIR code - I'll try that to see what the problem may be, but I still need confirmation I'm working with the most uptodate source code.

EDIT2: Very odd, it seems it can't find ~/.jwm/categories.lst or ~/.jwm/menu-root.lst when trying to run mk-jwm.main once placed in /opt/bin. Does it have to be compiled in a special way from a special location, Terry?

EDIT3: It does soom to me that the CHANGEDIR line should result in a cd to $HOME/.jwm (but doesn't seem to as source code stands) so that the line

lstCat$ = CHOP$(EXEC$("echo \"$(<./categories.lst)\" |sed '/#/d;/./!d'"))

can find ./categories.lst and similarly later on for ./menu-root.lst, but as it stands I think it probably cd's to /opt/bin since that is where binary mk-jwm.main is stored (unless, as I ask, it is something to do with compiling in a special way?). Well, bit of a mystery since it is true that /opt/bin/mk-jwm.menu contains 'cd $HOME/.jwm' before calling mk-jwm.main, so I don't know what the problem is...

William
github mcewanw

Post Reply