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

Re: Debian menus policy



Craig Dickson wrote:
> 
> Erik Steffl wrote:
...
> >   in addition to that IMO it would be good to have better menu structure
> > so that the programs are not randomly all over place (just look at the
> > menus of any system that has large number of programs installed, it's
> > even more chaotic when you enable hints) - just take a look at it, it's
> > quite appaling (I don't think there's any need to list examples).
> 
> Well, I think a few packages put their menu items in the wrong places,
> and the "Tools" submenu is just a dumping ground for anything that
> doesn't fit a defined category (and consequently it's got far too many
> things in it). But for the most part, packages that fit defined
> categories do the right things. So what's really needed is more defined
> categories.

  that's what I was saying, isn't it? so you're basically agree?

  but it's not few, it's quite some number, just go through the menu.
When you enable hints it's completely out of hand.

  examples (menu hints enabled)

editors:
AbiWord - why is it not in word processors?
hint KDE - submenu: makes no sense, it's orthogonal info to the rest of
submenus, also there's no Gnome submenu even though I have at least
gnotepad+ (maybe some other gnome editors)

Misc
dconfig - why is it here? looks like it should be somewhere, probably
System

Net (big time mess)
hint File_transfer - only ncftp is here but not:
  gftp-gtk, gftp-text
  (also, shouldn't napster, gnutella clients, pavuk etc be here as
well?)
hint IRC - not everybody uses it
  irssi-gnome, irssi-gtk, irssi-text
  tkirc
hint Gtk+-based_Mail_Client - this might be a good description but not a
hint (note that there is a hint 'Mail')
hint HTML_Editor - some html editors are in Editors menu:
    quanta
    august
    bluefish
    screem
hint Mail - not all mail clients are here, e.g.
  Net/Netscape  - netscape mail client
  Tools/evolution
  Net/postilion
hint Terminal - only mozilla xml terminal and telnet are here
hint VNC - tk vnc does not use it
hint Web_browsers - some browsers do not use it:
  netscape
  lynx
hint News Reader - Pan uses it but not Mozilla's news client

Programming
  hint KDE - here it makes some sense but again, no Gnome hint

Sound
hint KDE - again, who the hell cares? should we have athena, motif,
lesstif, qt, gtk, gnome, and zillion other toolkit's/environments
submenus? ('KDE' might be good as a part of description, or as keyword
or something but NOT as menu hint).
knapster - in Sound/KDE, all (?) other gnapster clients are in Net
hint Player - not used by:
  alsaplayer
  ddj (well, it's meta player)
  freeamp
  gqmpeg
  gmp3
  gnomp3
  gtcd
  mq3

etc. there's even more mess in System and even more in Tools. and IMO
xine is not really a viewer but more like a player (then again it's not
sound player, so where to put it? if xine is viewer then galeon is
viewer as well:-). look at where the various file managers are...

  basically, what developers do is to put it either into Apps/Net (if it
does anything with network) or Apps/Tools and include more or less
random hint.

> >   IMO instead of section and hints there should be one structure of
> > menus, user should be able to fine tune the menu system to display menus
> > according to various preferences (optimize for smaller menu depth? for
> > smaller numbers of items in each menu? put most often used item at the
> > beginning? in the top level menu? whatever).
> >
> >   another point: IMO the debian menu should be accessible by
> > left-clicking on the root window in all window managers.
> 
> No, absolutely not. In some desktop environments, the left button is
> used for selecting and dragging icons, and you can select several icons
> at once by dragging on the desktop to create a rectangle enclosing the
> icons you want to select. That really is the right thing for the left
> button to do in desktop environments that support that functionality.
> 
> Such environments often use a root window right-click to pop up a
> "desktop properties" or "window manager properties" menu, which also
> shouldn't be superseded by Debian policy.
> 
> That leaves the middle button, which two-button mice can usually fake by
> pressing both left and right buttons simultaneously. Will that do for a
> standard Debian menu button?

  click on the root window is different from dragging on root window.

  click on icon on root window - do whatever you want to do with icon
  drag in root window - select multiple objects on root window
  click on root window - get debian menu

  I admit that there might be some crucial feature tied to left click on
root window in some WM where it would not be possible to implement this
but IMO it's a good default. Is there? as far as I remember from my
testing WMs all of them have either menu or nothing bound to left click
on root window (and I mean click, not drag, and on root window, not on
icon or other object).

  I just switched to KDE to see how it handles debian menu and I've
found out that it's just sickening - it includes some debian menus as
submenus of KDE menu but the ones that do not fit are not there at all
(and I haven't found a way to get just single debian menu tree). The
crucial one is the menu with window managers - how do I get back to
fvwm?

  IMO debian menu system is one of the greatest things since debian
package system but it needs to be better maintained as far as the
content goes. and my guess is that it's time to revamp the
implementation as well (get rid of hints, replace by structured
section).

	erik



Reply to: