On Tue, May 20, 2008 at 3:37 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >>>> Anyone else looked at this? May I add the clipped smart object (no >>>> layout stuff!) to evas? I can add some docs and even change basic >>>> smart object to refer to this one for simple implementations. >>>> >>>> >>> >>> For those who are irc challenged, maybe you could give a short >>> overview of what it is this is supposed to help address, why it should >>> be 'added' to evas, etc. :) >>> >> >> It's just a way to help implementation of smart objects. Most common >> use smart objectcase: create an internal clipper, clip every child to >> it, move will move children relatively to parent, >> clip/clip_unset/color/show/hide will all go to the internal clipper. >> Resize is undefined. >> >> What this code provide is this set of default method implementation >> and an easy to extend base class, just do like in the examples and >> provide your own methods (be it constructor or resize or show... you >> name it), which can call the parent. I exposed all the base methods to >> make it easier to use, one can override show() to do fancy stuff and >> still call the original to do real work, this could be done >> differently, having users to copy (ie: parent_class) Smart_Class after >> evas_object_smart_clipped_smart_set() >> >> Why should it be added to Evas: because it's very simple, it's useful >> and can serve as base for other things. >> >> > > It's definitely useful to have such a ready-made simplifying > smart-class construction mechanism that could be 'overriden' - and > if you could couple that with some kind of object system for smart > data it might even be close to some aspects that the gui toolkits > already have. ;) > > But I'm not sure what you're proposing about doing with it in > evas itself..? Do you want to add a new 'clipped smart' object type, > or do you want to re-do the current smart stuff so that they have > default internal implementations for these smart functions but if > the functions are user-specified, then those are used rather than > the built-in default ones.. or something of that sort, or what?
just check ehelpers/evas_object_smart_clipped.[ch], they should go to evas/src/lib/canvas (and .h to Evas.h) no radical change, it's just an extensible way on top of what we have now, that I really feel is enough for our case: you can _VERY_ easily integrate that with other object systems. I did that for Python-EFL. >> Actually the idea of such component was born while I was teaching INdT >> guys and after documenting that you should always do the same stuff >> for most of methods I opted to add such default implementation and >> errors went down by a huge factor... actually nowadays it's hard to >> find a good case to use plain smart object itself. >> >> Al, one of things that I failed to figure in the past why show, hide, >> color_set, clip_set and color_set are ALL marked as DELETE ME. I don't >> remember for sure, but I think it was rephorm that did say that the >> common use case is like that and maybe these methods would be replaced >> with this default implementation only. So it's a good thing in that >> direction. >> >> > > I've been one who's pointed out issues with these in the past > as well, but the truth is that evas is not quite done with exploring > those things in full and it may well be that one could want to have > other implementations of such methods, or at least 'override' whatever > the default ones were.. so it may not be wise to remove them altogether, > no matter what jose, rephorm, raster, others may have said in the past > :) i'm fine with leaving them there, but if people can just avoid using it, we can check if there is any use case left in future and if not, maybe drop it. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
