[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: adding desktop files to misc packages

On Sun July 15 2007 07:19:45 am Josselin Mouette wrote:
> Le dimanche 15 juillet 2007 à 14:11 +0100, Neil Williams a écrit :
> > Why not drop the Debian Menu Policy completely? The only sane
> > argument against .desktop is hierarchy support but then the most
> > pertinent complaint against menu is that the hierarchy is wasteful.
> The Freedesktop menu has hierarchy support, but it's much more clever
> than the Debian menu's.
> The most important argument against it is more about window manager
> coverage. There are a good number of packages with Debian menu
> support and no Freedesktop menu support.


If by "drop the Debian Menu Policy completely" you mean adopting 
Freedesktop's .desktop file format, menu hierarchy rules, and whatever 
tools they have for working with menus---sure. From an enduser's 
perspective it doesn't matter what lies beneath the menus we see[1], if 
you DD's decide the Freedesktop way is the better one for packaging 
menu entries then so be it.

If you are suggesting dropping the Debian menu infrastructure as well, 
therebye forcing the other window managers to learn how to 
read .desktop files or convert them into their native format on their 
own time---that sounds like a bad idea. I would hate it if my 
lightweight and fast wm suddenly started using more RAM, took longer to 
startup, or if the menus became as sluggish as KDE's[2]. Since the 
conversion route is likely to be a popular solution and lengthening 
startup time is the least objectionable (both could be done without 
touching the wm's code), there would be a significant amount of code 
duplication happening and therefore pressure to devise infrastructure 
which does a good chunk of what the existing menu system does now. 

AFAICT, all potential benefits from this last kind of change favour the 
few window managers which natively "speak" .desktop, and everyone else 
gets the undoubtedly shitty end of the stick. Furthermore, it seems 
really odd to potentially shift onto, or create work for, all the 
lighter weight window managers, likely to be running on less capable 
than average boxes, for the benefit of window managers which pretty 
much require a box of average or better capabilities. IOW, if there are 
hoops to be jumped through to get a better menu subsystem then it is 
best to put those hoops into the arenas most likely to have enough 
spare resources to do the jumping.

I would think that would be enough to place the idea of dropping the 
menu infrastructure in the non-starter category, but obviously it isn't 
because "window manager coverage" is an issue. I mean, if simply 
changing the menu infrastructure to use .desktop files as input is what 
is on the table, then presumably all window managers will need to 
change the way they do things and any "coverage" problems will be 
temporary ones which could affect any wm while the Maintainers rewrite 
their menu generating code.


If I am understanding you correctly then I must say that "window manager 
coverage" is more than just "the most important argument against", it's 
a TKO for the idea (see above for why I believe that).

I believe I am understanding you correctly because, "Debian menu support 
and no Freedesktop menu support", is only an issue if the common menu 
generating infrastructure disappears and all we are left with is a 
collection of .desktop files.

I hope you reconsider your position.

- Bruce

[1] It would be nice to have a friendly Debian->Freedesktop menu entry 
conversion utility so those of us with custom menu entries and 
no .desktop experience can get a little hand holding while we make the 

[2] it has been awhile since I used Gnome but their menus used to be 
slower than KDE's, KDE's have gotten slower (and take up more HDD 
space, perhaps a consequence of the Freedesktop related stuff added to 
the menu subsystem and maybe why there has been a push to swith 
to .desktop files)... but the menus I get with UWM are always very fast

Reply to: