Re: [proaudio] Thoughts about menu entries and usability

[Dominique Michel <dominique.michel@xxxxxxxxxxxx>]

Le Wed, 7 Feb 2007 11:17:12 +0100,
Thomas Kuther <gimpel@xxxxxxxxxxxxxxxx> a écrit :

> On Mi, 07.02.07 10:47 Frieder Bürzele <evermind@xxxxxxxxxxxxx> wrote:
> 
> > Thomas Kuther wrote:
> > > Hi all,
> > >
> > > I'm currently looking at the mess in my default "Sound & Video" FDO
> > > menu (E17 and XFCE here) - proaudio stuff chaotically mixed with
> > > video and audio players, ripper, encoding stuuf..and the idea comes
> > > up to create a nice menu, e.g.
> > >
> > > 	menu root
> > > 	--> Sound & Video
> > > 		--> Pro Audio
> > > 			--> Sequencer
> > > 				- Aldrin
> > > 				- LMMS
> > > 				- MusE
> > > 			--> Sythesizers
> > > 				- ZynAddSubFX
> > > 				- OmSynth
> > > 			--> Recording
> > > 				- Ardour
> > > 				- ReZound
> > > 	etc etc.
> > >
> > > I know KDE and GNOME users can edit their menu as they like, also
> > > E17 and lots of others, but e.g. XFCE 4.4 doesn't seem to provide
> > > that advanced menu editing..
> > >
> > > So I could do this on my own... or for all in a maintainable way,
> > > which means adding a package, e.g. "x11-misc/proaudio-menu"
> > > something like that which adds required default menuicons and
> > > generates the submenus (there are eclass funcs for "domenu" etc, so
> > > that wouldn't be hard), and an eclass, let's say proaudio.eclass
> > > that takes care this package is installed and provides some
> > > functions.
> > >
> > > But what do users and devs think about this?
> > >  - that sucks, mess around on your own box
> > >  - good idea
> > >  - i don't care
> > > :)
> > >
> > >   
> > 
> > We'll thats really a good idea.
> > I don't know if I get you right: You want to create a ebuild which
> > generates entries for xfce4.4? from existing .desktop entries?
> 
> No, the idea was to provide a more
> advanced /etc/xdg/menus/applications.menu which provides this menu
> structure, but the more i looked into it, the harder it seems to do,
> because that would mean a) overwriting the default one from xdg-utils,
> or b) letting the user copy it to ~/.config/menus manually.
> 
> And that would work for any WM with FDO compilant menu, like XFCE and
> E17.
> 
> And well, some default gtk theme icons for those submenus.
> 
> But this seems a bit hard to do in a fashionable way... overwriting the
> default applications.menu is impossible with
> FEATURES="collision-protect" and a very bad idea anyway, and an ebuild
> just for an example applications.menu the user would have to copy over
> manually would be overkill. We could post this at the wiki :P
> 
> > I've seen you've added some make_desktop to some ebuilds.
> > So first we need to update any ebuild and provide a proper entry?!
> > (as long as the application won't provide one itself)
> > 
> > hm should we abstract these make_desktop and newicon into a eclass
> > function? so we needn't bother about the details?
> 
> Those functions are available from the eutils.eclass already.
> But what we could do, is to keep an eye on correct FDO categories like
> shown in the links I postet, like for example
> "AudioVideo;Audio;Sequencer" for lmms and museseq, or 
> "AudioVideo;Audio;Recorder" for ardour
> 
> That in combination with a custom ~/.config/menu/applications.menu
> will provide a more clear menu. AFAIK GNOME, XFCE and E17 can use this.
> KDE seems to do things a bit more advanced, FVWM as dominique said
> doesn't care of FDO menus at all, hmm..
> 
> 
> BUT as said, first there was the idea (which I posted right away
> here :P), and then I started looking how things could be done, just to
> see it's not sooo easy, hehe. Because this freedesktop.org menu stuff
> is a bit weird..
> 
> 
> > Greetz Frieder
> > 
> > 
> > > Any comments on this are welcome.
> > >
> > > Regards,
> > > Tom
> > >   
> > 
Debian have a different approach. Desktop as gnome or kde use the .desktop file
and they have a "menu" package that generate the entries for all the installed
wm. This menu package is not mandatory, but it help a lot with non freedesktop
compliant wm.

I was looking at it it was some time ago, but my programmers skills are too
limited and it need a rewrite to be adapted on gentoo. The interesting part is
how it work. "menu" provide:
- a general API to generate the menu entries
Each wm provide (added in Debian):
- an API for its menu structure, API used by "menu".
Each software package provide:
- Some entries in clear text that can be used by "menu" to generate the entries
for all the installed wm. (For the GUI applications and for some console apps
as mc)

And "menu" can be called at any time to re-generate all the entries for all the
installed wm.

I take a look of what they done for FVWM and FVWM-Crystal. It is in fact the
most complicated case because "menu" have to generate not only the menu entries
but also the icons (FVWM use xpm icons). 

I think at it must be possible on gentoo to use the informations in
the ,desktop files to get the needed informations for the menu generation (at
least for Crystal, the whole applications menu reside
in /usr/share/fvwm-crystal/fvwm/Applications and
~/.fvwm-crystal/fvwm/Applications, when it reside in the user configuration in
fvwm... ... ...(Debian use some kind of trick here, but don't ask me more...).
Current console programs as mc are already in crystal.

Remain the problem of the icons. Maybe use a script that will check for the
program name and search an icon of the same name and convert it, even if it
can be slow.

Another problem both for the .desktop files and for fvwm.crystal menu and icons
generation is at the .desktop files and the icons files can be in many places.

I am also not sure if crystal respect the menu hierarchy of freedesktop. To
check it is on my TODO list (I don't think so).

Ciao,
Dominique