On 9-Feb-07, at 6:14 PM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 16 Jan 2007 17:11:33 -0600 Brian Mattern > <[EMAIL PROTECTED]> > babbled: > >> Currently we have code to build menus, find icons, and load desktop >> entries complete. There are a few things left to finish (most >> importatnly executing desktop entries), but it is almost at a point >> where we'd like to start integrating it in to e17. > > can it slide in AS ecore_desktop? >
The APIs are different but the changes to bring in efreet instead of ecore_desktop aren't huge at this point. (There have been a couple of patches to do it so far) >> The code, for those interested, is available from subversion at: >> http://everburning.com/svn/efreet The code is in the e17/libs/efreet directory of CVS at the moment. >> >> Before we hook e17 in to efreet, there are a few issues I'd like to >> bring up. >> E currently uses a hands off 'read only' approach to the XDG >> structure, >> copying the structure in to the format that e previously used (.order >> files). This made sense given ecore_desktops roots as an addon >> program >> that simply connected the two. But, since we're already going to be >> loading up the xdg menu format, is there any reason to not just >> use that >> directly? This would have the added benefit that as apps are added >> through a package manager, they would just show up in the menu as >> they >> do in every other desktop (without having to go to config > >> application >> menus > Regenerate / Update "Applications" Menu). > > then we need to support the xdg menu modifications spec (ie user > changes to the > system menus overlayed on the systems ones) - is that your plan? > If the user has an applications.menu in their .local/menu directory then efreet will load that and use it. The user can then have that do a MergeFile with the system menus and put their changes on the end. Efreet will handle merging them together correctly. At this point Efreet handles the full menu-spec test that fdo provides. (At least last time I tried a week ago it did) >> The next question is, assuming you guys see it as a viable >> replacement >> for ecore_desktop, do we stick this somewhere in libs (as efreet or >> e_xdg, or whatever name) or do we cram it in to ecore? My vote is >> that >> we stop bloating ecore in the name of a 'dependency freeze' and keep >> proper separation of libraries. (Its all 'new code' that needs to be >> verified and tested regardless of where we stick it). > > well i'd prefer it in ecore - as the plan post e17 is to split > ecore up into > multiple actual libs - thus you get what you want anyway :) > Wouldn't it make it easier in the long run to have it in a separate lib as you then don't have to go through the hassle of splitting it out? Before we just start sliding it in as an ecore_desktop replacement, do we want to remove all the extra layer of menu stuff that e17 currently has? ecore_desktop has slid in as a replacement for .eap files. Do we really need too second layer of converting fdo menus to .order files and then e17 working off of the .order files? If we just work off of the fdo menu it will take a lot of the confusion out of the picture. May cleanup/reduce a lot of the code. dan ------------------------------------------------------------------------- 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
