Carsten wrote: > > > > > > edje_extern_object_min_size_set() > > > edje_extern_object_max_size_set() > > > edje_extern_object_aspect_set() > > > > > > these attach hints via a generic data + string key attaching > > > mechanism so edje can pick them up when swallowing. of course > > > formalising these as intrinsic properties of an evas object > > > would make this cleaner and provide more usefulness for other > > > things. > > > > > Yeah, but that's just so that you can *get* the min/max sizes > > - because there's no other way since arbitrary evas objs don't > > have such min/max_size properties. If they did, you could just > > 'get' them. > > > > bingo. that's the whole point of it - set them, be able to get > > them, have callbacks and events when they change (just like resize, > > move etc.). > > Not quite. The question is: what sense would there be in *setting* the min/max_size values on any object - period. The object could have non-trivial such values, due to internal constraints on its current state, but you wouldn't *set* these directly via an api func - the object calculates them and gives you those min/max values.. ie. you can *get* such things via an api function. But there's no sense that I can see in an api function to *set* them.
I can imagine setting min/max_size_hints, and understand various possible semantics for it, but that's not the same as an object's min/max_size. The former would still be constrained by the latter, and only the object can determine the latter. ------------------------------------------------------------------------- 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