On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: > > On Fri, Dec 05, 2003 at 03:02:42PM +0800, Cameron Patrick wrote: > > >> Except that AFAIK .desktops are still semantically richer than the > >> existing Debian system, and have more momentum behind them outside of > >> Debian. Upstream packages are much more likely to ship to .desktop > >> files than they are Debian menu entries. Admittedly I'm not convinced > >> that they're ready enough in other ways to replace what we have now. > > > > Thing is, none of this matters. If upstream support .desktop files, > > then we just run them through the script that converts them to Debian > > menu entries while installing. dh_installmenu would be a good place to > > do this. > > You do realize that the desktop standard has more features than the debian > menu system? Like i18n, icon theming, dynamic construction of a menu > hierarchy based on user /Desktop system preferences and so on? And that > this information would be lost? Why not run it the other way around, > convert the existing debian menu entries to .desktop files and work from > there? I think that this way would help debian on the desktops. Because you gain *nothing* and introduce a pointless transition. > > The extra features should be pretty simple to implement - just more > > text fields. > > Hardly. The desktop system in KDE-3.2+ and Gnome-2.4+ is not as static and > uncustomizable the Debian menu system at the moment. None of which is the problem of the menu package. It just has to read the fields and pass them to the methods, which then write out suitable data files for the frontend. In the case of kde/gnome, that would be a .desktop file; for everything else, yes, the data is thrown away. Nothing else supports those features, and this is again not our problem. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature