Opened 9 years ago

Closed 5 years ago

#5524 closed enhancement (fixed)

Make layout API public

Reported by: mmadia Owned by: yourpalal
Priority: blocker Milestone: R1/beta1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: #5525, #5526, #5614, #6403, #6407, #6543, #6979, #7683 Blocking:
Has a Patch: no Platform: All

Description (last modified by bonefish)

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

Change History (18)

comment:1 Changed 9 years ago by mmadia

Blocked By: 5525 added

comment:1 Changed 9 years ago by mmadia

Blocked By: 5525 removed
Component: KitsKits/Interface Kit
Owner: changed from nobody to axeld

comment:2 Changed 9 years ago by mmadia

Blocked By: 5525 added

comment:3 Changed 9 years ago by mmadia

Blocked By: 5526 added

comment:5 Changed 9 years ago by bonefish

Description: modified (diff)
Summary: Make Layout Kit public APIMake layout API public

comment:6 Changed 8 years ago by yourpalal

Owner: changed from axeld to yourpalal
Status: newin-progress

comment:7 Changed 8 years ago by yourpalal

Blocked By: 6403 added

comment:8 Changed 8 years ago by yourpalal

Last edited 8 years ago by yourpalal (previous) (diff)

comment:9 Changed 8 years ago by yourpalal

Blocked By: 5614 added

comment:10 Changed 8 years ago by yourpalal

Blocked By: 6407 added

comment:11 Changed 8 years ago by yourpalal

Blocked By: 6543 added

comment:12 Changed 8 years ago by mmadia

Milestone: R1/beta1
Priority: normalblocker

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

comment:13 Changed 8 years ago by yourpalal

Blocked By: 6979 added

(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).

comment:14 Changed 8 years ago by yourpalal

Blocked By: 7683 added

comment:15 Changed 7 years ago by 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().

comment:16 in reply to:  15 ; Changed 7 years ago by 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).

comment:17 in reply to:  16 Changed 7 years ago by 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.

comment:18 Changed 5 years ago by pulkomandy

Resolution: fixed
Status: in-progressclosed

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

Note: See TracTickets for help on using tickets.