#9882 closed bug (fixed)
Odd BGridLayout behavior
| Reported by: | anevilyak | Owned by: | yourpalal |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Kits/Interface Kit | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description (last modified by )
Since http://cgit.haiku-os.org/haiku/commit/src?id=7910d8b89cc2285eba6efc8c16475dd06617bc8b 's changes to BCheckBox's preferred width, some odd behavior has been visible in the Backgrounds preflet. The latter uses a grid layout with two BMenuFields and a BCheckBox, all in separate rows, where rows 0 and 1 each have two layout items for the label + menu spread across columns 0 and 1, and row 2 has just the BCheckBox in column 1. Picking the Image menu field in row 0 and picking "None" for the choice of image causes it and its respective label to jump to the right. Picking another longer name brings it back to normal. This behavior makes no sense though, since the checkbox isn't even in the same row, and one would expect any influence of the checkbox to affect all of column 1, not just that single row.
Attachments (1)
Change History (12)
comment:1 by , 11 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 11 years ago
| Status: | new → in-progress |
|---|
comment:3 by , 11 years ago
by , 11 years ago
| Attachment: | 0001-Fix-layout-issue-in-Backgrounds-preflet.patch added |
|---|
fix for bug #9882
follow-up: 5 comment:4 by , 11 years ago
| patch: | 0 → 1 |
|---|
comment:5 by , 11 years ago
Replying to yourpalal:
Since my I don't currently have ssh access to git.haiku-os.org, I figured I would just upload the patch here
comment:6 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | in-progress → closed |
Applied in hrev45892, thanks! As far as ssh access goes, I'd advise emailing Oliver, he should be able to get you taken care of.
comment:7 by , 11 years ago
Thanks for applying :) I filed a ticket for the BMenuField layout issue that was exposed by this bug: #9889. Unfortunately, I don't have time to fix it right now (although I tried for a few hours!).
follow-up: 9 comment:8 by , 11 years ago
Should the same fix be applied to MidiPlayer too or it shell be fixed as part of #9882?
comment:9 by , 11 years ago
Replying to diver:
Should the same fix be applied to MidiPlayer too or it shell be fixed as part of #9882?
I haven't looked at MidiPlayer, but probably the same fix should be applied, yeah. The layout issue here was just caused by someone relying on the old behaviour of BCheckBox when designing the layout. The fact that there hasn't been many things broken by the change in alignment shows (IMO) that the old behaviour was kind of unexpected in the first place!
The other ticket I filed is for an unrelated bug that only became visible with this change to BCheckBox, even if it were fixed right now, there still would have been an issue in Backgrounds.
comment:10 by , 10 years ago
Fixed properly in hrev47166 (the previous fix, while worked, was kind of a hack)
comment:11 by , 10 years ago
Applied similar fix to MidiPlayer in hrev47438
Sorry for the oversight diver and yourpalal.
The reason row 1 (Placement menu field) isn't reacting appears to be an invalidation bug. If you adjust the value of the placement dropdown, the menu will often move into the correct position, aligned with row 0's image menu.
The invalidation bug is hiding a simple layout bug produced by the change to BCheckBox: although the menubars have infinite max width, the column width is being set by either:
By adding a third column which contains the menubars, but not the checkbox, we can avoid this problem.
I've got a fix for this ticket committed locally, but I'm going to look into the invalidation bug before pushing.