On Fri, 16 Sep 2005 01:44:42 -0400 Jose O Gonzalez <[EMAIL PROTECTED]> babbled:
> Let me sharply critical here. > > Unfortunately for many other libs and apps, if evas is the > graphics engine they use, it's important to get it more than just > "good enough" -- as they will later find themselves stuck in the > situation where what was good enough earlier is not quite good > enough anymore.. What then? true. but given that i only have a few hrs a week to do this stuff. what do i work on? e is a priority. likely above evas in priority right now. > There are general patterns here, going beyond anything to > do with evas in particular, that lead to such things recurring > again and again... hampering the potential growth and development > of "e" in the larger sense. a lot of them can be changed internally at this stage and hidden/wrapped by ecore_evas (ie if we move event handling to an explicit process call). so only those doing their own display target bindings are affected (very few). for smart objects i think we cna do this all internally with no api-side effects so we can do this at any time in the future :) i actually wouldnt mind getting right of the smart class creator that accepts like 10 args forall the methods, but instead use the one that accepts the smart as a struct - we can then expand that strucxt until the cows come home. it's alreayd there, just not used. > If "e" aims to be a "gui platform" of some sort, say eg. > a "desktop shell", then it needs to take a serious look at its > foundations.. its subsystems... indeed - if i had the time i'd be devoting it there. :) > It needs to build these, and build from these, in a > systematic and coherent manner... and it needs to support > and facilitate all the 'standards' that people expect to have > these days. > > Unless this is done, e will never scale much besides > constituting a handful of very nice special-purpose programs > like a window manager, a graphical terminal, a login manager, > ... programs that, sooner rather than later, 'others' will be > able to duplicate in "coolness", and do so within the context > of a much more comprehensive framework. agreed, but the programs si what peolpe seem to be wanting and pining for. personalyl me too. peoelp are waiting for them. wanting them. its a 2 way street. u cant go make a set of libs and never have anything USE them. i agree we need to do things. i woudl be doing them mystelf - but i don't have time. i'm hoping others can get a firm grip on what to do int he meantime until i come back to it. > E will lead the way, in various gui related ideas, thanks > mostly to the tremendous creative talents and skill of a certain > nameless individual.. but it will never keep that lead for long, > or be able to capitalize on it. > > Jose. > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
