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. > > 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. 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. > > > ~$ 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? > > > 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. > > > 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 > 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. > > 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 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 Chris BTW - I notice that many .desktop files still do not have GenericName entries. Including epiphany! It just uses regular "Name" for its "GenericName"! WTF?
Attachment:
signature.asc
Description: Digital signature