WM menu systems for DebianDog/MintPup using xdg etc

[mcewanw]

Just a placeholder for further discussions about WM menu system improvements/developments.

Btw, how do you normally set the number of desktops? I can't find how to

Hi Fred,

http://www.joewing.net/projects/jwm/con ... l#desktops

Just look for the Desktops tag in $HOME/.jwmrc (or whatever file is used to generate that) and you will see how it works.

Toni,

I think the sudden interest in menu system was caused by MintPup openbox having problem with doubling up of Terminal=true and xterm -e. Then lack of localisation issue was raised, which is a major potential problem for some but aside from English I can only speak Norwegian, far now from fluent...

Yes, there is always "Debian menu system" but I have to say I just hate the look of it! Irrational dislike maybe, but I doubt I'm alone.

I understand that there are far more important things to fix up than the menu, hence agree a separate thread for those interested in that is better. However, DebianDog has been working well and stable for a long time now, and fine-tuning of the look and feel features (menu included) seem important to me in terms of making DD (and MintPup) attractive distributions. Style can be every bit as important as functionality (hence the Apple Mac addicts).

William

[saintless]

Hi William.

I think the sudden interest in menu system was caused by MintPup openbox having problem with doubling up of Terminal=true and xterm -e. Then lack of localisation issue was raised, which is a major potential problem for some but aside from English I can only speak Norwegian, far now from fluent...

This is strange bacause I'm sure I reported both problems few times before and there wasn't such interest for solving the problems then.
My suggestion for adding localisation support in mk-jwm menu.
Why I have to add "xterm -e" in some scripts or desktop files.

I will check this thread if you need something to be changed in MintPup or DD-Jwm for next iso updates (content in desktop files or something for jwm theme changing for example) to make menu-openbox deb package more compatible.

Toni

[fredx181]

Hi Toni, William

Fixed jwm-obmenu v 0.0.2:

Continued from here:
http://www.murga-linux.com/puppy/viewto ... 502#861502

In fact it works almost the same way now as the other menu's are set up, by concatenating jwm.head jwm.main jwm.tail in $HOME/.jwm to $HOME/.jwmrc
This way Jwm theme change should work ok now, since original $HOME/.jwm/jwm.tail will be used, just the same as the other menu systems.
So, in general, making changes to $HOME/.jwm/jwm.tail will apply.
Changes for jwm.head needs to be done in "/etc/xdg/templates/jwm.head" to apply for Menu-Openbox only.

William, thanks, good idea to have separate thread.
Here's how jwm-obmenu works:

Running 'Menu Openbox' from the menu starts the script /opt/bin/menu-openbox.
It will make some alterations to .desktop files (copy first to $HOME/.local/share/applications) and will copy jwm.head and jwm.main from /etc/xdg/templates to $HOME/.jwm
(for normal user; it will copy: jwm_user.head and jwm.main)
Then merge jwm.head, jwm.main and jwm.tail (from ~/.jwm) to $HOME/.jwmrc.
Next it will run /usr/local/bin/jwm-obmenu (see below for what it does)

A small difference in /etc/xdg/templates/jwm.head compared to the existing one in $HOME/.jwm, addition:

Code: Select all

<StartupCommand>jwm-obmenu</StartupCommand>

This will run /usr/local/bin/jwm-obmenu at jwm start, but only when 'Menu Openbox' is activated.
When e.g. 'Menu Puppy' is activated (after once activated Menu-Openbox) the line is still there but I made sure it does nothing then.
Content of jwm.main for Menu Openbox:

Code: Select all

<Include>$HOME/.cache/jwm-app-menu</Include>

$HOME/.cache/jwm-app-menu is generated from /usr/local/bin/jwm-obmenu, by the command:

Code: Select all

openbox-menu dog-applications.menu -f jwm -I 24 -p -o jwm-app-menu -R 'jwm -reload'

