Re: Brief descriptions in menu entries
On Wed, 29 Oct 2003, Ben Burton wrote:
> > > Btw, regarding (1), I certainly don't want menu-methods to look up
> > > manpages to get genericnames. ...
> > Huh. Read it again, RMB = Right Mouse Button.
> Hmm, I thought you wanted the RMB stuff *instead* of genericnames. If
> you want it as well as genericnames then that's fine with me.
We are still not communicating.
Sure, instead of genericnames. User sees "Internet/konqueror", thinks
wtf is that, RMB on the konqueror enty pops up a menu with entries
which: fire up khelpcenter on the docs, do "apt-cache show `dpkg -S
/usr/bin/konqueror` (whatever), etc.
I think that would be more useful than cluttering up the menues with
(probably redundant) stuff in parentheses designed to cater to
someone who doesn't know how to use the system docs.
> > So what is stopping Debian's KDE from using the menu system to
> > generate all of its menu?
> Well, because it would lose a lot of information for one thing. KDE
> uses a fair amount of stuff in its menus that the debian menu system
> quite simply doesn't support. Examples include generic names,
> translations and handled mimetypes. The current system uses this
> information where it's available and falls back to the debian menu
> system where it's not.
No need to lose anything, stick the KDE specific stuff in (I dunno,
say) /usr/lib/fdmenu (defaults) and /etc/fdmenu (overrides) with the
standard stuff (that which all menu producers use) in the usual place
and format. The KDE menu-method(s) can then produce either the
standard Debian menu hierarchy or the KDE default by either honouring
the structure produced by menu or that in the fbmenu dirs. There is
really not even any reason to split the current KDE .desktop files
into Debian native and KDE native fragments if the new menu-method(s)
take all the data in the fbmenu entries in preference to what is in
KDE gets to do what it wants without affecting any other menu
producer, and sysadmins gets to choose what style of menu they want.