BLayout should derive from BLayoutItem, and should function without a BView.

[yourpalal]

BLayout should derive from BLayoutItem, so that we can avoid creating BViews with the sole purpose of having a BLayout attached to them!

However, this change will cause some compilation problems, so it will have to be done in stages:

1 Update Applications to reflect the impending changes in step 2

2 Update layout builders and remove their operator* BView which will cause compilation ambiguities once BLayout is a BLayoutItem when a layout builder is passed to BView::AddChild() or BWindow::AddChild(). At this point, methods will also be added to the layout builders to facilitate use of viewless BLayouts, but they will not create viewless layouts.

3 Derive BLayout from BLayoutItem, and provide mechanisms for correct operation under viewlessness. Also update BLayout sub-classes to use these mechanisms.

4 Update layout builders to actually create viewless layouts under the correct situations.

5 Add an easy enhancement ticket for updating apps to make better use of viewless layouts, probably with hints at how to do this.

[tangobravo]

Just out of interest, what's the need for a viewless BLayout? What's the use-case?

[yourpalal]

Replying to tangobravo:

Just out of interest, what's the need for a viewless BLayout? What's the use-case?

Basically, there are two places where it will be useful:

• It will allow for nested layouts, so that instead of this kind of thing:

  BGroupView* myGroupView = new BGroupView(B_HORIZONTAL);
  BGroupView* nestedGroup;
  myGroupView->GroupLayout()->AddView(nestedGroup = new BGroupView(B_VERTICAL), 5);
  nestedGroup->AddChild(new BButton("a"));
  nestedGroup->AddChild(new BButton("a"));
  myGroupView->GroupLayout()->AddView(nestedGroup = new BGroupView(B_VERTICAL), 2);
  nestedGroup->AddChild(new BButton("b"));
  nestedGroup->AddChild(new BButton("b"));
  nestedGroup->AddChild(new BButton("b"));
  

You could forego the creation of the nestedGroup BView, and simply add BGroupLayouts to myGroupView. This way, we avoid the overhead of having another two views in there, when their only purpose is to host a BGroupLayout. This also means that all those BButtons will be children of myGroupView. (That's not really an advantage, but I thought I'd mention it) An even more 'extreme' scenario might be to avoid adding any organizational views at all to your window (of course, BWindow::fTopView will still be there).

• Another use case is laying out objects that are not strictly related to BViews. (Composing a document for example, you could use many nested layouts for the different elements).

[yourpalal]

Patch for review

[yourpalal]

description of patch

[yourpalal]

Commited in hrev38207, leaving this ticket open for a while for regressions and so on.

[diver]

white background in Terminal settings

[diver]

I'm not completely, but after hrev38207 Terminal settings window looks like this:

Before there was white border which had been caused by some other changes.

[diver]

Again, I'm not sure if it's related to hrev38207, but Mount settings window in tracker is empty now.

[yourpalal]

Replying to diver:

Again, I'm not sure if it's related to hrev38207, but Mount settings window in tracker is empty now.

Yes, it is, I've fixed it in hrev38281, thanks for catching these! I also fixed the Terminal settings one earlier.

[diver]

Thanks!

[yourpalal]

Everything seems to be working fine, so I'm closing this ticket as fixed.