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

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



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.

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

Attachment: signature.asc
Description: PGP signature