On Mon, 24 Mar 2008 03:13:10 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> 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 and thus they change as the state changes and the object sets its own min/max and callbacks are called indicating they changed so anyone controlling/reparenting the object can "do the right thing" :) > 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. of course there it - smart objects. they need to be able to set their own. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
