Hi, On Tue, Feb 26, 2008 at 7:05 AM, Øyvind Kolås <[EMAIL PROTECTED]> wrote: > I'm wondering exactly what scenarios and types of layout management > will be possible by this added infrastructure and what would remain > impossible/outside the scope of it. Like matthew I'm accustomed > to some more free form APIs than GUI toolkits and 2d canvases provide > and I wonder whether this is only about 2D layouts or if the > infrastructure is powerful enough to cater to other, unforeseen needs > as well.
The scope of this is really 2D layout only... but, it should not make anything impossible that was possible before. Also, a custom layout manager could choose to consider 3D properties. Remember, all the patch adds in the end is a request hint - hint about desired 2D size of the actor. It retains the idea that the actual 2D location of the actor is a ClutterActorBox which is a 2D box, just as Clutter had before. So, if you could previously implement your more complex 3D layout system by modifying Clutter, you still can. > How would this be implemented, by adding a hashtable to the container > with a mappings between the child actors and the additional layout > implementation specific hints? In GTK it's usually done with a linked list of structs, like GtkBoxChild. But you could also do it with a hash table or with object data. We could also add API to ClutterGroup for the purpose, perhaps, like clutter_group_set_child_layout_data() or something, not sure that is helpful. > What possibilities open up for layout management that interacts with > animated properties? In particular I wonder how it is possible to > integrate with 3D specific properties, like rotation around the x or y > axes or change of depth? Currently the patch ignores the transform (scale, rotate, and anchor point) for layout purposes. This is in part so you can do animations that do not affect the layout. (For scale, you can animate width/height instead if you want to affect layout, and for anchor point you can animate x/y position instead if you want to affect the layout.) An alternative layout manager could apply the 3D transformation to the size request hint before using it, if it that is useful. I should say - I guess the current patch doesn't really have a policy on ignoring the transform or not, since it doesn't really do any layout that's size-dependent (it just does fixed layout). But, my intent is that a box layout would ignore the transform. > Or are the above quesitons and concerns mostly irrelevant and such > layout management something that only really applies when doing pure > 2D static / fluid due to containers changing size interfaces. And > animated or more 3d use of the API would only make sense with the > fixed layout provided by the default implementation? I am mostly thinking about layout for relatively 2D cases, I think there could be 3D layouts and this patch would not break them, but I don't know a lot about what a 3D layout would be like. Ultimately Clutter does encourage a somewhat 2D way of looking at the scene graph, I think. That's part of why it's more useful for UI type apps than other 3D APIs are. Havoc -- To unsubscribe send a mail to [EMAIL PROTECTED]
