New xdg menu proposal and implementation

A home for all kinds of Puppy related projects
Message
Author
User avatar
Mobeus
Posts: 94
Joined: Thu 26 Aug 2010, 15:49

New xdg menu proposal and implementation

#1 Post by Mobeus »

To all Puppy system developers, this is a proposal for improving the Puppy menu.

An implementation of this proposal is provided in the next post.

Puppy as produced by woof is fully freedesktop.org menu standard compliant, with one major exception. That one exception is this: Puppy does not implement the $XDG_CONFIG_DIRS/menus/applications.menu. This is simple to implement in Puppy.

Adding the applications.menu will:

Pros:
Make Puppy fully compliant to the freedesktop.org menu standard.
Allow the use of one set of files for the system menu, regardless of window manager or panel.
Allow newly installed xdg compliant window managers and panels to instantly use the existing applications.menu.
Allow those window managers and panels to recognize and use Puppy's extended menu X-categories
Simplify the addition of new window managers and panels.
Allow easier full menu editing without ever modifying any system menu files (applications.menu, *.directory, *.desktop, or menu icon)
Allow all users to have their own custom menu.
Allow all users to have their own multiple window managers and panels with matching custom menus.
Not break support of non-xdg window managers and their utilities.
Not interfere with Puppy Package Manager.
Not interfere with Puppy's custom icon theme management (Icon Switcher).

Cons:
Some menu generation scripts called by fixmenus require a minor change.


Basic freedesktop.org menu standard compliance, as understood by yours truly.

In order to comply with the freedesktop.org menu standard the system must use applications.menu to define the menu layout. (This is mandatory).
System implementations may chose to use menu files with other names for tasks or menus other than the main application menu. (Other than, not instead of).

Systems that offer multiple desktop environments and that want to use distinct menu layouts in the different environments may use differently prefixed menu files. In this case the $XDG_MENU_PREFIX environment variable must be set by the system to reflect the $XDG_MENU_PREFIX-applications.menu file that is to be used.

Menu Definition Files (Menu files define the hierarchy of menus that are used in the desktop or panel menu bar)

User specific menu files are located in the $XDG_CONFIG_HOME/menus/ directory which is searched first.
System-wide menu files must reside in a $XDG_CONFIG_DIRS/menus/ directory.

If $XDG_CONFIG_HOME is not set, then the default path $HOME/.config is used.
If $XDG_CONFIG_DIRS is not set, then the default path /etc/xdg is used.

Simple procedure for resolving the location of the applications.menu.
Search $XDG_CONFIG_HOME for /menus/applications.menu.
Search, in left to right order, each directory path in $XDG_CONFIG_DIRS for /menus/applications.menu.
Use the first applications.menu file found and terminate the search.

Directory Files (*.directory files specify details for a menu such as a name, a tooltip, and an icon.)

User specific directory entries are located in the $XDG_DATA_HOME/desktop-directories directory which is searched first.
System-wide directory entry files must reside in a $XDG_DATA_DIRS/desktop-directories directory.

If $XDG_DATA_HOME is not set, then the default path $HOME/.local/share/ is used.
If $XDG_DATA_DIRS is not set, then the default paths /usr/local/share/:/usr/share/ are used.

