dan sinclair ha scritto: > Peter Parkanyi wrote: > >> On Wednesday 17 January 2007 15:15, you wrote: >> >>> On Wednesday 17 January 2007 01:14, Jorge Luis Zapata Muga wrote: >>> >>>> On 1/17/07, Brian Mattern <[EMAIL PROTECTED]> wrote: >>>> >>>>> .... >>>>> >>>>> 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). >>>>> >>>>> Let us know what you guys think. >>>>> >>>> Indeed, i agree here. Better make it away from ecore, ecore already >>>> has too many (unrelated?) things inside. >>>> >>>> turran >>>> >> I'd argue on that topic. I think it should go to either ecore or e17. The >> reason: I don't think any app but e uses the freedesktop menu, or if they do >> so, they depend on e itself. >> >> It would be just a mess in the now well-structured dependency tree if we had >> to compile another lib, which only does one thing, and only one app uses it. >> And ecore? Well ecore is what its name sais: core library for efl(not just >> e17). And if there are already fdo stuff in it, and this would be a >> replacement for that, why don't you really replace it, inside ecore? >> >> > > Efreet is more then just menus. It also contains the icon theme code > which is used in Ewl. Any other app that want's to use the icons from a > given icon theme could use Efreet as well. > > Along with that, this _isn't_ core functionality that every app needs. > Why should we stuff it into Ecore when it doesn't really fit? > > Compiling one more lib isn't that difficult and doesn't confuse anything. > > Along with that, what if someone wants to write a menu editor? They'll > need access to the fdo menu code as well. If it's stuck inside e17 then > they have to build it inside e17. Not an optimal solution. > > dan > I complete agree with you dan, make a separate lib so we can use it in many other project (also that not depend to e itself).
Dave > ------------------------------------------------------------------------- > 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 > > > ------------------------------------------------------------------------- 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
