On Thu, 20 Mar 2008 23:07:12 -0500 "Nathan Ingersoll" <[EMAIL PROTECTED]> babbled:
> 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. > little confusing to the themer if the programmatic setting is > overriding their expectations from the theme, but it's probably a rare > case. it is something a themer needs to account for. some things may get swallowed in and thus control the size of a design. they can set a max size to the swallow part that controls the client window of a window border in e - but this is pretty much useless as the client window itself is the controlling entity. > I do have concerns about the layout in Edje that was hand-in-hand with > this size hinting discussion, but that probably deserves another > thread. Just to sum up my thoughts on it though: not a fan of yet > another layout lib, would prefer to see edje support for relative > layout descriptions, and it seems like the base issue you're working > around is the level of primitives Edjeedje_extern_object_aspect_set operates > on. well it already is relative - everything is, BUT it is not repeatably relative. i.e. "put this button into this container, add another one, and another one, and another... etc." so u have a hbox/vbox kind of setup, or for that matter a table etc. etc... designers are actually asking for this kind of stuff as a convenience for design, and as such edje would then be providing these. designers then being able to control such a box with more complex parameters (like parametric scaling of entries based on distance from a fixed point in the output, or a selection point etc. would make it possible to even do a "osx dock" directly in edje just with fiddling the right parameters and math - but this then lets the designer do it, and not require a programmer). i guess that's the point of layout stuff in edje. it has in fact been there waiting to happen for a long time. edje_container.c has been there forever and a day - but just empty stubs... :) > On Thu, Mar 6, 2008 at 12:59 AM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: > > We were discussing about this idea at IRC and the summary is written at: > > > > http://wiki.enlightenment.org/index.php/Evas_Object_Size_Hints > > > > Idea is to move this common requirement to Evas_Object so it can be > > shared by toolkits, Edje and even the layout smart objects I plan to > > add someday in future. Adding this is pretty straightforward and I > > should do it soon, next moving Edje to use it. > > > > Any comments on that? Requirements we failed to notice? Better > > functions/types names? > > > > -- > > 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 > > > > ------------------------------------------------------------------------- > 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
