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

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

On Wed, 9 Aug 2006 07:23:28 +1000 David Seikel <onefang@gmail.com> babbled:

> 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.)

for e17 - just put it in src/bin/e_desktop_file.[ch].

> 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.

fine :)

> 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.

well - no - i don't think so. i think its best put in a fairly portable .c file
and copy it into e17 and entrance - for now. at some future time - maybe ecore,
but the creation of evas objects should be separate for sure. just have an api
that can raw parse a .desktop file - provide the right fields from the locale,
and be able to find an icon given some params (find the default, only find
bitmaps, find a certain size icon, find one given theme X) etc.

> 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.

XPM is not hard - loader is in imlbi2 - can be snarfed in. svg - well - a
bigger issue - but i think we can avoid it for now and just display "default"
icons in place. as long the the "icon finder" routine will return null when no
icon can be found given the params - the code can fall back :)

> 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.

fine :)

> 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.

just have an api for "give me the icon file for this .desktop icon name" given
parameters of "allow svg yes/no, theme, size, etc. etc." and let the code make
that descision. need to produce and evas object itself - let code do that
itself - it just knows what it SHOULD load, or CAN.

> 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.

for many apps we can guess the name/class based on exe - if not provided. ie

exe, Exe

> 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.

well i lean to the "put it in e and put another copy in entrance" for now - not
another ecore_desktop thing - but i do see a point of it being sharable.

i can be tipped to ecore given some arguments :) but as i said - it only needs
to parse .desktop files - provide structs to read, be able to FIND an icon file
- not actually load it, be able to parse menu data and provide a menu tree etc.

it should also be flexible to be able to parse added fields that we may add
ourselves (the fm2 .desktop parser handles a small set of fields - and one of
them is custom to fm2 - the Type member (also i recycled the URL, Name, Comment
etc. fields).

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)