Opened 12 years ago

Closed 12 years ago

#8700 closed bug (fixed)

SoundPlay missing buttons

Reported by: Disreali Owned by: jscipione
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Experienced on a fresh install of hrev44270.

I installed SpoundPlay-4.7.3 via its install script and when I started playing music it was missing it buttons. SoundPlay works fine, the button are just not visible.

On hrev43883, SpoundPlay's buttons were visible.

Attachments (1)

hrev44270_Soundplay_has_no_buttons.png (10.8 KB ) - added by Disreali 12 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 by dcatt, 12 years ago

This is still an issue with the most recent builds of Haiku (hrevr1alpha4-44577)!

comment:2 by diver, 12 years ago

Component: - GeneralKits/Interface Kit
Owner: changed from nobody to axeld

comment:3 by scottmc, 12 years ago

Can you try installing an older liblayout and see if they come back? http://www.haiku-files.org/files/optional-packages/liblayout-1.4.0-gcc2-2009-03-08.zip Let us know if this fixes it.

comment:4 by dcatt, 12 years ago

Installed the older liblayout and the issue is still present.

comment:5 by SeanCollins, 12 years ago

This should be a alpha4 blocker with Haiku being BeOS hrev5 compatible.

comment:6 by czeidler, 12 years ago

could you test if hrev44039 causes it?

comment:7 by jessicah, 12 years ago

Just testing from nightlies available, hrev44020 is fine, hrev44062 the buttons disappear (still clickable though). I will try to make a build for hrev44039 soon.

comment:8 by jessicah, 12 years ago

Okies! hrev44039 has no visible buttons. Hope that helps! :)

comment:9 by korli, 12 years ago

Has hrev44038 visible buttons? :)

comment:10 by jessicah, 12 years ago

Yes, hrev44038 has visible buttons. Happy? :P

comment:11 by scottmc, 12 years ago

Owner: changed from axeld to jscipione
Status: newassigned

So it seems something in hrev44039 broke this, perhaps it can be fixed soon?

Last edited 12 years ago by scottmc (previous) (diff)

comment:12 by jscipione, 12 years ago

Soundplay expects the clipping constraints of the view to be ignored when drawing it's buttons. hrev44039 takes the view's clipping constraints into account in the following code:

// get the clipping constraints for the view
BRegion clipping;
view->GetClippingRegion(&clipping);

// intersect constraints with updateRect
BRegion updateClipping(updateRect);
clipping.IntersectWith(&updateClipping);

// clip to the intersection
view->ConstrainClippingRegion(&clipping);

Ignoring the clipping constraints of the view like in the following code fixes this bug but also breaks new code that assumes the the clipping constraints of the view will be honored.

// clip to updateRect
view->ConstrainClippingRegion(&updateRect);

Respecting the clipping constraints of the view seems like the more correct thing to do, but, since SoundPlay depends on the clipping constraints of the view being ignored when drawing it's buttons we need to also ignore them and then fix the code that depends on the clipping constrains of the view being set, most notably the code that draws the Return key in Keymap Preferences.

It is also a good idea to preserve the existing clipping constrains of the view by surrounding the button drawing code with PushState() and PopState() calls like this:

view->PushState()
...
view->PopState()

If nobody wants to tackle this I'll work on a fix shortly.

comment:13 by jscipione, 12 years ago

Resolution: fixed
Status: assignedclosed

I updated the button drawing code to preserve but not use the parent view's clipping constraints which fixes this bug but breaks the drawing of the return key in Keymap and then re-wrote the drawing code of the return key to work again in hrev44708.

Note: See TracTickets for help on using tickets.