Gustavo Sverzut Barbieri wrote: > On Tue, Dec 9, 2008 at 5:00 AM, Sebastian Dransfeld > <[EMAIL PROTECTED]> wrote: > >> 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? >>> >> As it is now, none of the main developers are using time on etk, and >> raster and Gustavo have their own widget libraries (elementary/guarana). >> > > do not consider elementary and guarana separate entities, they're for > now, but we'll merge soon, just need time, but xmas is there for this > kind of thing ;-) Probably we'll make adapt grn_widget and > grn_edje_widget as the basics and move elm widgets on top of it, then > drop guarana_widgets, guarana will continue as other libraries that do > not contain widgets. But even before that, being simple smart objects > make it easier to merge, including with esmart. > > > >> The design of these widget libraries differ from etk, as they are 100% >> evas centric and use smart objects heavily. >> > > yes, and I really think this is way better, both for library > developers and users. > > > There's more than one way of realizing a (retained-mode) canvas gui system Gustavo. The approach taken by evas is but one - neither inherently 'better' nor 'worse' than some others.
When it comes to the very basic notion of just what "the canvas" is supposed to be, ie. how it should be represented via some api, there's more than one way it could be done. In evas, there's a fundamental distinction between 'the canvas' and 'the canvas objects', they are not exported as the same sort of thing. But this is not necessary for a canvas system, and for example in things like "Clutter" there are only 'canvas-objects' (what they call "Actors", all of which inherit from gobject), it's just that there are special 'top-level' such objects (what they call a "Stage"), which all other objects must be children of. This latter approach actually has its own merits, but in truth, there's little essential difference between "add an object to an abstract canvas thing" vs. "add a child object to a canvas object". In etk, there's a "canvas" widget (which if desired, could be allowed to be a top-level widget) to which you can add aribitrary child widgets. It has some api cruft around it, but really the only 'limitation' it has is that there are no native 'gfx-widgets' in etk. What etk does allow for (modulo limitations it inherits from evas and edje) is a far richer system for many other kinds of things (as eg. edje allows for more than evas alone can - it uses aspects of ecore), including a different kind of object and event system. The decision to view a 'canvas system' in either of the above mentioned ways is more a matter of taste and possibly externally related decisions, than it is a case of one being 'clearly better' than the other. As far as evas smart-objects go... If you think about it, you'll see that this is basically the same kind of order of magnitude issue as the above one. >> The only work done on etk is small fixes to keep it usable. >> > > and this is mostly dave because he is using for edje_editor... however > I see Dave moving to elementary once we have what he needs. and we're > not far. > Whatever works best for him. ____________________________________________________________ Visa, MasterCard, AMEX & Discover. Compare Offers & Apply Online. Click here! http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2Oq3mUbpvlzEPasqtPO42Cwb3FyTimQjCzNwoRpJDiOOCnS/ ------------------------------------------------------------------------------ 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
