Opened 15 years ago
Closed 11 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: | |
Platform: | All |
Description (last modified by )
This is a master ticket, to help track the various issues which prevent the layout API from becoming public.
Change History (18)
comment:1 by , 15 years ago
Blocked By: | 5525 added |
---|
comment:1 by , 15 years ago
Blocked By: | 5525 removed |
---|---|
Component: | Kits → Kits/Interface Kit |
Owner: | changed from | to
comment:2 by , 15 years ago
Blocked By: | 5525 added |
---|
comment:3 by , 15 years ago
Blocked By: | 5526 added |
---|
comment:5 by , 15 years ago
Description: | modified (diff) |
---|---|
Summary: | Make Layout Kit public API → Make layout API public |
comment:6 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → in-progress |
comment:7 by , 14 years ago
Blocked By: | 6403 added |
---|
comment:9 by , 14 years ago
Blocked By: | 5614 added |
---|
comment:10 by , 14 years ago
Blocked By: | 6407 added |
---|
comment:11 by , 14 years ago
Blocked By: | 6543 added |
---|
comment:12 by , 14 years ago
Milestone: | → R1/beta1 |
---|---|
Priority: | normal → blocker |
comment:13 by , 14 years ago
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 by , 13 years ago
Blocked By: | 7683 added |
---|
follow-up: 16 comment:15 by , 13 years ago
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()
.
follow-up: 17 comment:16 by , 13 years ago
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()
, butSetCollapsible()
(the item/items version, I mean). AlsoIs[Item]Collapsible()
would be nice to have, as well asSet[Item]Collapsed()
andIs[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 by , 13 years ago
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 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
All the children items are closed, and some apps outside Haiku are using the layout system now. Closing this as fixed.
Setting this as a blocker for entering R1/Beta's.