Re: menu-method for .desktop files?
On Tue, Dec 07, 2004 at 03:35:45PM +0100, Bill Allombert wrote:
> On Mon, Dec 06, 2004 at 11:47:16PM +0000, Peter Collingbourne wrote:
> >
> > This is a good start, now the question is how to integrate this into
> > the system.
> >
> > To tell you the truth I have also been working on a similar thing
> > separately (tested). My version is attached and it is up to someone to
> > decide which should be used.
>
> Please use mine. It has proper quoting and is in line with the other xdg
> methods. (I am the menu maintainer :).
Sure, it is no big deal but it needs some features from
my version which may be necessary: the definition of
ConfigExec/ConfigTryExec/SessionManaged for one (see later).
>
> > I believe the files should go into /etc/X11/sessions for two reasons:
> > 1. at least one of the display managers already looks in there by
> > default (gdm)
> > 2. it is in common with the majority of the other menu-methods which
> > write to somewhere in /etc
>
> It is common but this is a (mild) FHS violation: autogenerated files
> belong to /var, not /etc. However putting them in /usr would be a serious
> FHS violation, so I can live with /etc.
I agree... we can move to /var when the rest of the menu-methods do :)
>
> > Also five things need to be done in order to add this feature to the
> > system:
> >
> > 1. Create a package for the menu-method
>
> I suppose we can include it in the menu-xdg package.
Ok.
> > 4. Change the following packages so that they do not install a .desktop
> > file to /usr/share/xsessions (to avoid duplicate entries in the list):
> > gnome/gnome-session x11/blackbox x11/fluxbox x11/fvwm x11/fvwm-gnome
> > x11/icewm x11/icewm-experimental x11/icewm-lite x11/openbox x11/wmaker
> > x11/xfce4-utils
>
> I am not sure about that part. Programs messing with .desktop file need to be
> smart enough to handle conflicts/override, else it is a clear abuse of
> the .desktop specification.
...
> The best way to deal with that is to reduce the changes to the minimum
> that achieve the goal. If you can avoid the requirement of removing
> existing .desktop file, we will have 90% less work.
How would you suggest we adapt our method to deal with this? Possibly to
check if an existing .desktop is present in /usr/share/xsessions from
the same package. I believe install-menu would allow you to express that
but it seems like an ugly hack to me and might not actually be possible.
In the worst case the method could be rewritten in Perl or something
(the language of ugly hacks :).
> > Another question is: should this be mentioned in section 11.8.4 of the
> > policy manual?
>
> Certainly not yet.
I feel there are some decisions to be made at this point:
- should we deprecate /usr/share/xsessions/* files?
- should we define a menu attribute for ConfigExec/ConfigTryExec and
SessionManaged?
some of which will affect the implementation of our menu-method.
>
> > I am wondering whether I should go through the procedures necessary to
> > become an official Debian developer.
>
> Given the delay involved, that will not help.
I believe if I am going to continue development (in general, not on this
particular feature) it would be worthwhile for me to become one. I don't
just want to become a 'cheerleader' and put my coding skills to waste :)
--
Peter
Reply to: