On September 25, 2005 15:32, Decklin Foster wrote: > How feasible is it for gdm or kdm to write a menu method, as wms do? Is > there some reason this needs to be part of the grand plan for menu? This is interesting. menu-xdg might be the place to add the capability to auto-generate .desktop files, which could then be installed under /var somewhere. The modifications then required for kdm and gdm would be minimal. But menu and/or menu-xdg would have to gain the ability to clean up after itself. Currently, if a KDE or GNOME user installs the menu package, they will gain, tacked onto their regular desktop menus, a Debian menu. Removing the menu package does not result in the Debian menu disappearing from the sight of the user, however, because the files created by the menu-xdg method have no way of knowing that menu isn't around anymore. There the menu stays, getting ever more out of date. Similarly, a collection of auto-generated .desktop files would need to be cleaned up in menu's postrm, or else more elegantly through some currently unavailable (correct me if I'm wrong here) mechanism of the menu system itself. Furthermore, kdm/gdm would need the menu/menu-xdg packages for full functionality, which would not please some people, myself included. But what would be the benefit of all this cleverness be? Easier, internationalization, perhaps, when that arrives in the Debian menu system. Otherwise and until then? Quoting from Bernhard R. Link's list of alleged problems with the current situation, from another post, until otherwise noted: > * It adds additional burden for Debian. Maintainers have to make sure > another path is correct, another descriptions fits to another format. It is very, very little effort. Examples abound. I'm really having trouble seeing the problem here. > * It adds another burder for those administrating Debian machines, > as there is another format for those to learn when they want to > add another window manager, or change the description of some > windowmanager, or hide away a window manager from the users. Freedesktop.org is here to stay. When the admin wants to customize anything related to KDE or GNOME, they'll have to learn it. Of course, nothing is forcing them to use kdm or gdm, and if they want to hide a window manager in kdm/gdm, they can remove its .desktop file. If that isn't satisfactory, then the place to deal with it is with the kdm and gdm upstreams. I have yet to hear sysadmins complain about the burden imposed on them by blackbox, fluxbox, windowmaker, icewm, xfce4, etc. etc., which already provide .desktop files. > * It makes it harder to add a proper solution: > Unless there is a common way to tell in the menu registry, that > there is already a .desktop files, display managers supporting > those files and also supporting the Debian menu will either have > to disable the .desktop files or will have multiple entries, unless > they do some inteligent matching. (And as we all know, > inteligent means it might fail). "Might fail", like some hack to auto-generate .desktop files might fail, or cause problems, or impose limitations? On September 25, 2005 15:32, Decklin Foster wrote: > I don't particularly have a problem with writing these files myself, but > I am reasonably certain 99% of my users do not use or have any desire to > use gdm or kdm to manage their sessions (read the package descriptions > for 9wm and aewm). So, these files will eventually suffer from bit-rot > as no one will be looking at them or notice when they get out of date. > (Yes, I know that in theory no effort is supposed to be required to > maintain such a file once it goes in, because they're supposed to be > valid forever, but we all know that never ends up being true.) If you, the maintainer, who know your own package best after all, feel that your users are highly unlikely to benefit from a .desktop file, or it just isn't applicable to your package, then certainly the reasonable thing to do would be not to provide a .desktop file, and perhaps even close the wishlist bug as invalid. I'll certainly take no offense :) As for the bit-rot issue, I would respond that while you are right in pointing to bit-rot as a risk, some or occasional bit-rot is nevertheless better than no attempt at support at all, which is what we have currently for the packages on which I filed wishlist bugs (for gdm, anyway: kdm, as I've mentioned, has its own files for the time being, but they are also bit-rotting quite badly and it is not really appropriate or easy for the KDE maintainers to maintain them all, which is what I personally am trying to do for the time being). > If this *really* is widespread practice and it *really* is intractable > for dms to do it (is it?), then maybe this should go into Policy, so > there is a reason to write linda/lintian tests (like those that cover > bad menu files), and for people who do not otherwise care to pay > attention. (If I had the time and energy to hack on aewm, there are > plenty of other freedesktop.org standards which would be much higher up > on my list, and some of them are even suggested by Policy.). My feelings on the whole matter, for what they're worth, is that this really isn't appropriate for Debian policy, but is rather a quite normal category of request, specifically in this case for some maintainers to support freedesktop.org display managers. Analogous to asking the totem maintainer to have their GNOME menu entry (freedesktop.org desktop menu entry, to be precise) include an nice icon* (OK, that's a little extreme, but not by much). Just a minor wishlist itch related to usability, one which a number of maintainers have already kindly addressed for their users in the obvious, easy, and fd.o standards-compliant manner. None of this outright precludes the creation of a Debian policy, to be sure, if people feel that the existing situation (which my efforts would obviously entrench) is deeply problematic and would merit a new and formal structure being imposed, but I've yet to read any really persuasive reasons why such a policy would be worth the hassle. And I strongly suspect that the changes Bernhard are suggesting would be far more work to create and even to maintain, than a few maintainers each providing a ten-line file in their window manager packages, which are quite unlikely (I grant that nothing is certain) to need frequent or substantive changes. But if people are up to the job, and would like to volunteer to extend the Debian menu system and/or menu-xdg, then I wish them luck. Cheers, Christopher Martin * It has a very nice icon, thanks, this is just a random example.
Attachment:
pgpZrLKg0EWSb.pgp
Description: PGP signature