Hi, On Mon, Feb 25, 2008 at 7:36 AM, Matthew Allum <[EMAIL PROTECTED]> wrote: > Now clutter actors have properties like min/max/natural sizes we are > imposing rules and making it harder and more complex to actually > implement actor subclasses.
I'm unsure what you mean by this concretely. In my patch, ClutterLabel becomes much simpler, ClutterTexture becomes a little bit simpler, and ClutterRectangle is unchanged in complexity. What is an example of a subclass that becomes harder? For actor implementations, none of the size-related methods are required if you subclass ClutterActor. In fact ClutterRectangle does not override any of them. That's because the default implementations all assume a size-will-be-set-manually kind of situation. The only reason to implement get_width_request/get_height_request is if your actor has some idea of its "normal" size, as a label or a pixbuf does. And in those cases, it's a big win if I don't have to go to a bunch of trouble if I set a new pixbuf or set new label text - if my app just automatically reflows. However, even in these cases, actor implementors can still skip get_width_request/get_height_request and be no worse off than they already are with Clutter today. A real proof that my patch doesn't impose any limitations on Clutter is that the test programs all keep working without modifications, except for test-project.c (but that one is easy to make keep working, I'm just not sure what the right API is). I do think some apps probably will require modifications, but the basic spirit and feel of fixed layout remains, and nothing that you could do before should become impossible afaik. (Proof: you can always set a fixed size or position on anything.) > In some use cases it makes sense but Im not > so sure the common case. Its much better imho if this can go as an > optional interface (above clutter) One problem with this is that Texture, Label, and Stage (to pick three examples in core Clutter) need to implement the interface. If we made this optional, we would need to replicate those three in the higher level, which is both not really possible right now, and messy even if it were. The second, and larger, problem with this is that I think having the request and allocation be the same simply doesn't work very well. I don't think a "no layout" application exists; even the test programs have layouts, it's just done manually in the app. With request and allocation the same, one ends up working around it all the time. One example of a workaround in Clutter itself is the sync-size flag in ClutterTexture (and the need for clutter_texture_get_base_size()). And of course some stuff just breaks, like interactive resizing - of the stage, or of an actor within the stage. I think the actual layout _algorithms_ - "layout managers" - are fine at a higher level, but what's really required at a lower level is to split the request from the allocation, which is what I've done in this patch. Also keep in mind, if people have highly specialized requirements, they can completely ignore this basic setup in Clutter itself and do their own thing - but I don't think they will need to do that very often, if at all. (Note, get_width_request/get_height_request are only used by the layout manager. You'll be able to drop in your own layout manager that ignores them. So no limitations are imposed on layout managers here.) But I don't think adding layout entirely outside of the core would work very well. I'm not even sure it's possible. There are a bunch of hooks in the core, from forcing layout on repaint, to queueing layout up the hierarchy (must be able to rely on all actors passing the relayout upward), to queueing relayout in set_parent(), to the request implementations in Texture and Label and Stage, to setting the X11 size hints in clutter-stage-x11.c, etc. > What kind of use cases (in terms of applications) are you thinking about > as to need this kind of core layout code ? Are you really thinking about > Clutter being used in applications where there top level surface is > reszied at run time and thus this kind of layout handling is needed ? It's not just caused by top-level surface resizing, but by dynamic changes of any kind. That is, if I am going to change the text in any labels, change images, dynamically add/remove items from a group, etc. I have definitely already been hand-rolling bad layout hacks that don't work well in my app, and I haven't even gotten into the more complicated parts. What I'm trying for here are the minimal hooks in Clutter itself to make it possible for apps to do layout. I think the core needs to split request and allocation, have an idea of 'queue relayout', etc. - it's just not going to work otherwise, or at least I don't know how to make it work. Havoc -- To unsubscribe send a mail to [EMAIL PROTECTED]
