On Thu, 10 Aug 2006 23:13:50 +0900 Carsten Haitzler (The Rasterman) <email@example.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.
Description: PGP signature