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. > errr*** Entrance Does. And it doesn't depend on E.
> 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? > I agree with replacing Ecore_Desktop if it cleanly solves the problems. No need for backward compatibility with Ecore_Desktop, since there's not much apps written for it yet. Efreet could just start life in cvs/proto/Ecore_Desktop2 for now, and (assuming we're all on the same page), become Ecore_Desktop as it matures. The argument for putting libraries into Ecore, is actually a pragmatic IMOHO one. When its *easier* for the developer to know that everything is provided by a *major* provider (like glibc is all you need for *most* *basic* UNIX programs). If you're developing a basic EFL application (the 70% case I'm assuming), you should need only do 3 things. 1. Choose b/w ETK and EWL 2. build against Ecore 3. Build against your application domain specific libraries It will make learning and developign for the EFL a matter of knowing Ecore for the most part and if you wanna do funkier stuff, then EVAS, Engrave, etc. Or maybe I'm actually meta-thinking about a lib that should be called libefl. I do understand the need for small and targetted, resulting in cleaner and better implementations, but a modular approach could work wonders (it seems ecore already does this? where you can build against parts of Ecore instead of the whole of Ecore). The code base itself, could be a main project itself like E17, ETK, EWL, EFL, etc... anyways... i'm ranting now. just my 2 kobo[1] Cheers, Essien [1] Kobo is like Cents in Nigeria :) > Peter. > > >> 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? >> >> Peter. >> >> >>>> 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.php&p=sourceforge&CID=DEVD >>>> EV _______________________________________________ >>>> enlightenment-devel mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
