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

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

On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman)
<raster@rasterman.com> wrote:

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

Yesterdays efforts where mostly about splitting up the parsing from the
loading code, so that there is now code and structs to just parse the
.desktop to a structure, just find a path to the icon file, just parse
the menu files to a tree.

Arguments to tip you to ecore_desktop_* for the parsing code -

The history of this code is that it has been shuffled about from one
place to another, sometimes with attendant controversy.  You have given
me the rush job of finally incorporating it into the window manager
with the restriction that the wm dependencies are now set in stone.
There are currently three potential users of the code, two of them in E,
the other one in entrance.  I have always been writing this code with a
view to make it generically useful.  You are the one that has
complained in the past that all of E+EFL is in need of refactoring,
something which I have agreed to help with.  E and EFL are supposed to
be small and fast.

Given these restrictions, it makes a lot of sense to put this into
ecore now.  I don't have to move it yet again at a later date.  We don't
have to maintain two copies as we try to make it smaller, faster, and
more generic.  We don't have to merge two possibly divergent copies.
We don't add to a future refactoring nightmare.  We get all the
controversy over and done with one more time, rather than many more
times.  The fdo desktop, menu, and icon code can finally have a
permanent home.  I will have one less source of instability to worry
about this month now that my landlord has told me to get out by the end
of the month so that he can renovate my place.  B-)

Part of the job you have given me is to re do the eap caching once we
have converted over to .desktop files.  As part of e17genmenu, which
has to deal with hundreds of .desktop files, some of them read in
multiple times, the .desktop file reading code already has a caching
mechanism in place.  Sure I might decide on a better mechanism once
.desktop files are natively supported, but having two different copies
of the code just complicates the caching issue.

Having the code copied to two different places means lots of pain that
can be avoided by putting it in a library that is already used by both
those places.  Later today I will put it into ecore_desktop unless I
get some good arguments for putting it elsewhere.  Then I will start
modifying e as planned to use .desktop files and essiene can start using
it for entrance.  I know he is hanging out for the code.

> 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).
All fields that are in the .desktop file are included in an Ecore_Hash,
some of them are also decoded into specific fields of my Fdo_Destop
structure.  I have no issue with adding more fields to that structure
as time goes by.

Attachment: signature.asc
Description: PGP signature