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

[Carsten Haitzler (The Rasterman) <raster@rasterman.com>]

On Fri, 11 Aug 2006 09:45:31 +1000 David Seikel <onefang@gmail.com> babbled:

> On Fri, 11 Aug 2006 08:01:33 +0900 Carsten Haitzler (The Rasterman)
> <raster@rasterman.com> wrote:
> 
> > On Fri, 11 Aug 2006 08:07:56 +1000 David Seikel <onefang@gmail.com>
> > babbled:
> > 
> > > On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman)
> > > <raster@rasterman.com> wrote:
> > > 
> > > > i can be tipped to ecore given some arguments :) but as i said -
> > >
> > > Arguments to tip you to ecore_desktop_* for the parsing code -
> > 
> > ok- make it an ecore_fdo blob (ecore_fdo sounds good? or
> > ecore_xdg?) :)
> 
> I thought about that.  This is not the only fdo spec that we now,
> or might in the future, support.  The other specs may or may not want
> to be covered by ecore_fdo, as their specs cover all sorts of different
> things.  Xdg also covers all the other fdo specs. I think ecore_desktop
> is best, as this code deals with all the .desktop related stuff.

hmm - so you plan on covering the fdo menu spec elsewhere?

> > > > 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.
> > 
> > cool. what i see would be best is that the load is cone with the
> > ecore hash but then this is copied into a "static" struct on the e
> > side (since we will be loading 100's or 1000's of .desktop entries -
> > if each has their own hash this is rather expensive memory-wise).
> > 
> > the other option is - we make the only source of a load the "cache"
> > and nothing gets loaded until it goes into the "cache". so there is
> > code that loads and then adds to the cache - telling the "real" load
> > to "ok - look in cache now!". now cache becomes a mmap()'ed file,
> > already laid out in an architecture-independent way (no pointers,
> > just offsets for indexes) and thus this data is just mmaped() and
> > thus will be paged by the kernel as needed and only what is needed is
> > in memory - and if more than 1 process needs this data - it will
> > share the cached map.
> > 
> > ???
> 
> I'll get it in first, THEN worry about caching options.  B-)

well it could be a full design decision from the get-go :)

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