On Fri, 11 Aug 2006 08:07:56 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman) > <[EMAIL PROTECTED]> 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-) ok- make it an ecore_fdo blob (ecore_fdo sounds good? or ecore_xdg?) :) > 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. yes - do it :) > 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. 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. ??? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
