On Tue, Jul 10, 2012 at 12:03 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > On Monday, July 9, 2012, Carsten Haitzler wrote: >> On Mon, 9 Jul 2012 11:24:03 +0100 Michael Blumenkrantz >> <michael.blumenkra...@gmail.com <javascript:;>> said: >> > I don't know, but the idea of having to go to >> > efl/src/lib/ecore/src/lib/ecore_con/file.c makes me not want a single >> tree >> > at all >> >> god no. it'd be >> >> efl/src/lib/ecore_con/file.c >> >> ecore would flatten out to its component ecore_*'s - other libs wouldn't >> need >> more than a single dir. >> >> > Seems good, but 'src' is useless. It would be nice to also keep a > consistency of plugins x modules.
I disagree, we have data, docs, m4 and src at the first level. And I think they do split information nicely. I don't really care about going one more directory below, it will be filled with lib, bin, tests and examples (maybe benchmark ?). > Tom suggest GUI x core... I'd be against it, EFL is basically for GUI and > split the core of that is not of use. Maybe the lib, but please not the > packages. I am for. EFL is not only about GUI. You can write light server and service with them. People are advocating using Qt for that can of job. I believe that EFL do compete quite well in that area. We would need to push more at azy, esskyuehl to improve the experience for this class of application (Basically writting daemon that are usefull to us). -- Cedric BAIL ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
