Re: Debian menu system update
> > Does this mean there simply is no such documentation?
>
> I think it's pretty clear how it should be done. Once we adopt the
> system, we can point system administrators to the relevant file in our
> documentation, and give pointers to the file format.
I think there should first be a documentation. Anything I've seen yet
only document how to implementing it. Nothing describes clearly how
to make .desktop files and what the content should be (oposed to the
format), nor how to customize this for local needs. Everything the
preludes talks about is: "we have doe it for KDE, having the same
format for Gnome would be nice". This is far from anything usable as
Menu standard. (It may be useable to be parsed by WMs and generated
by a menu system perhaps, but simply does not talk about users.)
> > Currently the main database for window managers or fvwm-modules is the
> > debian menu, as they are often selectable from a menu and there is no
> > difference in handling them and normal items.
>
> Huh? What "main database"? Are you saying some window managers read
> the Debian menu entries directly? From looking at fvwm, this certainly
> seems not to be the case.
No, but things like fvwm-modules just add a menu item, describing itself
as fvwm-module. And anything able to cope with fvwm-modules (and be it only
fvwm) gets them all.
Same is with window managers. A Window manager adds a needs=wm item for
itself, and anything allowing to choose a wm gets a file what wms exist
and how they are called.
> > Do you suggest tweaking
> > the .desktop files, to contain them, too?
>
> Contain...what?
Window managers and things like fvwm-modules or other things like this.
> > When I currently look in icewm-gnome, what is has in its KDE and Gnome
> > menus compared to what it has in its debian menu, I really have to doubt
> > that.
>
> If your problem is with the default layout, again: it's only a
> *default*. We can and probably will change it.
I was speaking of the mere numbers. Currently things having a Gnome or
KDE menu entry are a minority. Even when they combine to one format,
they will not soon get the "vast majority" you speak of.
> Many of my packages come with perfectly good menu entries from upstream.
> And besides, as one of the prominent free software projects, Debian
> should be leading the charge here.
Well, I think we just disaggree, if it is a change to good or to bad. I
do not want Debian to lead into disaster...
> > Heck, this specification even gives in the example the
> > Icon as .png-file. While using .xpm-only for menus is really
> > long-lasting standard, with no reason to stop this...
>
> And now the "Ok, my pointless KDE and GNOME flame was obviously wrong,
> so I'll try to troll about image formats instead" part.
You are trying hard getting me to insult back, don't you?
My whole point is, that this format is a typically KDE approch:
It describes happily complex formats and schematas. (Nice for a roadmap
to implement a prototype oneself, for a standard inadequate.)
It does not speak about anyone beside the programmer at all. It does not
even give reasoning for the creators of such files. Nor does it talk
about users or administrators and how they can get interfere with the
system. (Note that this is a general problem with KDE, trying hard to
get a system doable by clicks and forgetting to make the way without
graphic interface doable). If there are some resonings or hints for
contents, they partly seem not to think about other things (like
specifing icons as .png[1]) and partly simply want to soldify bad
decisions (Like those file formats decided by file-extension[1]) or
merging mime-suppliers and menu-items[3])
It furthermore describes no way to get a standardized deeper menu.[4]
I'm not saying automatic aproaches or specific menus per wm should
not be possible. I'm talking about they being avoidable.
Thus my whole point is, that this is by no means menu standard. On its
best its a format description for menu-files, that some new fashioned
wms are able to parse. And it might have good things like less work
to write menu-methods for those. But it is by no means something
resonable to base our menu-system on. (And as I tried to say before,
even the way to more directly recylcle upstream's suggestion for menu
items does not get more simple but just more error prone).
Hochachtungsvoll,
Bernhard R. Link
[1] This might be partly resonable for KDE-menus, for a menu
"standard" this just says: "It is not bloated as we are,
it can't be good.". or even "should no longer be supported".
[2] I'm currently even working to get xfm with some sane
defaults, as telling people to rename their files to
click at gets annoying with the time.
[3] It's real nice working Pavlov experiment. They most of the
time hit the "other"-button/menu-item, when they need it
though it is really obscure.
[4] I know, when I tell I badly need exactly the same looking
menu in a miriad of window managers with as many items that
the debian-menu-hirachy is on its limit, I will get answers
like "KDE-programs should not be shown in Gnome" and "non-KDE
programs are nothing newbie users can cope with in KDE" and
other opinions, people invented by thinking on their single
-user machine what newbies might want or what administrators
coping with many newbies might want.
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Reply to: