Re: Debian menu system update
On Sun, Jun 01, 2003 at 04:34:55PM +0200, Bernhard R. Link wrote:
> * Chris Cheney <ccheney@cheney.cx> [030530 20:50]:
> > > I think making things consistent needs us to write them on our own,
> > > taking upstream entries as suggestions. In my eyes it is just the same
> > > as with the directories software is installed into. There are just too
> > > many ways to do it and we do not serve our users well to let them all in.
> >
> > I'll let you learn all the languages of the world so that we can throw
> > away upstreams fully i18n menu entries...
>
> I'm nor talking about throwing them away in general. I'm talking about a
> consistent menu. If all your menu shall contain are KDE-programs, you
> might archieve this by blidly copying upstream items.
Any application that is written for GNOME or KDE (KDE 3.2+) will be in
the same menu. As I undestand it both ROX and XFCE menus work the same
way as well.
> > > Of course it would be nice to have things on places, where users know
> > > them, but without an consistent concept overall, there is no use to it.
> > > (Last time I looked we did not put KDE in /opt, though that might have
> > > things much easier and I'm sure many people were expecting it there...)
> >
> > Its Debian that is being inconsistent...
>
> Debian may be inconsistent with other distributions. But within Debian
> it's a dream of consistency. I have users using fvwm, wmaker, qvwm,
> icewm and others. And all have exactly the same menu. All can look at
> the others screen to show each other where to find the program to use.
>
> The only thing inconsistent in this regard are KDE-packages, which just
> have a unbearable menu. But I guess I'm just not in favor of KDEs
> philosophie. I never found a way to let KDE users look at .ps files
> other than ininstalling kghostview...
Right clicking on the file in konqueror and telling it to open with some
other app doesn't work? (Works fine for me) I am viewing a pdf file in
xpdf right now. If you want to make it permanent just click on edit file
type instead and change the default. Or run kcontrol -> KDE Components
-> File Associations to change them. By the way mime types are also
defined using desktop files and there is a specification for how that
should work on freedesktop.org as well. After the Debian menu system has
been ported to using desktop files the mime system will probably be the
next thing on the list.
> > > I think making update-menus able to parse files in dektop menu
> > > specification will only cause such files beeing included without
> > > inspection by newbies.
> >
> > I do not understand this statement. Why would newbies inspect desktop
> > entries to begin with...
>
> I was talking about DD newbies.
>From your posts to me and others it seems you are a Linux newbie as
well. Perhaps you need to learn more before posting about topics you
don't fully understand.
> > It is Debian that is broken since it does not follow the desktop menu
> > specification. Both GNOME and KDE follow it and will soon have
> > integrated menus, only Debian stuff will then be outside of the menu.
>
> I'd really be suprised, if those will become so simmilar. Even the
> update-menus rewrite to parse the new format seems not to aim at
> having all wms in debian exactly the same menu.
They aren't going to become so similiar... they already are the same. As
soon as KDE 3.2, which is currently in development, is released they will
be combined in Debian. People running the KDE 3.2 cvs debs already benefit
from this merge. By the way there are already 423 desktop files in Debian.
> > > There a many things, that make proper packaging of software a
> > > complex matter. Writing this single line to get a menu-item
> > > should really no problem. And if it was I really doubt the
> > > person involved was competent enough to look in the .desktop-file
> > > if it is reasonable...
> >
> > Now it becomes obvious you did not look at any .desktop files either...
> > slashdot is dooming us all. A single Debian Developer _CAN NOT_ write
> > decent menu entries _period_. See the attached konqueror desktop file,
> > notice it has translations for 57 languages.
>
> If there is a proper wording for a menu-item upstream (Note that the
> item and its place in menu are two different things), then there is
> no reason not to use it in the debian package. And then there is also
> no problem to include all the translations.
This is just extra effort that is not needed, and likely to get screwed
up by inept developers munging utf8 characters.
> > Debian people SHOULD NOT be writing the menu entries. And it is trivial
> > to learn if a DD does want to submit a skeleton one to their upstream. As
> > I already said above a menu entry written by only one person is of little
> > value since it will have no or very little i18n support.
>
> A menu consisting of only original menu items by upstream has no value
> either. Having Gnome and KDE chosing a common policy where to place
> their core pieces and adopting such a layout might be nice. Placing all
> the other free software on earth where their upstream thinks they suit
> best, will just give an entire mess.
The placement of a menu-item is not determined by individual upstream
maintainers as I have already told you before and you would have known
by now if you read the links I posted previously. Window Managers that
directly use desktop files will have menu files that determine the
directory structure. Apps only select which categories are proper
for the specific item and the menu file (menu as in desktop menu spec)
determines what to do with it. The upstreams of individual packages have
no control over the menu file. And the categories are also predefined in
the standard (since you obviously have not looked at it yet).
> > Debian people SHOULD NOT be writing the menu entries. And it is trivial
> > The current system is limping along and needs to be shot. KDE obeys
> > menu policy just fine (afaik)
>
> fine? not having a debian menu at all but placing some wild items in its
> own categories shall be fine? It's about as good as not implementing it
> at all.
This was done as a request by someone prior to my maintainence of KDE,
long ago KDE had its own separate Debian submenu as well. Many people
seem to think the way it is done currently is better than the separate
Debian sub-menu. Also, ripping out KDE's menu is not an option as it
would make KDE in Debian look completely different than any other
distribution and would make it much harder to get used to.
Chris
Reply to: