Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#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 anevilyak)

Since '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)

0001-Fix-layout-issue-in-Backgrounds-preflet.patch (1.4 KB ) - added by yourpalal 7 years ago.
fix for bug #9882

Download all attachments as: .zip

Change History (12)

comment:1 by anevilyak, 7 years ago

Description: modified (diff)

comment:2 by yourpalal, 7 years ago

Status: newin-progress

comment:3 by yourpalal, 7 years ago

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:

  1. the min width of the column (eg. the width of the default "HAIKU logo - white on blue - big.png" value) or
  2. width of the checkbox

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.

by yourpalal, 7 years ago

fix for bug #9882

comment:4 by yourpalal, 7 years ago

patch: 01

in reply to:  4 comment:5 by yourpalal, 7 years ago

Replying to yourpalal:

Since my I don't currently have ssh access to, I figured I would just upload the patch here

comment:6 by anevilyak, 7 years ago

Resolution: fixed
Status: in-progressclosed

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 yourpalal, 7 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!).

comment:8 by diver, 7 years ago

Should the same fix be applied to MidiPlayer too or it shell be fixed as part of #9882?

in reply to:  8 comment:9 by yourpalal, 7 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 jscipione, 7 years ago

Fixed properly in hrev47166 (the previous fix, while worked, was kind of a hack)

comment:11 by jscipione, 6 years ago

Applied similar fix to MidiPlayer in hrev47438

Sorry for the oversight diver and yourpalal.

Note: See TracTickets for help on using tickets.