Re: Debian Menus (Was: Re: [PROPOSED] moving the menu hierarchy into debian policy)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Okay, it's replying time (now that I tried to understand the menu
system... :-})
>>>>> "Fabien" == Fabien Ninoles <fab@tzone.org> writes:
[SNIP]
>> Instead, we should make it editable... such that, when the user
>> first opens the menu, there are some (limited) defaults, like,
>> one *std* app for each category (or maybe two)[1].
Fabien> I disagree with this. For the common purpose, I just don't
Fabien> install thing I don't need. Must entries in my menus are
Fabien> entries that I need. They're just lost in the jungle of a
Fabien> too much generalize section like Tools or Net.
You point is pretty much correct for a single-user machine. I'm the
only one on my system too, but I try to look at things from the
perspective of an admin of a multiuser machine.
And in that case, there can be lots of apps, with most user not being
interested in most apps (as an admin, I'd try to make my users happy
(I know lots of admins don't see that as their mission), and if any
user would ask for a package, I'd install it most of the time (if it
was trustworthy, that is... .debs tend to be))
[SNIP stuff about default root menu]
Fabien> I don't think this is control by the menu system in
Fabien> general. I think it's a setup made by each WM maintainer
Fabien> for the menu system. e.g. E get it's logout in the root
Fabien> menu. With a Default Apps menu, a Gnome menu, *and in the
Fabien> Gnome menu*, the Debian menu.
Looking at the menu system docs, I agree... so, I think this is one
thing that needs to be policy-cized (that a word?)... maybe an admin
can switch between a Debian-std-root-menu and a WM/DE specific (he
will NOT have to choose on installation... we're trying to get away
From that, right?).
>> + Config This Menu... okay, maybe a Config menu, with entries
>> for all relevant stuff. Including, of course, the general
>> Debian menu editor.
Fabien> Gnome has such an entry but not all WM follow this
Fabien> strategy. I agree however that having a Debian menu editor
Fabien> will be a good thing. Take in mind however that we can't
Fabien> make an editor for all aspect of menus in all WM
Fabien> (especially for specific functions like exit or restart).
I think we can... it should be rather simple. I mean, it *is* done by
the menu system right now, right? So, we just need to separate the
system default menu from the one users use. The user-specific
(created by the DRME (Debian Root Menu Editor) ;-) is also created by
update-menus...
Basically, what the DRME does is present a nice (understandable ;-)
interface to update-menus/install-menu.
>> I think this would make much more sense than the current `group
>> by where it is in FTP'. We really should group by what it
>> does, and be more intelligent about this.
Fabien> Hum... isn't what the menu system currently allow? As far
Fabien> as I know, the current division of the menus is slightly
Fabien> different from the one of the package sections.
I think this is because both are not ideals ;-) So the creators of the
menu system (or rather, lacking policy, the package/wm maintainers)
chose some hierarchy, similar but not identical to the ftp tree.
>> Yes, I know there's no such thing as a Debian Menu Editor. But
>> I think the menu system needs to support editing/customizing
>> the menu hierarchy for this to be really useful.
>> The menu that is displayed needs to be separate (on a per-user
>> basis) From the menu hierarchy in which packages install their
>> entries/menus.
Fabien> Completely agreed with you. Currently, you can get a
Fabien> per-user menu but they're no easy way to add the Default
Fabien> menu in it (Or I don't know it). In addition, the users
Fabien> menu are not update System-wide, update-menu should be run
Fabien> by the user each time he want to update. I think this
Fabien> should be an option.
So we're in agreement here... the biggest problem I see (from taking a
long, confused, look at the update-menus docs) is that this system is
meant for developers. Users need to dig into text files with a pretty
obscure structure[1]
>> The menu editor would then show the hierarchy of installed
>> apps/tools/etc, and the menu as currently configured, and the
>> user could copy entries or whole menus between them...
Fabien> For a good implementation of the menu system, I suggest
Fabien> you to take a look at the KDE menu editor. I think also
Fabien> the gnome system have something similar (I don't try it
Fabien> yet).
I hung around the GNOME crowd when it started, but I've lost interest
when I realized they essentially want to clone Windows...[2]
>> Also, this would make adding locally installed packages easier.
Fabien> For this, equivs is still the best.
I really need to get to try the youngest version soonish...
>> [1]We should generalize mime-types and alternatives: both are
>> priority-based. For the menu hierarchy, this means the top priority
>> apps of each category (and the top categories) go into the default
>> menu.
Fabien> Please, don't mix them all. Program I used for viewing documents
Fabien> [mime-types], aren't the same that I used currently [alternatives] and
Fabien> I still want all of them in my menus. When I used one more often then
Fabien> the other, either I add a special local menu entry, or add a Dock/panel/
Fabien> launcher/shortcut entry on my desktop.
Oh, I see... you're right on that one. But I do think multiple
(currently two, I think) similar, but independently implemented,
systems for essentially the same thing (finding out what is the
favorite item of a list of items) is stupid. IMHO, they should be
integrated...
I do think most people have a preference for app A, no matter what A
is being used for. But different priorities for the same app,
depending on what it is used for, should be possible anyway
(configurability is always A Good Thing(tm)).
Of course, all this depends on: a) people doing the work, and b)
people (maintainers) apopting the changes for their packages.
But I start rambling, so I better stop here... ;-)
Bye, J
[1] Yes, obscure... and I've got quiet a lot of years of
experience... so, what would a typical Windows user say to that? ;-)
But Windows user or not, a USER should not have to deal with these
files... they are just to cryptic for that.
[2] "Dem's fightin' words" the GNOMEs shouted, kocked him out and
dragged them down into their caves...
- --
Jürgen A. Erhard eMail: jae@ilk.de phone: (GERMANY) 0721 27326
My WebHome: http://members.tripod.com/~Juergen_Erhard
GNUstep - Free OPENSTEP (http://www.gnustep.org)
Codito, ergo sum - "I code, therefore I am" -- raster@redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.4a (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjcg7hgACgkQN0B+CS56qs0cqgCdGskph1zPKIRZy5cxd238K1vZ
/IwAn0S5Wawt+1CN1an67k6cta4J6i7a
=xtkW
-----END PGP SIGNATURE-----
Reply to: