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

Bug#741573: Proposed draft of ballot to resolve menu/desktop question



On Fri, Aug 28, 2015 at 09:13:33AM -0400, Sam Hartman wrote:
> If we adopt Keith's proposal without updating policy 9.6--we retainIs
> the SHOULD have menu entries for all command line apps, but move the
> metadata format to .desktop, we have a number of problems.  We have no
> way to express the category information and some of the other metadata
> from the trad menu that's kind of important for its expanded scope.

> So, it's not clear what should happen.

> If we revise 9.6 and  adopt Keith's proposal then we're basically
> adopting the XDG menu's scope, but taking away the place where the
> broader information could go.

> In effect we leave menu entries that do belong on the trad menu but do
> not belong on the XDG menu no where.

> Depending on how we do things we may also significantly complicate the
> runtime dependencies of light-weight windowmanagers if we force them to
> parse .desktop files and do image conversion.


> In effect by adopting Keith's proposal with an update to 9.6, we're
> saying that as a matter of technical policy decided by the TC, there are
> some menu entries on the trad menu that do not belong on any menu at
> all.

If this is the message that the ballot option is sending, then I agree that
it's concerning.  I'm aware there are some maintainers of desktop
environments who view this as the goal; my support for Keith's proposal was
predicated on the belief that this would /not/ be the outcome, but instead
that we were describing a path forward by which existing menu system entries
would be translated into .desktop files and the semantics would be
preserved.

The XDG .desktop format allows applications to specify that they should or
should not be shown in particular environments using the
OnlyShowIn/NotShowIn keywords.  I assumed it would be straightforward to
declare a new OnlyShowIn value that menu consumers could key on if they wish
to show the traditional menu heirarchy, and that this could be implemented
without causing any problems for the existing desktop environments.

Have I overlooked something that makes this approach untenable?  Should the
ballot option be extended to make this a more explicit recommendation?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: