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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
