Hi, Right now (with layout removed) Clutter only has one kind of size, which is (usually) equivalent to GTK's allocation.
With layout re-added presumably there will also be a request (possibly made up of a minimum and natural size). I'm wondering if it would work nicely to add a third size/position per-actor, a "transient allocation"; the idea of a transient allocation is that it's used for rendering, but is invisible to layout. Say I have a layout table of icons, and I animate the icons growing 25% on mouseover which includes a set_position() to keep the icon centered and a set_scale() to grow the icon. If I animate the size request (either min or natural), the entire table will reshuffle as I animate the icon - the icon's row and column will expand. This is probably not desirable (but could be in some cases, so animating the request is an option). On the other hand, if I animate the "transient allocation," the icon grows as rendered, but the layout of the table is unaffected - probably what's intended. Interestingly, I think if there were a request and a "transient allocation," then it would never be correct or useful to animate Clutter's current idea of size (i.e. the allocation determined by layout algorithm). In fact that current idea of size should probably always be strictly a function of request + layout algorithm and not settable by an app, in the presence of layout. (This creates some pretty weird back compat questions when layout is added.) Another thought related to this, it seems that get_size() combined with set_scale() already somewhat implements a "transient allocation"; because get_size() and query_coords() ignore any scaling. I _believe_ this is true even for group bounds; if I scale everything inside a group, the group's bounding box is still based on the unscaled child sizes (right? am I reading that code correctly?) So you can use the scale factor much as a "transient allocation". However, there's no equivalent for setting position - there isn't a separate translate() from set_position() as there's a separate scale() from set_size(). Perhaps transient allocation means "transform" but with a translate that works like current scale, i.e. separate from set_position(). Then animations use translate and scale, and layout allocates with set_position() and set_size(). "transform" is probably a better name than "transient allocation" (but still there should be a crisp understanding of how the various sizes/positions relate to layout) Another advantage of this is that a clear_transform() or reset_transient_allocation() kind of call is possible, which would drop the effects of any behaviors and revert to the layout-determined allocation. It could even automatically animate back to the original allocation. This is all pretty confusing and depends on how the layout is done, I'm assuming a layout system similar to GTK (well, hopefully closer to HippoCanvas which is the GTK model plus all the fixes we can't make easily in GTK for back compat reasons). But, I had this thought about "transient allocation" or position transform separate from the regular allocation, so thought I'd throw it out there. I'd like to be able to crisply separate animating the request (and thus the whole layout) vs. animating the presentation/rendering of an actor without touching its "logical" layout/size/pos parameters. Havoc -- To unsubscribe send a mail to [EMAIL PROTECTED]
