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

Bug#741573: Two menu systems

Colin Watson <cjwatson@debian.org> writes:

>  * There's no reason that "has a .desktop file" should imply "shows up
>    in modern desktop environments", and so I think that the question of
>    coverage is to some extent a red herring; the systems have different
>    coverage because they've always had different coverage, not because
>    the .desktop format is inherently unable to meet the needs of trad
>    menu consumers.

That's my view -- the two systems are split because they use a different
file format, and not through any carefully considered reason.

> On the other hand, Keith's draft seems highly aspirational to me.  While
> it seems to me to be broadly the right kind of long-term technical
> direction, there is an awful lot of work in there for people who want
> something like trad menus which is being glossed over.

I think the only piece of work necessary is to add support for .desktop
files to the 'menu' package. With that, other packages are free to
transition from menu files to .desktop files and any existing menu
programs will continue to work as before, while .desktop file consuming
menu programs will slowly see more and more applications to present.

> So, I prefer Ian's position in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the
> purposes of how the policy text should remain for the time being, and in
> terms of the philosophy of not ripping out work from under people's
> feet.

I guess I'm not sure what work we're ripping out from under people's
feet here. The only significant change proposed is to require support
for .desktop files in the 'menu' package. I would imagine that the
simplest way to add .desktop file support to the 'menu' package would be
to translate .desktop files into menu files and process those through
the existing code base.

> I prefer Keith's position as a long-term direction, but agree
> with Ian that it is lacking an awful lot of transitional thought, and
> feel that it has a lot of things-should-be-done without it being clear
> who will do them.

I feel like there's a mis-characterization of what it would mean to
switch to .desktop files, and whether the change would need to be
all-at-once or could be done incrementally. Here's the transition that I
imagine would occur:

 1) Support for .desktop files is added to the 'menu' package. This
    ensures that applications providing only a .desktop file would
    continue to appear in menu programs using the existing menu package

 2) Packages would be encouraged to transition to shipping only .desktop
    files. Over time, more and more would start to appear in menu
    programs with native .desktop support.

 3) .desktop-based menu program users would start exploring the broader
    range of applications shown to them and enjoy the benefits of this
    broader selection of tools.

None of these steps places any specific burden on developers, although
skipping step 1) would regress menu programs using menu package support,
dropping any programs which choose to not ship a menu file. I would
expect that to be sufficient incentive for the 'menu' package to add
.desktop file support though.


Attachment: pgpwlYRW5Tgfu.pgp
Description: PGP signature

Reply to: