Re: Generic "extra menus" package (was: Re: electronics-menu REJECTED (discussion))
On Mon, 14 Jan 2008, Peter Clifton wrote:
I don't think it serves the purpose, as anything configured by the
desktop-profiles would only be done at session startup time.
This is correct.
This completely breaks the use-case where:
apt-get install <application>
Will place the app in the user's expected menu, right away.
OK.
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?
Well, if you would like to try
apt-get install med-tools
(or any other med- meta package, but tools has the viewest dependencies
so will not blur your box very much) you will be asked a debconf question
which user of your system should get the Med user menu. This perfectly
works for system with say up to 20 users, but it becomes really boring
on machines with more users or if you are using LDAP or whatever.
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).
Well the user menu feature of Debian menu just creates a complete
menu tree for every installed UI on your box. It uses one single
.menu file for this but the tree is auto generated and just exists.
(The drawback of the current solution in Debian-Med which is implemented
in the cdd-common package is that this is done for every user separately
if you are using the user menu feature of Debian menu.)
The trick we are using in the cdd-dev / cdd-common framework is that
we do not write single menu entries for every single package we want
to use but instead just use the original menu file of the maintainer
and change the menu location automatically. You might like to have
a look at the output of /usr/share/menu/cdd-menu. The framework also
allows to override a maintainer menu file if it is not fit for our
purpose for whatever reason.
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.
Well, this is a general criticism of Freedesktop.Org which I would
support in principle. My problem is that we should not divert a
standard that is widely accepted with our smart tool extra-menus.
It might help our closed cirlce but will not lead to an enhanced
Freedesktop.Org standard.
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?
If you ask me I would prefer the later one because it might
enable us to establish some kind of standard. IMHO it would
require a detailed discussion and documentation and kind of
a policy which gives clear hints how to use the menus.
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.
Sure, but especially this initial state is important for the success.
I think there is some big need for a reasonable menu solution and thus
we should collect ideas and suggestions first (Charles suggested a
Wiki page) to make sure that we really are able to fullfill the
needs of the idfferent groups. If we just do a quick shot we might
blur the good idea from the beginning. (And no, I'm not a friend
of bluring things by overlongish discussions on the other hand but
rather implement a working solution - but some discussion is needed
to make sure that it will really work.)
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.
Completely agreed.
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.
Definitely.
Thanks for your effort
Andreas.
--
http://fam-tille.de
Reply to: