Re: Generic "extra menus" package (was: Re: electronics-menu REJECTED (discussion))
On Mon, 2008-01-14 at 10:53 +0100, Andreas Tille wrote:
> On Sun, 13 Jan 2008, Peter Clifton wrote:
>
> > http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0-1.dsc
> > http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0-1.diff.gz
> > http://www.srcf.ucam.org/~pcjc2/debian/extra-menus_1.0.orig.tar.gz
> >
> >
> > I'd appreciate it if those who were advocating this approach on IRC
> > could check over the package, and see what they think.
> >
> > Do I need an ITP bug to proceed?
>
> Well, I would strongly suggest to verify desktop-profiles before
> proceeding in this direction. I don't think that it is productive
> to invent something new if there is something that might be serve
> perfectly for the purpose.
I don't think it serves the purpose, as anything configured by the
desktop-profiles would only be done at session startup time.
This completely breaks the use-case where:
apt-get install <application>
Will place the app in the user's expected menu, right away.
Referring to your previous email, where you state the "currently used
user menu solution is suboptimal because it does not scale", could you
clarify what exactly you're meaning there, and just how much scalability
you think we might need?
If we assume that more than one application group needs to install a
menu, using desktop-profiles will introduce an entire extra hierarchy of
XDG or KDE structure which must be searched through at run time. (Rather
than just one extra .menu file per menu).
>From the desktop-profiles manpage:
"If two profiles contain the same config file, the one from the profile
with the highest precedence is used."
You STILL have to use the XDG menu merging mechanism, otherwise the
desktop-profile will over-write any "master" applications menu file.
The XDG menu spec (although it has _badly_ thought out categories), does
has the capability to allow these menus to be installed directly.
Requiring a new desktop-profile just to have a schematic editor or other
CAD program appear in a sensible place does not seem the way forward.
"Ham radio" already uses the XDG "merged" mechanism, and I propose to do
the same with "Electronics". Wine uses it too (although has the luxury
of being able to "own" its own menu directly - rather than needing a
category registered on its behalf).
If we also bear in mind that any menus added won't appear unless there
are applications installed which list these categories, there is no harm
in just installing them (if their numbers are low enough).
The original argument from ftp-master was simply that he didn't want to
allow lots of small packages to install categories individually, and
that they should all be lumped together in one "extra-menus" type
package. (+ some option of configuring the installed menus on/off)/
IMO this kind of breaks the point of packaging different things in
different packages, especially if we have to provide infrastructure for
"sub-package" management locally, ie.. for the user to turn parts of it
on / off.
My opinion is that we are only discussing how
the /etc/xdg/menus/appliactions-merged/*.menus get installed:
Is it with one debian package per category / menu someone might want to
install, like "hamradiomenus" and my "electronics-menu" package?
Is it in one master package such as the "extra-menus" package I have
presented, which will aim to collect all such menus across Debian and
install them in one hit?
(And may provide run-time scripts for the user to add/remove the
symlinks as desired).
At the moment, we are talking about two packages, with the possibility
of some scientific interest groups benefiting from extra categories too.
It is not as if we're designing some GNOME API which will be set in
stone forever.. we can always change things if it becomes necessary.
If some tens of interest groups find their applications don't fit in the
normal XDG categories, THEN is the time to worry. Specifically, if the
problem DOES scale to such a size, then it is a concern which might need
to be addressed with an update to the XDG menu spec.
What IS clear, is that sensible defaults must be provided with no more
complexity than "apt-get install <application>" . The user mustn't be
made to work for their menus.
Best wishes
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
Reply to: