On Thu, 10 May 2012 03:05:55 +1200, Alex Wilson <yourpalal2@xxxxxxxxx> wrote:
thats definitely a solution but IMHO not a nice one. I just took a look atqt *) and they do it my way :-) Using AddChild to add a layout if there is a SetLayout method does not follow the principle of least astonishment either. I think its onlyastonishing for someone who knows BLayout very well that SetLayout adds alayout that not spans the whole BView frame.I don't agree here. The PLA doesn't just mean everything behaves in the simplest way, but it means that there is a conformity to the API. If you learn what SetLayout does in x - 1 cases, the xth case should not surprise you. If you learn that BLayout is a BLayoutItem (an easy thing to learn if you start making complexish layouts), then it is not surprising at all that you can embed it into another layout with AddItem() (or AddChild() on a view).
but thats not the simplest way and its even less powerful. Everybody who is using AddChild will need to switch to BLayout for more complex stuff so why use AddChild in the first place? The simplest solution is:
- AddChild behaves like in R5 - each view can hold exactly one layout which can be set by SetLayout- the layout can be positioned in the view using an layout inset (for compatibility reasons the inset is only for the layout!)
that solves all the problems mentioned previously in this thread and AddChild and SetLayout have a clear defined behaviour. :-)
As a backup for this hypothesis I can only point back to the stunning simple qt QGroupBox example. I looked into the QGroupBox source and zero magic is going on there! just the use of the standard api no need for QGroupBoxLayout :-)
I don't think completely abandoning this mechanism is the right choice, for the reasons I have given above, and also for one more. I've done big changes to the layout API before, and adjusting and testing the various apps/preflets in Haiku is a big job. It's also very boring and error-prone. I don't think I've ever caught all the errors, thankfully people like diver on Trac seem to find the ones I miss.
yeah that would be a bit of work :(
- a view could be in multiple layouts (yes it is not a very common example(but also not totally beside the point) but it shows that it is possible without further effort)I don't understand why the current auto-add behaviour prevents this. Unless you are also planning to remove the guarantee that a BView with a BLayoutItem in a BLayout will be a child of the BLayout's target BView. I guess that would be doable, but it would mean that you'd need to add every view to both the BView and the BLayout, which would be a huge pain.
ok an example use case is that you have two different BLayouts fLayout1 and fLayout2 holding the same views. fLayout1 is child of another parent layout which is attached to a target view. Thus all child items of fLayout1 are attached to the target view. fLayout2 is not attached to any view. Now you want to switch between both layouts for some reason. That can be done by doing:
parent->RemoveItem(fLayout1); parent->AddItem(fLayout2, ...);This removes fLayout1 and all views from the target view and adds fLayout2 and all child views again. You can also switch it back:
parent->RemoveItem(fLayout2); parent->AddItem(fLayout1, ...);So only if the layout is attached to a target also the child items are guaranteed to be attached to the same target view.
Cheers,
Clemens
