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

Bug#741573: Two menu systems



Steve Langasek writes ("Bug#741573: Two menu systems"):
...
>  - What *I* want is for the TC to take a principled stand on the point that
>    the policy manual exists to describe distribution-wide integration
>    policies, instead of taking a "there's more than one way to do it" easy
>    way out.

Taken to its logical conclusion, this suggests that we should throw
Python out of the archive because Perl does much of the same tasks.

My view is that the trad and desktop menus serve different functions
for different sets of users.  They are superficially similar but for
the reasons I have explained merging them doesn't make sense.

>  Over the lifetime of this disagreement, I have repeatedly heard
> claims that the Debian menu system should not be exposed at all in
> e.g. the GNOME desktop because it's "full of junk" (paraphrased).

But it is this very comprehensiveness which makes the menu valuable to
other users (such as Matthew Vernon who has posted earlier in this
thread).

Now it might be possible to have one file format and some kind of
filtering approach so that users who want to see a comprehensive menu
can have one, and users who want a more aggressively curated menu see
a subset.

But there are other differences between the two menu systems: they
tend to be preferred by different groups of people who use different
menu consumers, with different capabilities and restrictions.  Even
leaving aside differences of preference in categorisation, the
categorisation of a comprehensive menu requires a different approach
to the categorisation of smaller menu.

The two communities seem even to have a different view about what
should go in the name of a menu entry.  Desktop environment folks seem
to prefer to emphasise descriptions of the functionality ("image
viewer") whereas in the trad menu the names of programs are more
prominent.

So I think even if these two systems used identical technology, you
would still end up with either two parallel sets of menu entry files,
or one set of files containing two parallel sets of metadata (two
titles, two categorisations, different filtering information, etc.)

Under these circumstances it doesn't seem sensible to me to try to
enforce a merger, even from a technical point of view.

(Of course we could have only one set of metadata and invite a battle
between the two camps to make the one menu look like they think it
ought to be, which would be even worse.)

Ian.


Reply to: