> > In general I don't have any objections to the addition of size
> > hints to Edje, these could actually be useful to EWL as we could
> > use them in place of some of the existing size hints we get from
> > Edje. I'm not really certain why you want the ability to set the
> > min and max sizes programmatically since these are normally
> > determined by the EDC description, but I don't really see a
> > problem with it. It might be a
>
> the problem comes when you swallow something into a edje - it does
> not know the constraints of the object being swallowed - thus edje
> has calls like:
>
> 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.
These min/max values could actually change, as other properties
of the object (which can be 'set') are varied, due to internal
constraints and whatnot, but it makes little sense to 'set' the
min/max values of anything that's potentially intrinsic to an object.
Does it make sense to set the min/max values of the min_size property?
One can imagine setting lower/upper bounds for values of
properties (subject to those being constrained by the min/max ones),
with the meaning that setting arbitrary values for the property
will be stopped at those limits, but not really directly setting
min/max ones.
It's a bit of a semantic run-around, but not any more mojo
than the usual. :)
-------------------------------------------------------------------------
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
