On Mon, Mar 24, 2008 at 6:41 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > I wrote: > > Gustavo wrote: > > > >> anyone really looked at the patch? It says it all :-) > >> > >> > >> > > I saw the patch. But it refers to size 'hints', and still leaves open > > the question of obtaining an object's min/max size. > > > > > Let me be a bit more precise here: > > 1) Is it desirable to obtain an object's min/max_size? > 2) If it is, then: > is it a good idea to have a separate api function to get those values, > or do you intend that eg. to obtain the min_size, one should always > be able to do: > > evas_object_size_hint_min_set(obj, w = 0, h = 0); > evas_object_size_hint_min_get(obj, &w, &h);
I see what you mean, but I don't think we really need this, at least now. If we need this some day, we can extend it either by adding some range set and clamp to this range in setters, or we could add interceptors and make it generic. But adding these now, without a valid use-case (at least a real life, either in Edje, EWL or ETK) is over engineering. We can extend it later without breaking the API. Also, note that we callback on any size_hint setting, so object itself can listen for those in order to revert values. It will not be "atomic" and it might generate infinite loop if 2 peers bounce, but it will do for most of cases. What do you think about it? I'd leave it as is for now and possible add this noted in the comments. -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