(dog-applications.menu is inside /etc/xdg/menus, is a modified xfce-applications.menu)
(and the categories, dog-<category>.directory files in /usr/share/desktop-directories are renamed xfce-<category>.directory files, this is mostly because I wanted it to be a unique package, so that dpkg doesn't complain about already existing files from libgarcon-common package (which provides these xfce .directory files)
$HOME/.cache/jwm-app-menu has all the categories and programs, it is read by 'menu-cached' and will be updated if there's a change in /usr/share/applications or in $HOME/.local/share/applications.

For anyone wondering where is e.g. the Games category in the menu, it will show if there is one or more applications installed from that category.

Toni, let's see first if Menu-Openbox works properly now (with jwm and also when switching to the other menu systems).
For me the menu interest came when I made 'mintpup-openbox' setup using pipemenu, before that I didn't know such a xdg menu could be made with a small size program as openbox-menu.
It works different in DD openbox_xfce, the menu is generated by menu plugin from xfce4-panel.
You can oversee best the problems it brings for using it in different DD versions, I think however that jwm-obmenu is the best way for menu generating on JWM, but I am not really the most objective person, of course .

Fred

[fredx181]

Hi Toni,

mcewanw wrote:
I think the sudden interest in menu system was caused by MintPup openbox having problem with doubling up of Terminal=true and xterm -e. Then lack of localisation issue was raised, which is a major potential problem for some but aside from English I can only speak Norwegian, far now from fluent...

This is strange bacause I'm sure I reported both problems few times before and there wasn't such interest for solving the problems then.
My suggestion for adding localisation support in mk-jwm menu.
Why I have to add "xterm -e" in some scripts or desktop files.

I may have missed something, excuse me then.

I think 'not interested in solving a problem' means many times that someone just don't have any clue how to solve.
But then... at the point of viewing some light for improving things, there could be suddenly a lot of interest.
That's anyway how it went for me with the discussion for Jwm menu at that time, lost interest at some point back then, accepting how it is, but now it feels different because of progress in discovering possibilities.

Fred

[mcewanw]

Hi William.
This is strange bacause I'm sure I reported both problems few times before and there wasn't such interest for solving the problems then.
My suggestion for adding localisation support in mk-jwm menu.
Why I have to add "xterm -e" in some scripts or desktop files.

Easily explained in my case, Toni. My last post to Puppy Forum in 2014 was on 6 Dec and I never (I think) looked in again till 30 Jan 2015 because, unlike you guys, I keep away from the computer over the peak summer months (which is Dec/Jan in New Zealand)! :-) Your post about xterm -e was late Dec 2014, and I thus never noticed it and was too busy to keep up with all the missed posts thereafter. I came across the issue only recently when testing Fred's openbox addition to MintPup, which is why my sudden interest in menu fixes arose - it didn't matter to me if it had been brought up before. I can't say why Fred also took an interest. Anyway, good we took a look at it again.

William

[saintless]

Hi William, Fred.

Please, don't feel wrongly accused. My apologies if my post sounds like that.
My point is when Terry and I worked on the menu system long time ago there was not much interest from you and over a year later we don't have single complain about the included menu system from enyone (except from me).

Yes, it is good you both decided to work on menu improvements.
But Fred is working on alternative jwm-obmenu package which can't be installed in DD-Wheezy and DD-Squeeze. If you feel DD-Jessie and MintPup need improved menu don't you feel the same for the menu in DD-Wheezy and Squeeze?

I think however that jwm-obmenu is the best way for menu generating on JWM, but I am not really the most objective person, of course .

I'm also not the most objective person Fred, but while mk-jwm, mjwm and update-menus use zero RAM this is the report from lxtask about ram usage (RSS) after starting menu-openbox in DD-Jessie:

Code: Select all

openbox-menu    10,5
jwm                        6,1
menu-cached        4,2
jwm-obmenu         2,4

Openbox-menu process alone uses more ram compared to the WM.
Starting again menu-puppy (or menu-debian, menu-mjwm) doesn't kill the processes. Menu-openbox ram usage is kept for the session for all menu methods (I guess it can be fixed). Exit X and startx kills openbox-menu and jwm-obmenu process.
menu-cached process stays with the same ram usage in Jwm and even when I change the WM to icewm:

