Re: Bug#707851: debian-policy: soften the wording recommending menu files
Hi Russ,
For clarity: I never meant to say we should hold off on discouraging
desktop files unless and until all that is available; just that we
should consider all those things too, and that (at some point) we need
to ensure we have them. Since we're discussing changing to desktop
files now, however, this seems as good a time as any to at least think
about the issues. If some of them can be implemented by adding the
correct wording to policy, then why not?
On 14-05-13 20:42, Russ Allbery wrote:
> Wouter Verhelst <wouter@debian.org> writes:
>
>> It refers to some (unspecified) window manager implementations as
>> "legacy", which I think is a no-go (if they're supported in Debian, by
>> definition they're not legacy).
>
> I think it's fair to say that not supporting desktop files for the menu
> infrastructure makes a window manager legacy at this point. I use one of
> those window managers personally, but the fact remains that this is the
> direction in which the whole desktop world has gone, and most new window
> managers, even those that aren't really trying to provide a desktop
> environment, support them to the degree that they do things related to
> desktop files.
The point that I was trying to make (but failed, I agree) is that we
shouldn't have to support "legacy" in Debian. If we decide to switch, we
should switch, and drop the old -- not talk about "legacy". That just
doesn't make any sense to me.
If a window manager in Debian is still supported, it won't be legacy,
and (if we switch to desktop files) it will support desktop files;
either through reading them directly, or through having maintainer
scripts convert them into something the window manager understands.
>> Apart from that, I would like to see rough feature parity, i.e.,
>> - support for applications which start from a terminal, using the
>> x-terminal-emulator alternative), without hardcoding the terminal
>> emulator (for pdmenu or similar things) (possibly desktop files
>> already support this; if so, feel free to just point that out ;)
>
> I'm fairly sure they do. This is the Terminal=true setting.
Good, ignore that bit then :-)
>> - per-user desktop entries (~/.menu, and update-menus run as user) that
>> are not specific to the used user interface. (same note as on the
>> previous item)
>
> Already supported, although where you have to put the desktop file varies
> depending on the environment. There is slow convergence (I think) on the
> XDG paths, but we're not there yet.
Well, if upstream is working on something, I suppose we don't need to
work on it ourselves anymore :-)
>> - an easy way for window managers that don't use the desktop format
>> directly to be told when there are new entries and they need to
>> rebuild their menu. With the Debian menu system, we have
>> update-menus which is called at postinst time (possibly by a
>> trigger, I'm not sure); there should be something similar for
>> desktop entries. This might simply be implemented by a dpkg trigger
>> that all interested window managers listen to and that
>> desktop-installing packages should emit; but we should document such a
>> procedure before making this switch.
>
> It would be ideal if we had something like this in place, but the reality
> of the situation is that we're already making this switch, and no one is
> stepping forward to do this work. At some point, I think it becomes the
> obligation of the fvwm (etc.) maintainers to do this work if they want to
> see it done, rather than asking the GNOME and KDE and Xfce maintainers to
> write code for window managers they don't use and don't support in order
> to move forward with their upstream direction.
I didn't mean to imply someone other than the relevant UI maintainers
would need to write code for this to happen; we could simply add some
wording along the lines of
packages that install desktop files must emit the
``desktop-files-installed'' trigger from their postinst (e.g., by
running ``dpkg-trigger desktop-files-installed''), so that user
interfaces which don't support desktop files directly can listen to
this trigger and update their menus.
That still leaves the actual implementation up to the maintainers of the
relevant window managers, but clarifies how it would be implemented
technically.
[...]
>> Moreover, we should have clear policies on what the contents of a
>> .desktop file should look like, that goes way beyond just a vage URL
>> over at freedesktop.org. Specifically, we need:
>
> The URL is really not that vague, speaking as someone who wrote the
> Lintian validation code based on the specification.
It is vague in that it's just a URL to an external specification for
something that we'll be using quite extensively. I haven't read the
actual specification, but I think the two things I pointed out are
things that should be specified in policy rather than be "specified" as
"do whatever it is that upstream does, we don't care."
>> - a replacement for our current menu policy which explains which types
>> of applications will go where. Consistency across user interfaces is a
>> *good* thing, and to get that we'll need to make some decisions
>> ourselves, sometimes overriding upstreams. That should obviously be
>> the exception rather than the rule (i.e., we should construct
>> something that would allow us to keep "most" upstream desktop files,
>> for whatever definition of "most" makes sense). Consistency across
>> choice is one of Debian's strengths; we should strive to keep that
>> feature.
>> - A decision/clarification on what will happen when a desktop file
>> contains the "only show this in GNOME" feature (with which they
>> *actually* mean "don't show this in KDE") and the user interface in
>> use is neither of those two.
>
> I don't think either of these are related to this bug. We already have
> tons and tons of packages with desktop files, so to the extent that these
> are issues, they're already issues.
Yes, but not so much so.
Most environments that use desktop files today have some filtering
mechanism so that only the desktop files relevant to that environment.
As such, they're consistent, because they're internally consistent.
If we're going to switch to desktop files as the way to specify a menu
entry, that will mean that some applications which are currently only
added through a menu file will get a desktop entry instead, and that the
Debian maintainer of that package will need to write a desktop entry.
Alternatively, it might mean that the upstream "example" desktop entry
(which was cobbled together with some quick copy-and-paste) will be
installed (where it previously wasn't), but that its quality might not
be what would be desired. As a result, there will be more items in some
menu systems. Some consistency is important there, and we need to ensure
that policy encourages such external consistency.
[...]
> There is an existing fdo standard for what categories to use in what
> situations, and while it's not as detailed as one might like, it's
> workable. It might be worthwhile linking to it directly, although I think
> the desktop file spec already does.
I certainly never said we need to write that ourselves if it already
exists :-)
Linking to it explicitly might make sense then, indeed. Even if the
desktop file spec already links to that, I think it makes sense to
explicitly say "we care about consistency in categories, and here's the
list of categories you should use". If we later on decide to add
additional categories that the upstream fdo spec doesn't list, we can
always add our own categories to (a sub-)policy.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Reply to: