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

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

David Seikel wrote:

It seems there are two things going on here, 1) parsing and 2)loading with the parsed information. I think striving to keep the two seperate will be good overall (i'm saying this without having a clear view of the situation that you have). Next below...
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.)
I feel the parsing belongs in ecore. Since ecore is like central plumbing, it makes sense to put this there. I expect to call, ecore_dotdesktop_parse(a_pointer_to_struct_dotdesktop, "/path/to/foobar.desktop") and it populates that struct with, name, full path to icon (which has been located via freedesktop.org kung-fu), full path to executable or executable name to be found in $PATH, etc... this part of the work, I feel should belong to ecore_...). Just ignore my description above, since you obviously have something already, just an explanation of tot process.
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 second part in this process is .desktop file loading, which I believe refers to the ability to use a specified .desktop file to create an visible icon, which when we click on it, it executes the executable refered to in the .desktop file. This part of it, i feel is distinct enuff and belongs to Evas. It falls in line with *loading and image and some metadata*. Evas in this case would use the ecore routines to grab the meta data (would this create a cyclic dependency? if it does, then every thing can be done in evas, but as _seperate_ subsystems, though the parsing part... really *smells* like ecore stuff).
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.
this work should all be done by the parsing parts.
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.
if the ecore_parser part is quizzed for the image size, it can return the proper image path in the "struct" and then the evas loading part can commence to load this.
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.
dunno much about this guys... no comment :)
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.
the heavy lifting should surely be done by ecore, like you said, all you need is there already. you could add a simple tree there for this purpose i guess.
So, where do I put this code?
IMOHO, i think the parsing part belongs to ecore, and the loading part to evas (this will call the parsing part from ecore, provided there's no circular dependency being created).

okie dokie... how's that for being helpfull :)

Oh... and good work.

/me settles down to lazily wait for grossly underpaid onefang to solve all headaches :)


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

enlightenment-devel mailing list