Code: Select all

icewm                 9,2
menu-cached     4,2

Jwm ram usage will be double compared to IceWm and IceWm itself gets 4,2 Mb extra ram usage just because I started once menu-openbox in Jwm.

Toni

[mcewanw]

Hi Toni, Fred,

Yes, I also noted the RAM usage difference, which is why I commented that Terry's menu system remained great because of its low resource usage. However... as time goes by (despite some of the old machines some of us have) RAM sizes on even quite old machines becomes quite large (2G or more) so for many people these extra RAM usage figures become almost irrelevant (albeit a bit painful to us purists... :-). But, for me, where localisation is unimportant (in my house) I will probably stick with Terry's menu, but for a larger audience things change and, from the bells and whistles (including localisation) point of view there doesn't seem to be anything obviously better than obmenu out there from what we have discovered so far. I think it is a good alternative offering to widen the likely audience. I didn't realise it only worked with MintPup or DD-Jessie - why is that?

William

EDIT: I actually think most people don't care so much abotut the extra RAM usage (within limits) - I do... so I'd hate to see Terry's menu system abandoned - I rather like its somewhat 'static nature' - meaning it requires update menu command (via menu-puppy) to be run - but thus no daemon hogging RAM in background. But good to offer the somewhat more sophisticated choice IMO for newer machines with Jessie/Mint on them and so on.

EDIT2: Also, it must surely be possible to turn off any and all menu-watching daemons once menu is generated - in other words to allow a static generated menu using obmenu, but then switching it off unless woken up again by user toggling it back on?

[mcewanw]

Actually Fred,

I am having a problem with your jwm-obmenu version 2... after installing it on pristine MintPup I can't find the JWM - System - Menu openbox start command. I've probably done something stupid, but I've tried twice now...

William

used dpkg -i followed by apt-get install -f and system said it was installed ok... I haven't checked further yet though.

[mcewanw]

Oh, if I just use dpkg -i, jwm-obmenu installs fine, but if I then try to finish things off with apt-get install -f, the system removes obmenu! Is it just me? It is late here, maybe I need a break...

William

[saintless]

Hi William.
Didn't test the second deb package in MintPup yet. But the first version needs to install small dependency package in MintPup. Make sure you run apt-get update first. Otherwise the system will remove jwm-obmenu because it can't download the dependency package.

For Wheezy and Squeeze jwm-obmenu needs packages not available in Wheezy/Squeeze repo and simple copy/paste the needed libs gives incompatibility error from my quick testing.

Toni

[mcewanw]

Ah yes, Toni, silly of me, that is what the problem I had will be. On a different system at the moment.

Thanks,

William

[saintless]

I actually think most people don't care so much abotut the extra RAM usage (within limits) - I do... so I'd hate to see Terry's menu system abandoned - I rather like its somewhat 'static nature' - meaning it requires update menu command (via menu-puppy) to be run - but thus no daemon hogging RAM in background.

Just one small correction. Terry's menu needs Start -> Menu-Puppy to update the menus only if you add manually desktop file in /usr/share/applications.
If you use apt-get/synaptic or "dpkg -i" the deb package containing menu entry has postins script with update-menus command inside. In practice this auto-updates the menu only when it is needed (installing package with menu entry file inside) without the need to have daemon.
We use with Terry's menu the official Debian menu method by symlinking update-menus to Terry's script instead to /usr/bin/update-menus
And this method speeds up installing packages process because update-menus command runs only for packages containing menu entry. It doesn't run for packages containing libs only for example.

Edit: Yes, I also think jwm-obmenu is very good alternative. But not so good for default menu in the iso.
If we don't care about the ram usage what is the point to keep Jwm as default window manager?

Toni

[mcewanw]

Edit: Yes, I also think jwm-obmenu is very good alternative. But not so good for default menu in the iso.
If we don't care about the ram usage what is the point to keep Jwm as default window manager?

Toni

