Re: Brief descriptions in menu entries
On Tue, 28 Oct 2003, Chris Cheney wrote:
> On Tue, Oct 28, 2003 at 02:36:10AM -0700, Bruce Sass wrote:
> > On Mon, 27 Oct 2003, Chris Cheney wrote:
> > > On Mon, Oct 27, 2003 at 04:40:56PM -0700, Bruce Sass wrote:
> > > > On Mon, 27 Oct 2003, Ben Burton wrote:
> > > > > Chris Cheny wrote:
> > > > > > Why not just convert the Debian menu system over to the freedesktop
> > > > > > standard after sarge is released? Gnome, and KDE (and probably others)
> > > > > > already use it. It takes care of this problems and several others,
> > > > > > besides making the Debian menu files standard format.
> > > > >
> > > > > I rather like the idea of this. Though of course the people who need to
> > > > > be convinced are the ones writing menu-methods files for systems that
> > > > > don't use this standard. :)
> > > >
> > > > I like it, although it is a bit heavy handed.
> > > >
> > > > on one hand:
> > > > Is "this problem" really a problem that warrants rewriting the menu
> > > > system, and the menu-methods, and the menu entries. The existing
> > > > system should create submenues as required, and those with only one or
> > > > two of a particular type of app (freedesktop's GenericName) that don't
> > > > know what (say) apps->net->konqueror is can do...
> > >
> > > There are fewer than 45 menu-methods in total. Converting them to use
> > > the new standard shouldn't be that hard. However, there are many menu
> > > entry files, many of them could be dropped entirely due to them being
> > > conversions of .desktop files already (ie all the Gnome and KDE ones).
> >
> > It is not so much a matter of "hard" as it is a bother for little or
> > no gain. Do you you mean `conversions to .desktop files'... getting
> > basic .desktop files for everything with a menu entry is pretty close
> > to trivial.
>
> I meant that currently a large amount of the .menu files in Debian are
> simply obtained from their Gnome/KDE .desktop counterparts which are
> maintained by upstream. The .menu files for those could simply be
> dropped and the remaining apps with .menu files would need the trivial
> conversion to .desktop format. Then they could be sent to upstream as
> well so that all users could benefit from the entries, since they would
> be uniform across all dists/os. For example, a FreeBSD desktop menu
> would essentially look the same as a Debian one, etc.
>
> Afaik Debian originally created its menu system due to the fact there
> was no standard one available. Now that there is one the only real reason
> (afaict) to continue using it is keeping the status quo.
If looking the same as something else and using someones standard is
important then why not use MS's, then it will look the same as most of
the boxes out there... :-() just kidding... but you may presume that
I don't see `looking like others' as important. A Debian box should
look like a Debian box, ditto for FreeBSD, Mdk, RH, etc.
> > > Also by converting to the new standard the menu entry files could/should
> > > be sent to upstreams so that everyone could benefit by the menu files
> > > since they would no longer be Debian specific. This would also further
> > > i18n desktop support since the new standard supports it and upstreams
> > > could more easily collect the translations from its wider base of users.
> >
> > None of that is contingent on Debian converting to the freedesktop
> > standard; the current, generated, .desktop files could be sent
> > upstream. If that 's what you want to do.
> >
> > I don't think upstream should have to worry about menu entries,
> > that is up to those building the menues.
>
> Upstream has a vested interest in having their applications used. Having
> the applications appear in a uniform location with a correct and the same
> translations across different dists/os would also be very useful.
Ok
> However, creating and sending correct .desktop files to upstream when
> the Debian maintainers would just have to manually create .menu files for
> the same entries is redundant and annoying work.
In general, this broader proposal seems to presume that all the
upstream developers will jump onboard and neither the desktops or
distros will need to generate menu entry files. I think it is more
likely that only some upstreams will distribute .desktop files, only
some of them will be maintained, distros will want to tweak some, and
some apps will not be covered by a distro or upstream so KDE will
still need kappfinder.
Instead of one or two creating menu entries according to whatever
policy or standard you have a bit of a free-for-all generating
entries of unknown quality. Is the result more or less work.
> > > > ~$ man konqueror
> > <...>
> > > real documentation, but they haven't been written for all binaries yet.
> >
> > Point was, it is not necessary to convert Debian to accomplish what
> > the GenericName proposal wants. IMO it would be better to have KDE
> > improve its menu handling... integrate with the existing system; and
> > have an RMB on an item pop up a menu with actions for viewing the apps
> > docs, looking at the dpkg and apt views of the package the app comes
> > from, looking at the docs of the package, etc.
>
> You are correct about the GenericName proposal. However, my point was
> that you would also automatically get that with .desktop support as well,
> amongst its other benefits. However, I don't know what you are talking
> about wrt improving KDE's menu handling. Is there an example menu-method
> that shows what you are talking about?
Nope, just a feeling that KDE's menues do not integrate well; the
dumped in /usr with the Debian menues tacked on thing, only
per-user customisation (no overrides).
> > > > on the other hand:
> > > > It would sure be nice if I could override the system wide entries and
> > > > get nice KDE menues. i.e., the standard menu sucks because it
> > > > can't/doesn't communicate enough info to KDE, KDE's menues suck
> > > > because I can't do a system-wide replacement of an entry (without it
> > > > getting overwritten next upgrade).
> > >
> > > If I remember correctly there are ways to override menu entries with the
> > > new freedesktop standard. However, its not in the version currently in
> > > sid.
> >
> > or the KDE menu-method(s) could get smarter and more flexible...
> > Why not adopt a convention for dealing with menu entry fragments so a
> > menu-method has somewhere to look for additional data.
>
> See above.
[takes a quick glance at what would be needed]
The menu-method is ok but the stuff in /usr/share/applnk would need to
be installed elsewhere, /usr/bin/kde-update-menu would need a
rewrite, bits would need a home in /etc.
While I'd risk assuming you would consider a new kde-update-menu, and
I like the idea of not installing to where KDE looks for its menu
entries, it touches 78 maintainers on my small system... isn't that
the sort of thing which needs DD community approval beforehand. It is
easy enough to break the menues to test things, but what is the point
if it is a non-starter with the DDs.
> > > > This would open up the possibility for (say) KDE to actually
> > > > integrate its menues with the system instead of dumping them into
> > > > /usr then tacking on the Debian menues.
> > >
> > > With KDE 3.2 both Gnome and KDE menus should be fairly well integrated.
> > > I haven't actually looked at KDE 3.2 to see how this works out but in
> > > theory it should just work. BTW KDE 3.2 is due out early in Dec.
> >
> > Great, but what does that mean and how does it help KDE and Gnome
> > menues integrate with the system?
>
> There is a uniform location for all menu entries now
> (/usr/share/applications). Afaik if the menu entries exist in the
> directory they will automatically be sorted into the correct menu folder
> and displayed as the user requests (ie genericname, i18n, etc). If the
> applications that do not currently have .desktop files were converted to
> .desktop and installed into that directory they would be displayed
> automatically as well. Then all that would be needed for the rest of the
> WM's to see the menus would be either:
>
> 1. writing new menu-methods
> 2. add direct support for the new menu system
So, it doesn't help KDE integrate with the system. You want the
system to bend to what KDE does, that is just plain backwards to me.
> > Who do you see being the logical distributor of menu entries:
> > upstream, the DE/WM's, or the distro? How about practically?
>
> I see the logical distributor of menu entries as being the upstream.
> There are of course exceptions such as XFree86 who don't even maintain
> their own codebase properly. All apps that are in some way related to
> Gnome or KDE already have .desktop files. I have even seen some other
> apps that aren't directly related already use them. However, until
> recently there wasn't a uniform location for the files so there wasn't
> as big of a reason to do it.
Logically, I would agree that upstream makes the most sense.
Practically, I think it should be the distros; not all the upstreams
will bother so the distros will need to do it anyways, distros are
closer to the users, distros are the ones generating the menues.
How many distros have jumped onto the freedesktop bandwagon?
> > > Finally, the best reason to convert is because standards are good m'kay. ;)
> >
> > Standards adopted by convention are good, standards that are pushed
> > often most benefit those doing the pushing. In this case KDE and
> > Gnome benefit most and most everyone else has some work to do... for
> > what, to process options they don't support.
>
> Since Gnome and KDE make up over 80% of the desktop on FOSS saying it
> was pushed instead of convention is questionable. Supporting options
> such as i18n is a good thing. Most of what the menu entry standard does
> is just makes what various dists have done in the past uniform.
I don't know about the FOSS community, but KDE and Gnome are the only
two suites I've noticed in Debian I'd consider desktops (xfce4 looks
like it is trying, any others?) so I suppose one could say Gnome and
KDE make up 100% of the desktops on Debian, eh. :/
If you start emailing .desktop files to upstream developers, for them
to maintain, it will appear as pushing.
> > I would much rather see Debian adopt an efficient, even if more
> > complex, system than a one size fits all standard solution which would
> > appear bloated to most of its users.
>
> IMHO it would be best if Debian actually worked with freedesktop.org if
> there are wanted features to be added directly to the standard.
>
> http://freedesktop.org/Standards/desktop-entry-spec
That would be a good thing.
- Bruce
Reply to: