Make layout API public

[mmadia]

This is a master ticket, to help track the various issues which prevent the layout API from becoming public.

[yourpalal]

fixed in hrev37817.

[mmadia]

Setting this as a blocker for entering R1/Beta's.

[yourpalal]

(In #6979) After looking into this, I think these two issues are symptoms of a larger one. Basically, in a BGridLayout, empty rows/cols are given no special consideration. Without items adding any constraints to a row or column, the max size for that row/column defaults to B_SIZE_UNLIMITED, which means that it will soak up any extra space in the layout (which is why the row isn't collapsing when the BMenuField is hidden). Also, empty rows and columns still have spacing applied, because they are not considered to be special.

What I'm thinking is to catch empty rows and columns (in BTwoDimensionalLayout) and basically discard them this means for layout purposes, they would take up no space, and not add any spacing. This situation is complicated a bit by the BTwoDimensionalLayout::AlignLayoutWith() feature, but when a layout is aligned with another, this would be disabled (maybe if both have the same empty row or column, we could still discard it). There could be a problem where applications rely on the current behaviour, but this could mostly be worked around by adding a BSpaceLayoutItem to the layout (which is more correct, anyway).

[bonefish]

Not sure, if that was the issue I forgot in #5526 (it isn't FBC related, though), but before making the layout API, I think the non-templatized layout builders should be phased out. Either by removing them completely and adjusting all code that uses them. Or (the lazy way) by moving them to headers/private for the time being. Or (the very lazy way) the headers should clearly be marked obsolete.

Moreover, it seems BSplitView could use some love. I assigned #7902 to you. Also the method naming should be rechecked. E.g. we have Set*Item*Weight(), but SetCollapsible() (the item/items version, I mean). Also Is[Item]Collapsible() would be nice to have, as well as Set[Item]Collapsed() and Is[Item]Collapsed().

[yourpalal]

Replying to bonefish:

Not sure, if that was the issue I forgot in #5526 (it isn't FBC related, though), but before making the layout API, I think the non-templatized layout builders should be phased out. Either by removing them completely and adjusting all code that uses them. Or (the lazy way) by moving them to headers/private for the time being. Or (the very lazy way) the headers should clearly be marked obsolete.

Yes, absolutely. I was thinking to add some compiler errors/warnings so that third party apps can still build for a little while, but on further reflection, if these are going to disappear from libbe, it is probably worth it to do something a little stronger, since there will be runtime errors down the line. Better to hurt the devs using unfinished API's than the users ;) Maybe we can leverage GCI to get all the Haiku code using the old builders converted.

Moreover, it seems BSplitView could use some love. I assigned #7902 to you. Also the method naming should be rechecked. E.g. we have Set*Item*Weight(), but SetCollapsible() (the item/items version, I mean). Also Is[Item]Collapsible() would be nice to have, as well as Set[Item]Collapsed() and Is[Item]Collapsed().

Yes, naming is another thing I want to go over, making sure everything is consistent and easy to understand. Another example is the BAbstract* classes have hook methods name Base*(), but I wonder if they should be renamed to something like Derived*(), which is more correct, I think, and is also used elsewhere (IIRC).

[yourpalal]

Yes, naming is another thing I want to go over, making sure everything is consistent and easy to understand. Another example is the BAbstract* classes have hook methods name Base*(), but I wonder if they should be renamed to something like Derived*(), which is more correct, I think, and is also used elsewhere (IIRC).

I decided to leave those methods as Base*(), child classes that reimplement these methods are overriding the base class' implementation. Derived() makes more sense for pure-virtual methods.

[pulkomandy]

All the children items are closed, and some apps outside Haiku are using the layout system now. Closing this as fixed.