Am Freitag, den 20.07.2007, 18:03 +0200 schrieb Michelle Konzack: > Am 2007-07-15 22:57:10, schrieb Daniel Leidert: > > Am Samstag, den 14.07.2007, 12:44 -0400 schrieb Joey Hess: > > > Until there is one, I don't see any reason why I should accept patches > > > adding menu files to my packages. > > > > The .desktop format is not only about the menu item itself. It also > > contains the application <-> MIME/file type association information. The > > update-desktop-database then parses all .desktop files and creates this > > database (/usr/share/applications/mimeinfo.cache). AFAIK KDE 3 uses this > > system, his own system and the old system via /usr/lib/mime (metamail, > > right?). But GNOME AFAIK only uses the current shared MIME info > > database. > > Which mean, over the half of the .desktop files would be useless for peoples > NOT USING KDE or Gnome.
This is wrong. There are many other systems that make use of these _cross-desktop_ specifications, written to unify the ways, the different environments handled these things in the past (e.g. current browser use this information to know, which applications to use for a MIME type; but there are many other systems and implementation to use these information - not only written for GNOME/KDE/XFCE). Further my point was, that .menu only contains a subset of information a .desktop file contains and that the conversion into .desktop files will be very limited. > However, I support ONE fileformat since maintaining > a .menu AND A .desktop file costs some nerv specialy, if you can not use/test > the .desktop files. There are test applications for .desktop files. And PS: That something is getting on your nerves is not a compelling argument. > So if "menu" use the .desktop files as input, it would be good. Yes, that would be possible. However I think, that this only makes more work that simply switching the Debian .menu file format into the .desktop format too. > > > Generating both menu and .desktop files from a third format would be > > > pointless. Either format can be generated from the other format. > > > > No. The Debian menu entries do not contain the information about which > > MIME/file types can be handled nor in which menus the entry should > > This is right, but WM's which do not use .desktop files do they support > those mime stuff? -- AFAIK no. A pretty silly argument. I was talking about the conversion of Debian's .menu files into fd.o .desktop files. Can you please tell me, which WMs support or use Debian's .menu files or it's features? Right: We are talking about a Debian internal system. > > occur. The Debian menu items also do not contain the information, how to > > ??? -- What do you mean, with "in which entry they should occur"? OnlyShowIn, NotShowIn, Categories - Debian .menu files do not follow the "Desktop Entry Specification" and do not contain the Categories information from the specification, beginning with the fact, that there is no 'Application' category, because it's very useless - the Type key tells, if the .desktop file is for an application. > The "Menu System" have the "section=" which is, WHERE the item occur. The Debian menu sections are differently organised and use different categories. E.g. Application(s) is not registered category in the "Desktop Menu Specification". > > handle the arguments when calling the program from e.g. nautilus to open > > Does this work under "fvwm" too? AFAIK no. We speak about a cross-desktop specification, that was written to unify the systems on the desktops. Also current KDE 3 doesn't fully support all specs, but KDE 4 will. So I cannot tell you, if or when fvwm (parts) will follow the specs, but I can tell you, that using fvwm as argument here, is pretty useless. I was talking about the limitation of converting the different formats. And applications using the extended features of the .desktop format will more suffer from the limited conversion than applications/systems _not_ using _any_ parts of the specifications. But these systems also will not loose anything by dropping the Debian .menu file format in favour of the .desktop file format. I wasn't talking about removing the Debian menu in favour of the GNOME/KDE/XFCE menus. > > a special file. And I don't want to start to tell about the "action" > > section possibilities ;) However, the formats only share some basic > > information, but the .desktop format contains much more information, > > than the Debian menu item files. You may be able to create a Debian menu > > file from the .desktop file. But the other way would be very useless. > > It depends, whether the apps SHOULD be run from GNOME/KDE or not. This is wrong and I already explained why. And even a limited .desktop file would only work on the systems, where the .desktop format is supported (including Debian's internal menu). So what is your argument? > For many (most of my) apps, I do not need any mime stuff and such. And this is the compelling argument against my statement, that .menu only contains a subset of .desktop and you will never be able to create a full-featured .desktop file from a .menu file? Are you kidding me? Say someone decides to turn the .menu format into the .desktop format. What will you loose? Nothing. You then simply write a "simple" .desktop file, if you don't need MIME support or execution information. But you will be able to add this information for the systems, that can use it, without doubling your work as package maintainer. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
