Carsten Haitzler (The Rasterman) wrote: > On Mon, 19 Mar 2007 10:02:18 -0400 dan sinclair <[EMAIL PROTECTED]> babbled: > >> Christopher Michael wrote: >>> Brian Mattern wrote: >>>> Loading .desktop files, finding icons and parsing / building menus all >>>> works. Executing desktops (and even downloading the files if necessary) >>>> has been implemented. >>>> >>>> There may be a small amount of work left to be done to properly do menu >>>> editing. I think we just never decided to what degree we want to >>>> integrate things. E.g. converting directly from efreet's menu structures >>>> into an E_Menu, or doing an intermediate step and building .order files >>>> first. >>>> >>> IMO, .order files may be the way to go as this would still allow a >>> manual edit if needs be. >>> >> I don't think .order files are the way to go. The menu spec allows you >> do manual edits. You can override the system menus by adding/editing >> menus in your local directories (~/.config/menus). This gives the same >> thing and saves us having to translate between .order and menu stuff. >> Also keeps us consistent with other window managers for people that >> switch desktops. >> >> >>>> But, I'm busy with work, planning a wedding, and preparing for grad >>>> school in the fall. So, its hard to find the motivation to work on this >>>> in what little free time I have. :( >>>> >>>> rephorm >>> If you could provide a little more "direction" (as in what exactly we >>> want todo in regards to integration) then I'd be happy to look into this >>> and spend some time with it. >>> >> I believe the idea is to use fdo menus directly for the main e17 menus. >> The Ibar would remain .order files. >> >> So, we need to replace the menu generation code with efreet code. We >> need to port the icon editor over to using efreet (and add in a bit of >> editing stuff to efreet I believe). >> >> We also, I guess, need to move efreet into ecore. Probably into >> ecore_desktop as #if NEW_CODE blocks so we can keep the old stuff. Not >> sure on that one tho. If we integrate into ecore we need to make sure we >> bring the menu test suite code into the bin directory. This is the code >> that let's us run efreet against the menu spec tests. I think we should >> definately keep it around. >> >> There is a bunch of example code in the efreet test directory that >> should let you know how things work in efreet-land. > > agreed to all the above - except i think test code could/should go into the > now > nice and shiny e17/test/... tree :) (imho). > >> dan >>
Hi Guys :) I've been reading through the efreet code and it's not too shabby, so big (insert your favorite type) cookie to the authors there :) but before I jump head first into this porting nightmare I have a few remaining questions.... 1) Is it really worth the effort to port all this efreet code into ecore_desktop, just to be pulling it out at a later date when ecore gets broken apart ?? 2) Am I correct in assuming that we still want to keep the ecore_desktop_some_function calls and just replace the code inside with efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we still would have ecore_desktop_some_func, just that it would run efreet code) Cheers, dh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
