Re: adding desktop files to misc packages
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
Reply to: