>>> 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?
> 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
:)
-------------------------------------------------------------------------
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
