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

Re: Bug#330064: wm2 should provide a session file for kdm and gdm



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: pgphXeArDf9ll.pgp
Description: PGP signature


Reply to: