Viktor Kojouharov wrote: > On Tue, 2008-12-09 at 01:57 -0500, Jose Gonzalez wrote: > >> Sebastian Dransfeld wrote: >> >> >>> Jose Gonzalez wrote: >>> >>> >>>> Gustavo wrote: >>>> >>>> >>>> >>>>> On Mon, Dec 1, 2008 at 8:15 AM, John Lee <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>> >>>>>> ... by adding 3 callbacks to viewport->event and connecting >>>>>> them back to the original callbacks. >>>>>> >>>>>> Signed-off-by: John Lee <[EMAIL PROTECTED]> >>>>>> >>>>>> >>>>>> >>>>> nobody replied to this in a while, so I commited to ETK as it seems to >>>>> work. >>>>> >>>>> Thanks for the patch and sorry taking so long to commit. >>>>> >>>>> >>>>> >>>> Since my retiring from work on evas, I took a better look at etk.. and >>>> I have to say that there's a lot that could be done to it, not only fixes, >>>> but also major internal refactoring, some api changes, and more 'basic' >>>> stuff. >>>> >>>> >>> Then you should also realise that etk is a dead end, and no one is going >>> to do any major work on it. Don't waste your time. >>> >>> Sebastian >>> >>> >> Really? That's quite severe.. especially since much of this >> stuff is fairly straightforward to accomplish. >> What makes you state with such certainty that "etk a dead end" >> just because some refactoring and improvements could be >> made to greatly improve the lib? Or do you mean it might >> be better to start with a new code base? >> > > I think that if you have time to work on these things, you are more than > welcome to do so. Since Mo0m has long retired etk development, I don't > think the rest of us will object. Though, if you do happen to break an > API, would be nice to sed the svn for the relevant changes in the > apps :) >
I may decide to play with it.. experiment here and there. But you should realize one thing: A lot of aspects of something like etk (and others) ultimately suffer not because of its 'design', but rather because of evas' design. If I were developing etk, and developing it to become something more powerful, flexible, and self-contained.. there would likely come a point where it would become necessary to use something other than current "evas" for its rendering and other things. Ideally, one would base it on something with the same object/event system, but also possibly allow for accessing gfx nodes which aren't event driven. In some ways, the gtk folk face a related issue. They want to extend gtk to a more flexible system in various ways, and have a retained-mode rendering system to go along with this. They could modify the current gtk widget to allow for 'embedding' such into a suitable (gobject based) canvas system (like clutter or goocanvas), or they could try and build the widgets on top of such a gobject-based canvas system. > That being said, the scene-graph ideas you have will be especially > useful (probably in evas as well). Currently, etk's tree and other > scrolled widgets are dead slow. > > Scrolling is a difficult one for an alpha-blended, compositing rendering system to do efficiently. But a lot could be done in evas to improve this. A related issue is the entire way that it builds its current render pass.. this needs redoing, not only for better dealing with such things, but also if it ever wants to correctly have such things as transformed/filtered compound objects (ie. smart objects). However, this would have to be done by someone else - my work on current evas is over. > Though I really don't think how relevant etk (or ewl for that matter) > will be in the future. It's a good bet that raster will use elementary > to replace e17's internal widgets (either for e17 or for a future > release). If that happens, we will have a blessed widget set, so any > future development will most likely be based on it. > That depends on who's doing what development... Raster and e17, or whomever/whatever else should use whatever they feel suits them best . It'd be up to those doing 'development' to decide just *what* development in "e" consists of -- I find the current state of things rather limited in many ways. ____________________________________________________________ Visa, MasterCard, AMEX & Discover. Compare Offers & Apply Online. Click here! http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2Oq4GN5LSdEP4lWFNjxXmYoNB4Q4mIBklOLIbkmLG2YkHGU/ ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
