[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[E-devel] Using freedesktop.org .desktop files.



There are a few TODO items for E17 -

"* fm2 .desktop parser needs to handle i18n
* use .desktop files and move eap editor to edit them etc. etc.
instead to fix
* if we want to do icons on the desktop - and as part of efm, i am
thinking that we have little choice but to implement a .desktop file
loader. this is not to hard - it's the xml jungle of the system menus
that is sucky. the real problems are where to find the icons for
the .desktop files."

I already have all the code for parsing .desktop files and finding the
icons according to the freedesktop.org (fdo) specs.  Also, to support
xsession files, essiene wants me to make the code available to
entrance, since those are .desktop files. So the question becomes,
where to put the code.  I'm ready to cut and paste, just gotta know
where.  (I also have xml jungle menu code.)

According to rasters plans, we are replacing .eap files with .desktop
files.  Argue with him about the plans, I'm just implementing them
since I have the code all ready to go.  My initial plans are to
implement .desktop file loading alongside .eap loading, so that .order
files for instance could contain a mixture of both.  This gives us a
grace period where things wont break while we change over.

The .eap code is in e_apps.c, and there is some really basic .desktop
parsing code in e_fm.c.  That's not the best place if entrance wants to
re use the code.  Evas or ecore are the candidates I am considering.
Evas because we are essentially loading an image and some metadata.
Ecore, because evas needs some extra API to allow the requesting of
specific sizes.  There may be a better place.  Let me go over the
relevant details.

The information in a .desktop file is not complete, it requires the
rest of the freedesktop.org system to be in place to be able to gather
all the information required to actually load the icon.  Any distro
that is using .desktop files has that system in place, it's just up to
the code to follow the spec and ferret out all that info.

Typically a .desktop file only supplies the base name of the icon, you
have to go through the fdo procedure to find an actual file with image
data in it.  Those files will be PNGs, SVGs, or XPMs.  PNGs we can
handle, XPMs we can add support for, SVGs are currently considered to
hard, and are being left until later.  What particular mix of PNG, SVG,
and XPMs might be found is usually upto the distro makers to decide.
The user can install more icon themes at any stage.  So we will be
getting lots of complaints until we support all three formats.

There are a few sources of paths to search for both icons and .desktop
files.  These include things like default paths, optional paths,
environment variables, programs to run that return paths, KDE and GNOME
can supply paths if they are installed, etc.  KDE or GNOME are likely
to be installed, and a lot of distros setup their fdo systems to suit
those wms, so it is worthwhile using them as sources of search paths.
E17 has it's own method of allowing the user to define search paths,
this can also be used.  The end result is prioritised lists of places
to look for .desktop and icon files.

According to the fdo specs, the user is allowed to select an icon size
and theme.  The spec contains methods of looking through the search
paths to determine what icon themes and sizes are available.  There is a
fallback size and theme that every system must supply, but it doesn't
have to be the default.  B-)  This is what makes evas a bad choice, it
doesn't currently have an API for "give me this image in this size",
let alone taking into account the theme element.  This is also one of
the reasons that SVG is too hard, since it's a vector format, a size
will need to be specified for evas to load it.

Another issue is that although the fdo spec includes window class info
in the .desktop file for the purposes of startup notification, I
haven't seen many .desktop file that actually include that
information.  In the case of eaps, the user either typed it in
manually, or it came from a currently running application, so I don't
think that is a major concern.

Finally, my .desktop implementation requires a hash and a list
implementation, and the xml jungle code requires a tree.  No external
xml parser is needed, as I wrote a simple one that is just enough to
parse fdo menu files.  The .desktop files are not xml, they are more
like Windows .ini files.  Ecore supplies all the needed functionality,
which is the reason I think it's a good place for the .desktop code.

So, where do I put this code?

Attachment: signature.asc
Description: PGP signature