Hi; (a prerequisite: Im really not an expert on layout or there implementation)
On Wed, 2008-02-13 at 12:04 -0500, Havoc Pennington wrote: > Hi, > > On Feb 13, 2008 11:19 AM, Matthew Allum <[EMAIL PROTECTED]> wrote: > > Therefor we decided to at least provide enough hooks in Clutter to make > > it easy for layouts (and policy) to be implemented outside of Clutter > > for a specific use case > > This is kind of what I'm wrestling with; Note other things we were thinking about were also animating layouts - exploding/imploding, collapsing/growing when items removed/added etc. It gets very hairy. > if I think about how I'd add > layout to Clutter, or add some kind of layout thing to my app anyway, > I'm wondering about a couple things. > > First, it seems like the layout system and behaviors would "fight" > over the allocation in an undefined way. Whenever the layout pass was > run, it would reset the sizes and positions of actors, which would > break any behaviors in progress. Thus the "transient allocation" idea > - then the regular allocation is 100% exclusively owned by the layout > system. Behaviors are allowed to modify either the request, or the > transient/transform allocation, but not the layout-determined > allocation. Yeah, we were thinking about some kind of 'memory' or lose binding for actors where they could essentially 'ghost' or free themselves from a container but no how to get back. I think this is similar to what you are suggesting ? > > Second, in at least one case (ClutterRectangle) the allocation is used > as the request. This leads to "infinite-grow" in the presence of user > resizing of toplevel windows, or of actors. User resize leads to > larger allocation leads to larger request (and request is the minimum > size). So stuff can be resized up but not down. > > If those two were resolved, the way I'd expect layout to work, > roughly, is that there's a default "fixed" layout manager which would > be like the current Clutter API except - crucially - the fixed > size/pos request would be distinct from the allocation. This is what > "freeform" uses of Clutter would use. Ok, can you send a rough patch (bugzilla maybe better) showing what you mean for something like the rectangle ? I think the kind of route we took before was this layout interface which provided a number of extra methods for doing the allocations that actors could implement. But it seemed pretty complex, too much ? Also for fixed sized 'displays/windows' it could be argued clutter is more targeted for, too heavier/obtrusive layouting can be more of a hindrance than an advantage. Not that Im saying layouts arn't useful there just not as critical as in desktop app - at least they should not get in the way if you want to do mostly fixed. A clutter app will usually know its eventual window size from start whilst a GTK+ will not (which makes sense to me - different use cases). Its worth keeping all this in mind. > > But another layout manager could be like HippoCanvasBox, which is what > you want for 2D-ish/html-ish/widget-ish aspects of a UI. I've always thought a html-ish box model could work nice. Also as a random note you can always clip actors to make them (appear) smaller. > > This seems to imply that the Clutter core would contain a "get size > request" interface, the Fixed layout manager, and transient > transform/allocation support, and a higher level such as Tidy would > pile on with the more complex layout managers. Yes I think so. > > > we've kind of started doing this in Tidy for > > example, and for this kind of thing its probably worth sending patches > > there. > > Oops, I'd missed the existence of Tidy somehow ;-) though on quick > scan it looks like it hasn't grappled with this stuff quite yet? Is > someone working on layout for that? (am I missing the important file > to look at?) > Hmm, afaik then ebassi hasn't yet had a chance to move some of the previous clutter stuff in? == Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
