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.
Neil,
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.
Josselin,
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
switch.
[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: