Re: [E-devel] Is efreet still coming?
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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
Christopher Michael schrieb: 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) If you want to have efreet to be a part of ecore and raster seems to want this, why don't you move it simply to ecore/src/lib/efreet and keep the efreet name-space. So efreet and ecore_desktop can coexist for sometime and it is much easier to do the transition (not only e17 uses ecore_desktop). And when sometime ecore gets split into several package, you can still use the efreet namespace and you don't have to rename all the function in your applications and libraries. just my 2 cents Peter - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
Peter Wehrfritz wrote: Christopher Michael schrieb: 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) If you want to have efreet to be a part of ecore and raster seems to want this, why don't you move it simply to ecore/src/lib/efreet and keep the efreet name-space. So efreet and ecore_desktop can coexist for sometime and it is much easier to do the transition (not only e17 uses ecore_desktop). And when sometime ecore gets split into several package, you can still use the efreet namespace and you don't have to rename all the function in your applications and libraries. just my 2 cents Peter This is along the lines of what I was thinkingtho I wanted some peer input first :) I'd rather just do all this once and not have to go back and redo it :) 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
Christopher Michael wrote: 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 ?? I'd prefer keeping it out of ecore, but its been decided that that's where it's to go. 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) I'd prefer if you keep the efreet naming and just s/efreet/ecore_desktop/g. We put some thought into the APIs and think they came out pretty good. (Unless we got the words around backwards for the typical ecore naming, then swap them around.) dan - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
On Tue, 20 Mar 2007 08:13:35 -0400 Christopher Michael [EMAIL PROTECTED] babbled: 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 ?? yes. as then we need to remove ecore_desktop from ecore if we keep efreet. we also now need efreet to be packaged for e17 and add it to the dependencies checks, e17 build checks etc. when ecore gets broken apart - it will be post 1.0 and it will be broken up consistently - it will not be hard as the same thing will be done for each ecore component when broken out so its do the 1 thing N times which is tirival - in the scheme of things. 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
On Tue, 20 Mar 2007 09:23:37 -0400 dan sinclair [EMAIL PROTECTED] babbled: Christopher Michael wrote: 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 ?? I'd prefer keeping it out of ecore, but its been decided that that's where it's to go. 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) I'd prefer if you keep the efreet naming and just s/efreet/ecore_desktop/g. We put some thought into the APIs and think they came out pretty good. (Unless we got the words around backwards for the typical ecore naming, then swap them around.) i agree - am happy with that. trying a compromise here - keep whatever api u have - as its what you designed and thought about - just make it an ecore_desktop replacement in ecore. :) dan -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
Brian Mattern wrote: On Sun, Mar 18, 2007 at 03:29:13PM +1000, David Seikel wrote: Raster made this commit about two weeks ago : a lot of patches - also my work on moving the IO stuff in e_fm to a slave process to stop e from ever locking up. this unfortunately breaks the other source stuff and thus breaks the app editor config dialogs and anything using fm2 for .desktop stuff from the e applications/all repo. i am doing this as i expect this to go away with efreet anyway so not too much of an issue. not all fm operatiosn work currently - note. so beware. it can view files though :) So I have been holding off on any attempt to repair these things and just sitting and waiting for efreet to solve all our problems. The users are now complaining about the broken app editor. I have not seen any efreet commits for a while, is it going to replace ecore_desktop soon? Or should I put in some effort to patching up the app editor while we wait? Efreet is pretty much complete, other than being itegrated into e17. Unfortunately, dan doesn't use e17 on anymore and seb and I have been pretty busy lately. What state of development is efreet in anyway? It is mostly complete. 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. 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. 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
Brian Mattern wrote: Efreet is pretty much complete, other than being itegrated into e17. Unfortunately, dan doesn't use e17 on anymore and seb and I have been pretty busy lately. I still use e17 at work, but don't have time to do development there. I just don't use it at home anymore as I turned off my last non-mac machine when I gave the monitor to my wife. dan - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
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 - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
On Tue, Mar 20, 2007 at 12:15:59AM +0900, Carsten Haitzler wrote: agreed to all the above - except i think test code could/should go into the now nice and shiny e17/test/... tree :) (imho). As long as we make this tree well known (e.g on whatever new 'accessing CVS' page we build). :) I've noticed several people who started learning edje after you split out the test tree who never knew about the edje test app (which is very helpful when initially learning EDC). rephorm - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
On Mon, 19 Mar 2007 10:39:08 -0500 Brian Mattern [EMAIL PROTECTED] babbled: On Tue, Mar 20, 2007 at 12:15:59AM +0900, Carsten Haitzler wrote: agreed to all the above - except i think test code could/should go into the now nice and shiny e17/test/... tree :) (imho). As long as we make this tree well known (e.g on whatever new 'accessing CVS' page we build). :) I've noticed several people who started learning edje after you split out the test tree who never knew about the edje test app (which is very helpful when initially learning EDC). yeah - i need to make something better that's separate. as such the edje test app is only just that - a quickly hacked up test app. :( rephorm - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Is efreet still coming?
On Sun, Mar 18, 2007 at 03:29:13PM +1000, David Seikel wrote: Raster made this commit about two weeks ago : a lot of patches - also my work on moving the IO stuff in e_fm to a slave process to stop e from ever locking up. this unfortunately breaks the other source stuff and thus breaks the app editor config dialogs and anything using fm2 for .desktop stuff from the e applications/all repo. i am doing this as i expect this to go away with efreet anyway so not too much of an issue. not all fm operatiosn work currently - note. so beware. it can view files though :) So I have been holding off on any attempt to repair these things and just sitting and waiting for efreet to solve all our problems. The users are now complaining about the broken app editor. I have not seen any efreet commits for a while, is it going to replace ecore_desktop soon? Or should I put in some effort to patching up the app editor while we wait? Efreet is pretty much complete, other than being itegrated into e17. Unfortunately, dan doesn't use e17 on anymore and seb and I have been pretty busy lately. What state of development is efreet in anyway? It is mostly complete. 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. 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 - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