True, but I think jwm is a great (and perhaps underated) low-resource window manager. And yes, the low resources is a big point, I agree, but I just used lxtask to kill process openbox-menu (process jwm-obmenu dies then too) and menu-cached and that temporary extra-RAM usage was gone... Surely some mechanism such as used with Terry's system (post-install) etc could additionally be used with jwm-obmenu giving same low RAM advantage but with full localisation support?

William

EDIT: One good thing, from my point of view, is that these recent menu discussions have finally interested me in BaCon programming and I've been playing around with that and exploring GUI building with HUG. So thanks to Terry's exemplars for that. Anyone who programs tends to look for some Holy Grail of simple to construct GUI apps programming language. Bash is a wonderful and powerful scripting language, but I can't say I've ever loved gtkdialog, and resource usage of the latter is also an issue on top of bash underneath. Problem with compiling languages like BaCon/C is, as we know, it makes modifications trickier (in that you have to learn BaCon and keep reliable source code archives!). However, BaCon is certainly interesting in being quite simple to use and powerful. It can also be used with GTK and not just via HUG so I'm keenly exploring all that just now - though I have no particular project in mind. There is always the problem of whether to use shared library hug.so bearing in mind disadvantage that new versions of hug.so can cause problems but linked in hug.so increases binary size (which is why Terry's Wallpaper gui is relatively large). Oh well, it is interesting hobby anyway....

[saintless]

Hi William.

I guess it is possible to change the scripts for starting menu-puppy, menu-debian, menu-mjwm to kill all jwm-obmenu processes and add jwm-obmenu as fourth menu method and test the changes properly before next iso updates.
But again - it is only for MintPup and DD-Jessie. Isn't it better to keep it as separate deb package then and make it auto-remove mk-jwm and mjwm setup before installing?
If the user choice is jwm-obmenu what is the point to keep 4 menu systems and kill obmenu processes each time the menu is changed?
I prefer to keep the same menu setup in all DD versions and MintPup. It makes easier answering questions about the menu without need to ask what is the version in use.
If the user needs full menu localisation support we can add in the first post:

Code: Select all

apt-get update
apt-get install jwm-obmenu

Edit: If you mean to make jwm-obmenu processes active only when update-menus is executed from deb package installing I'm not sure about this. Maybe Fred will know better if it is possible.

Toni

[mcewanw]

Edit: If you mean to make jwm-obmenu processes active only when update-menus is executed from deb package installing I'm not sure about this. Maybe Fred will know better if it is possible.

Toni

Yes, that's what I meant. If that works it would be a more interesting option to me.

William

[fredx181]

Hi Toni, William,

I'm also not the most objective person Fred, but while mk-jwm, mjwm and update-menus use zero RAM this is the report from lxtask about ram usage (RSS) after starting menu-openbox in DD-Jessie:
Code:
openbox-menu 10,5
jwm 6,1
menu-cached 4,2
jwm-obmenu 2,4

Yes, I agree that's to much extra RAM usage, I didn't look at that very much, just saw increase of total RAM in htop by a few MB's, but obviously that says not all.

Edit: If you mean to make jwm-obmenu processes active only when update-menus is executed from deb package installing I'm not sure about this. Maybe Fred will know better if it is possible.

Ok, that would be a good compromise, I experimented already to make it this way, got it working with user root, but can't make it work yet with e.g. user puppy, continuing... I won't give up

Fred

[saintless]

Thanks Fred.

I don't know if you use similar method but with Terry's menu from user account refreshing menus and installing packages with apt-get has different scripts.
/opt/bin/refresh-menus is for manually refreshing from user (and root) account. /opt/bin/menu-puppy doesn't work well from user account (It asks once for user password and then once more but for root password). The script works also for root and it is the one inside the desktop file.
/opt/bin/update-menus is link to /opt/bin/menu-puppy and starts /opt/bin/refresh-menus-3 when installing packages and auto-updates the menu for user and root.
I think the code in refresh menus was suggested by you when I asked for help at that time. I tested 3 different combinations and the best one is the uncommented in refresh-menus scripts.
The menu setup seems complicated at first but works well even in standard Debian.

