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