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

Re: Debian Menus (Was: Re: [PROPOSED] moving the menu hierarchy into debian policy)

Hash: SHA1

Okay, it's replying time (now that I tried to understand the menu
system... :-})

>>>>> "Fabien" == Fabien Ninoles <fab@tzone.org> writes:


    >> 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

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

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
Version: GnuPG v0.9.4a (GNU/Linux)
Comment: For info see http://www.gnupg.org


Reply to: