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.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