Simple procedure for resolving the location of a directory file.
Search $XDG_DATA_HOME for /desktop-directories/*.directory file.
Search, in left to right order, each directory path in $XDG_DATA_DIRS for /desktop-directories/*.directory file.
Use the first matching *.directory file found and terminate the search.

Desktop Entry Files (menu items for individual programs)

User specific desktop entries are located in $XDG_DATA_HOME/applications directory which is searched first.
System-wide desktop entry files must reside in a $XDG_DATA_DIRS/applications directory.

If $XDG_DATA_HOME is not set, then the default path $HOME/.local/share/ is used.
If $XDG_DATA_DIRS is not set, then the default paths /usr/local/share/:/usr/share/ are used.

Simple procedure for resolving the location of a desktop file.
Search $XDG_DATA_HOME for /applications/*.desktop file.
Search, in left to right order, each directory path in $XDG_DATA_DIRS for /applications/*.desktop file.
Use the first matching *.desktop file found and terminate the search.
.
/root for the home team

User avatar
Mobeus
Posts: 94
Joined: Thu 26 Aug 2010, 15:49

#2 Post by Mobeus »

Menu Implementation, Test Procedure and Notes

The binary portion of the implementation was tested on Puppies lucid 5.2.8, slacko 5.5, and upup-precise so should work on a wide range of Puppies. Please test and provide feedback with as many Puppy editions as possible.

Use a fresh 32 bit Puppy running in ram or with a new small save-file. Testing example assumes JWM window manager.


Manually install all of the files from the implementation.tar.gz
There is a hidden directory /root/.fluxbox

Test:

cd /root/my-applications/bin

#generate the /etc/xdg/applications.menu
./createmenus
fixmenus
jwm -reload

Observe the duplicated original Puppy menu with a new 'Other' menu.

#Simulate a custom edited user menu
./editmenus
fixmenus
jwm -reload

Observe the users edited menu.
Note the layout changes.
Note the Utility menu and Abiword menu item changes.

Delete /root/.config/menus/applications.menu
fixmenus
jwm -reload

Observe the restored system menu layout with the new 'Other' menu.
Note the Utility menu and Abiword menu item still have the users changes.

Delete /usr/share/applications/AA-Strange-Program.desktop
fixmenus
jwm -reload

Observe the 'Other' menu is no longer visible

Delete /root/.local/share/applications/Abiword-wordprocessor.desktop
fixmenus
jwm -reload

Observe Abiword menu item is restored to the original.

Delete /root/.local/share/desktop-directories/Puppy-Utility.directory
fixmenus
jwm -reload

Observe the Utility menu is restored to the original.

At no time were any changes made to the system menu files.


Notes:
Supported non-xdg window managers and panels are jwm, icewm, openbox, fluxbox and fbpanel.
The misc-support.tar.gz archive contains the modified scripts that fixmenus calls when refreshing the menus for jwm, icewm, openbox, fluxbox and fbpanel. The original scripts are from Puppy and various packages found on this forum and the Quirky source archive. These are provided for convenience. The modification consists of deleting the multiple lines containing the commands to <windowmanager>-xdgmenu /etc/xdg/menus/puppy-*.menu with one gen_pup_xdg <windowmanager> [svgflag] line. This is the only change these scripts require.

The menus generated by the included binary gen_pup_xdg have menu icon support.
The icon syntax has not been confirmed on openbox and fluxbox. Feedback from
testing with these two window managers would be helpful.

The binary gen_pup_xdg is simply rarsas *-xdgmenu files combined into one with some improvements.
The improvements include:
Automatic detection of the proper applications.menu to use, either the user's or system's.
Removal of exec arguments (%F %U etc.) from the menu. They don't belong there.
Output of menu icons for all menus.
The option to ignore svg icons for compatibility with window managers/panels such as openbox.
Fast xdg compliant search & find of the menu icons for fluxbox.
Menu icon search includes Puppy's icon theme directory.
Some formatting of the menu output for readability.

The binary is written and compiled with BaCon BASIC to C converter version 2.0 build 1. The source code can easily be translated to C if you prefer; it uses plain Gtk and can be compiled against gtk2 or gtk3, 32 or 64 bit.
This is an alpha and source code will likely be changed during testing.
Attachments
source-gen_pup_xdg.tar.gz
(3.39 KiB) Downloaded 880 times
misc-support.tar.gz
(7.7 KiB) Downloaded 844 times
implementation.tar.gz
(50.23 KiB) Downloaded 888 times
/root for the home team

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#3 Post by 01micko »

Hi Mobeus,

Just to let you know that this is still on my radar, just no time ATM :(
Puppy Linux Blog - contact me for access

User avatar
Mobeus
Posts: 94
Joined: Thu 26 Aug 2010, 15:49

#4 Post by Mobeus »

Thanks for that Mick.

I was beginning to think I had committed a major faux pas with this thread. After no comments or feedback and my user account being deactivated somehow :shock: I really didn’t know what to make of it.

Thank you to Flash for fixing the account
/root for the home team

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#5 Post by musher0 »

Hello, Mobeus.

First of all, many thanks for trying to clear up this entangled subject.

I'll give it a shot with icewm and pekwm menus ASAP (I have contracts to fill out ATM).

For now, two general questions if I may:

1) would you happen to know if the scripts, etc., that you presented above are adapted to any localization?

Some famous menu scripts follow the principle of "two entities (be they atoms or chairs, it doesn't matter) cannot occupy the same space simultaneously". For example, in the *.desktop files, if you have a category "Name" and another "Name[whatever_language]", in those scripts, only one form is recognized, usually the one without the appendage. Most of the speed gain of the initial script is lost if you have to add twists and turns to create a readable localized menu.

2) what logic does this system follow? No offense intended; I mean "logic" as in deductive logic (classifying data from principles x,y,z; from the top down), or empirical logic (building a structure from data a,b,c; from the ground up), or "usage" logic (real people tend to organize things this way and not that way).

Many thanks in advance.

musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Mobeus
Posts: 94
Joined: Thu 26 Aug 2010, 15:49

#6 Post by Mobeus »

Hi musher0,

I was hoping to hear from you here. First, pekwm is not one of the formatted menus supported (at this time), but please do offer any insight you may have on supporting that menu. It is not understood by me at this point as I have never used it.

1) Localization. The scripts mentioned in my implementation example above are from Puppy and others on this forum. The menu generator that I put together does not actually create the menus for the programs. It takes the output from gnome-menus and formats it for a specific window manager so menu localization is provided by the gnome developers and is fully supported that way. The actual localization of the menu and program names is provided in the .desktop and .directory files that make up the xdg menus. If a specific language is provided in these files then the menu will be output according to the locale of the OS.

For example, here is a .directory file with [fr] localization:

Code: Select all

[Desktop Entry]
Name=Sound & Video
Name[fr]=Son et vidéo
Comment=Multimedia menu
Comment[fr]=Multimédia
Icon=applications-multimedia
Type=Directory 
See, no further translation needed. With a French locale [fr] gnome-menus will select the proper language strings for the menu name and tooltip. If no locale strings are in these files then the menu will be in English. The same applies to the .desktop file for a program. All menu localization should be in the .directory and .desktop files.

2) The logic for the menus is provided by the freedesktop.org menu spec which gnome-menus adheres to. The ordering of the menus is controlled by the <Layout> element in the applications.menu. If there is no <Layout> element then the ordering is alphabetic. The default layout would be in /etc/xdg/menus/applications.menu and a users modified layout, if any, would be in ~/.config/menus/applications.menu. The users applications.menu merges the default one (usually) and any specific elements in the users applications.menu will override the defaults. The same logic applies to the users .directory and .desktop files. The users files override the default ones, and that is where any menu editing should take place.

These are some of the things the implementation example demonstrates. Feel free to rearrange things in ~/.config/menus/applications.menu and make changes to ~/.local/share/applications/Abiword-wordprocessor.desktop and ~/.local/share/desktop-directories/Puppy-Utility.directory.
Add your own locale strings, add another menu (don’t forget category tags and a matching .directory file)

To All:
If anyone is trying to understand the xdg menu specs a little better, look here for an easier to understand presentation http://www.linuxtopia.org/online_books/ ... ure-0.html

Have some fun with it 8)
/root for the home team

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#7 Post by musher0 »

Hi Mobeus!

I did try your suggested scripts, and I was a bit disapointed.

It is well done, and it obviously respects the gnome standards, but it only changes the order of the menu, on my machine anyway.

I was hoping to see something focused on users' logic, or closer to it. And that, I'm afraid, will never be at the very general level of standards, but the programmer's perception of the category of his program. Perceptual psychology rather than Computer science ?

For example, take a look in /usr/share/applications. Try to isolate all the applications for multimedia. Then look at their line "Categories=". Very few are correctly classified. There are a few notable audio programs that are classified under "AudioVideo". "AudioVideo" is the topmost general category for this type of applications, of course. And when the user consults his/her menu, (s)he gets confused. At this top level, there is a mix of strictly video, audio-video and strictly audio programs. What does what, is the question in the user's mind.

What's wrong with indicating "Categories=Audio" for an audio only program? It does sound very logical to me! :)

You may want to do the same for the "Graphics" categories. it's a mumble-jumble there too.

I think we have to educate the programmers in the proper classification of their own programs! :twisted: And the users will say: "Finally..." :)

It's not so much the standards, I think.

My proposal for a solution in Puppy regarding this problem would be to suggest that Mr. Kauler issue an "edict" :) to all Puppy developers saying :
* Puppy shall have so many menu categories, and no more;
* in each category of the menu we have
main programs in category
the utilities for this category must go in a sub-menu
* only exception to these subdivisions would if the sub-menu gets too long (more than ten entries is when the brain starts to get tired, I believe.) Then we create another sub-menu within the category.

Right now, it's like a carnival on this subject.

I'll end on a funny note. I'd like to ask a judge to issue an arrest warrant :twisted: for the specific Puppy developer who thinks that gcolor2 is a main graphics program and that mtpaint is a graphics utility. It's the reverse, of course, but we should not have to spell it out to him!

Cheers!

musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Mobeus
Posts: 94
Joined: Thu 26 Aug 2010, 15:49

#8 Post by Mobeus »

Hello musher0

Thanks for trying but I think you missed the point of the implementation demo. This is not a menu editor nor does it change anything in the base Puppy menus. It is only to show how the Puppy menus should be implemented. Conforming to the standard would allow easy use of alternate window managers and panels that will keep the users current menu, plus enable sane menu customization. The changes are simple, minor, and easy to implement, but this must be done at the distro level.

I'm not holding my breath.
/root for the home team

2byte
Posts: 353
Joined: Mon 09 Oct 2006, 18:10

#9 Post by 2byte »

Hi Mobeus,

First off, thanks for posting your code and scripts. Also for the explanation of how the menus get assembled by gnome menus.

I wasn't convinced it would make it easier to add a different panel so I tested it with jeyjs lxpanel pet. I took the pet apart and deleted all of the directory files and the menu files in it. Then I renamed the applications.menu that your editmenu script created earlier in ~/.config/menus to lxde-applications.menu. I also removed all of the other files from /etc/xdg/menus. Then I put jeyjs pet back together and installed it.

Sure enough, after rebooting there was lxpanel with the same menu that jwm had. :) Almost. The Desktop menu had a sub menu also named Desktop and it wasn't inlined like it is in jwm. I assume menu-cache does not respect the inline limit menu element. The extra Desktop label was the fault of the directory file already in Puppy. Later on I edited the abiword.desktop file in root and those changes appeared in the lxpanel menu a few seconds after the file was saved and fixmenus was never used.

I also tested your generator and fixmenu scripts in lupu 5.2.8. They worked perfectly there. I wish lupus openbox supported menu icons.

I want you to know that I appreciate the work you did here. Even if it never gets into a “official


musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#10 Post by musher0 »

Hi, Mobeus.

Maybe I did miss something. Here's a screen capture. Maybe you can tell me what is wrong. As it is, I only get a non-alphabetical re-arrangement of the jwm menu, not an improvement. (IMO)

Best regards.

musher0
Attachments
result-mobius-system.jpg
(51.62 KiB) Downloaded 2071 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Mobeus
Posts: 94
Joined: Thu 26 Aug 2010, 15:49

#11 Post by Mobeus »

Hi musher0

Nothing is wrong. Read on, please.

First, are you using an ‘official’ Puppy with unmodified menus?

Also, did you install these files?
/usr/local/lib/X11/pixmaps/applications-other.png
/usr/share/applications/AA-Strange-Program.desktop
/usr/share/desktop-directories/Puppy-Other.directory
Curious because I don’t see the “Other
/root for the home team

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#12 Post by musher0 »

Hi.

I routinely use esmourguit's localization of the jwm menu for French. I remember I also tried technosaurus' menu tools a while back on the same Puppy. So there might have been interferences.

I'll retry on a "virgin" Puppy wary 5.5 and see how it goes.

Talk with you later. (TWYL).

musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

R-S-H
Posts: 487
Joined: Mon 18 Feb 2013, 12:47

#13 Post by R-S-H »

Mobeus wrote:For example, here is a .directory file with [fr] localization:
Code:

[Desktop Entry]
Name=Sound & Video
Name[fr]=Son et vidéo
Comment=Multimedia menu
Comment[fr]=Multimédia
Icon=applications-multimedia
Type=Directory


See, no further translation needed. With a French locale [fr] gnome-menus will select the proper language strings for the menu name and tooltip. If no locale strings are in these files then the menu will be in English. The same applies to the .desktop file for a program. All menu localization should be in the .directory and .desktop files.
Hi!

It's exactly this way, I'd it realized in LazY Puppy for the German Menu Categories and Menu Entries. LazY Puppy is using Openbox 2.0.3 on which I found a problem when using this for foreign languages:

- when entering the same name for sub-categories (f.e. having a sub-categorie 'Werkzeuge' for Office Tools and also a sub-categorie 'Werkzeuge' for Graphics Tools, then both sub-categories 'Werkzeuge' will show the exactly same content (iirc it was the content of the sub-categorie 'Werkeuge' last included into the Openbox menu pipe/structure.

So, for Openbox (can't say anything about newer versions) i would recommend definitely a use of unique names for each sub-categorie.

RSH
[b][url=http://lazy-puppy.weebly.com]LazY Puppy Home
The new LazY Puppy Information Centre[/url][/b]

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#14 Post by musher0 »

Hello, people.

The following is somewhat off subject, I know, but it may still have a bearing on the main subject, because the problem is not only production of a unique standardized menu for all window managers in Puppy.

~~~~~~~~~~~
It is my experience that unilingual English-speaking programmers do their best in this matter -- you can see this by the quality of their code --, but, unfortunately, they cannot evaluate the result properly, because they do not speak the language. So, many localization errors seep through.

You may want to try a variant of the following to get proper localization of names -- whether of programs or categories.

Code: Select all

	# ce qui suit par musher0
	NAME="`grep -w \"Name\[${LANG:0:2}\]\" $DESKTOP_FILE | cut -d= -f2`"
	[ "$NAME" = "" ] && NAME="`grep -w Name $DESKTOP_FILE | cut -d= -f2`"
	# fin de l'ajout par musher0
(Where $DESKTOP_FILE = some *.desktop file in /usr/share/applications folder.)

The above tries to find a localized name of program. If the localized name does not exist, then it uses the default English name.

The above solved a squishing problem in technosauraus' jwm-create-menu tool. In technosaurus original code the name-find routine was

Code: Select all

		case $LINE in
			Name=*|Name?${myLANG%_*}?=*) NAME="${LINE#*=}"'' ;; # sc0ttman... should use "Name[$myLANG]=" if found
			#Name=*) NAME="${LINE#*=}"'' ;; # aragon: only main language
That code found the localized name but squished it with the default name.
aragon (author of various "spm2" menus) had seen the problem.
~~~~~~~~~~

Submitted for your "meditation" only. :)

TWYL.

musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
lvds
Posts: 340
Joined: Tue 23 Jan 2007, 15:15
Location: Near the window

#15 Post by lvds »

Mobeus wrote: Puppy should follow the menu standards. Even experienced Linux users are confused by Puppy’s menu system.
+1 Many many thanks for you work ! That is something I had dreamt off since the days we built the xdg compatibility !

We need this to become standard in future pupplets. Did Barry said something about integration on future releases ?

Thanks again :-)

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#16 Post by 01micko »

Hi Mobeus,

I like it! I gave it some brief trials, and when I get a bit of time in about a month or so I'll probably whack it in a thinslacko build (which has become my favoured test bed) as the main menu generator. That way fellows like peebee can test with lxde, also icewm should run fine maybe some others. (there is a fluxbox official slacko pet, created by dejan555).

Cheers
Puppy Linux Blog - contact me for access

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#17 Post by peebee »

01micko wrote:Hi Mobeus,
I like it! ..... I'll probably whack it in a thinslacko build .... fellows like peebee can test with lxde
Cheers
I'm up for experimenting and testing....I'm following the thread....
Cheers
peebee
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
oldyeller
Posts: 889
Joined: Tue 15 Nov 2011, 14:26
Location: Alaska

#18 Post by oldyeller »

Hi Mobeus,

Which tar.gz do I need to compile? and do I need all three? I did the manual moving of the files. This is a very promising fix to the menu 8)


Cheers

User avatar
Mobeus
Posts: 94
Joined: Thu 26 Aug 2010, 15:49

#19 Post by Mobeus »

Hi everyone,

Sorry for not getting back sooner, been offline for a few days.
lvds wrote: Did Barry said something about integration on future releases ?
As far as I know, Barry is unaware of this thread.

@01micko, peebee
Sounds good. I'll be patient.
oldyeller wrote: Which tar.gz do I need to compile? and do I need all three?
implementation.tar.gz has everything in it to implement the menus. If for any reason the /root/my-applications/bin/gen_pup_xdg fails to run for you then you would need to compile the source-gen_pup_xdg.tar.gz source with BaCon BASIC version 2.0 build 1 or greater.
/root for the home team

User avatar
lvds
Posts: 340
Joined: Tue 23 Jan 2007, 15:15
Location: Near the window

#20 Post by lvds »

Mobeus wrote:Hi everyone,

Sorry for not getting back sooner, been offline for a few days.
lvds wrote: Did Barry said something about integration on future releases ?
As far as I know, Barry is unaware of this thread.
would be great to bring it all upstream for the next puppy release ;-)
great work

Post Reply