Toni

[fredx181]

Hi Toni,

I don't know if you use similar method but with Terry's menu from user account refreshing menus and installing packages with apt-get has different scripts.
.......

Thanks, yes the menu system is rather complicated, glad anyway that I don't have to re-invent the wheel.

I think it has one weakness:

Suppose you are logged in as root and make the switch to menu-mjwm, then login as user puppy,ok, menu- puppy is used, the user likes to stay with it, install some programs, then suddenly the menu has changed to menu-mjwm (because /opt/bin/update-menus is still symlink to menu-mjwm.
Not a disaster of course, but not how it should be.

Now.., probably not many users will switch from root to e.g. puppy and back, on the other hand if you like it to be a true multi-user system, for info here's a possible solution for that, didn't test very much, just an idea:

Make /opt/bin/update-menus a script with content something like this:

Code: Select all

#!/bin/bash

export USER_HOME=`echo $XAUTHORITY | sed -e 's,/[^/]*$,,'`

if grep -q ".jwmrc-mjwm" $USER_HOME/.jwm/jwm.main; then
echo menu-mjwm running...
/opt/bin/menu-mjwm

elif grep -q "/etc/jwm/debian-menu" $USER_HOME/.jwm/jwm.main; then
echo menu-debian running...
/opt/bin/menu-debian.

elif grep -q ".cache/jwm-app-menu" $USER_HOME/.jwm/jwm.main; then
echo menu-openbox running...
/usr/local/bin/jwm-obmenu

else
echo menu-puppy running...
/opt/bin/menu-puppy
fi

And remove the commands for creating symlink to /opt/bin/update-menus in all /opt/bin/menu-* scripts.

Again, just idea, there may be complications or compatibility issues, as there almost always are some

Btw, I have made also jwm-obmenu for wheezy now (compiled openbox-menu on wheezy), it works but I like to do some more testing.

Fred

[saintless]

Hi Fred.

The menu setup is not perfect but adding one more script instead symlink will make it more complicated. We always get problems after changes. In the case with your example /opt/bin/update-menus script it will break the menu in IceWM.
IceWM has the default Debian menu and needs /usr/bin/update-menus to update the menu. With this script Icewm will update Jwm menu because /opt/bin/update-menus script will run instead /usr/bin/update-menus command.
Installing different WM like blackbox for example will create the same problem for the user. Running menu-debian as it is will restore the official update-menus command and every WM using this method will work well.
I'm sure you can easy add few lines to cover this option but not for any available WM in debian repo and you can't predict what complications this change will bring later in situation not tested from us. I prefer to know the weakness we have instead finding new problems after we make new iso updates.

Btw, I have made also jwm-obmenu for wheezy now (compiled openbox-menu on wheezy), it works but I like to do some more testing.

Thanks.

Toni

[fredx181]

Hi Toni, William,

Here is low resources jwm-obmenu v 0.0.3-nocache.

- No daemon mode; Once the part of the menu 'jwm.main' is generated, openbox-menu exits, similar as mk-jwm.main does.
- Menu-cached is disabled (menu-cached is very stubborn, btw, needs to get killed by first remove ~/.cache/menus/* and then 'pkill menu-cached', tried to compile openbox-menu without libmenu-cache, it seems not possible to me)
- Updating the menu depends on /opt/bin/update-menus or refreshing by running 'Menu Openbox' from menu.

Alltogether: no process is running in the background after the menu has been generated so it works basically the same as the other menu systems.

Attached;
For DebianDog Jessie and Mintpup;
jwm-obmenu_0.0.3-no-cache_i386.deb.tar

For DebianDog Wheezy:
jwm-obmenu_0.0.3-wheezy-nocache_i386.deb.tar
(remove dummy .tar extension)

Edit:

The menu setup is not perfect but adding one more script instead symlink will make it more complicated.
......

Yes, I see, suspected something like that already.

Edit: Made small fix:
There should be no 'user settings' category when logged in as root. fixed.
Reattached.

Fred