On Tue, 08 May 2012 06:31:48 +1200, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
On 07.05.2012 09:15, Stephan Aßmus wrote:On 07.05.2012 00:34, Ingo Weinhold wrote:Having worked for a while with Qt now, I'm no longer convinced that implementing the "adding to view adds to layout" automatism was a wise decision. The other way around is obviously useful (and also implemented that way in Qt), but occasionally one does want to manage a child view independently of the layout. [...]It probably depends on what one is used to. I've never found it weird that BView::AddChild() and BLayout::AddItem() result in the same thing. In SWT, there is no method to add wigdets to a layout, the layouts always work on all children. Some of the layout implementations however support an "exclude" property in the layout data that can be associated with a child widget.I would argue that the API should make the common use case the most important, but still makes less common use cases like overlays (or the BBox label) possible.In that light, I would prefer an extra call, or even a view flag (B_EXCLUDE[_VIEW]_FROM_LAYOUT?) to achieve this rather than to let BView::AddChild() ignore the layout; I wouldn't find that very intuitive, at least.
no that would just make thinks more complicated and mix BView and BLayout more then necessary. As said before the BView::AddChild api is not sufficient to create arbitrary layouts. For example, a beginner who creates a simple BGroupLayout using AddChild would face the problem that he is not able to add a BSpacerLayoutItem. That is very confusing.
Using just BLayout for layout stuff is much cleaner. Furthermore, a separation would make it possible to add a view to multiple layouts and switch between the different layouts on the fly :)
Regards,
Clemens
ps. I would even remove the main AddItem(...) and AddView(...) from
BLayout. Already in a grid layout I would not be sure what it will do or
if it is allowed to used these methods. Each specialized layout should
provide appropriated methods by itself.
