Hi; Ok - so I am beginning to get things now.. I think. Mr Bassi at least tried to explain things to me :)
Am I correct in understanding that adding this patch wouldn't (at least by intention) have any affect/change on how clutter is currently used (from a fixed pov) nor any kind of performance impact ? And in that its actually pretty cool ? Thanks for bearing with me on this. I really have no experience of layouts and I guess much of my fear is in something I cant really visualise. In that Im worried that we're perhaps missing something really obviously dangerous here. I really need to study the patch closer, and if you feel the motivation to give (or point at) a quick layouts for dummys it would be much appreciated. Many thanks; == Matthew On Mon, 2008-02-25 at 10:28 -0500, Havoc Pennington wrote: > 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]
