View Issue Details

IDCategoryLast Update
0000211bugs2007-02-15 13:13
ReporteroofusAssigned Topaul 
Reproducibilityalways 
Status closedResolutionfixed 
Platformi686OSLinuxOS VersionMDK 9.2
Product Version 
Fixed in Version 
Summary0000211: Most buttons do not show their status (colour) when the mouse is hovering over them
DescriptionClick on a solo/cut/record ... etc button and it depresses as it should do; however it does not change its colour until the mouse has moved outside of the boundry of the button. Move the mouse back over the button and its intended colour goes away.

Quite trivial but also quite anoying.
Steps To ReproduceClick any button, hover the mouse over the button. Colour is a gray instead of the correct one. move the mouse away from the button, colour is as it should be. Hover mouse back over the button, colour goes away again.
TagsNo tags attached.

Relationships

has duplicate 0000094 closedpaul Hovering over active (red) rec buttons changes colour 
related to 0001380 closedpaul beta 8: Color of switches when selected / pressed 

Activities

paul

2004-02-11 19:38

administrator   ~0000407

We cannot fix this in GTK+ 1.X. Widgets have a "prelight" state that cannot be disabled in any general way, and not even all the time for the widgets where it can be disabled. After we port to GTK+ 2.X, we hope to disable prelighting completely.

taybin

2006-11-06 18:21

administrator   ~0002682

So is this fixed with the change to gtk2?

obligog

2006-11-06 20:26

reporter   ~0002688

Unfortunately not. It has changed slightly though. The colour you get when hovering the mouse over a lit button is it's unlit colour rather than grey now.
The most annoying one is the channel record arm button, when clicked it's pastel red. When the master record is enabled and the track is recording, it's bright red. If you hover over the track record enable button it turns pastel red again and stays that way.
Quiet miss-leading !!

taybin

2006-11-06 20:35

administrator   ~0002689

Could this be a theme problem?

paul

2007-01-27 18:09

administrator   ~0003115

alas, i was wrong about the ability to disable prelighting.

basically, this cannot be fixed until the GTK team see the problem with prelighting. i must check that there is a bug filed for this in GNOME bugzilla.

oofus

2007-01-27 18:56

developer   ~0003120

So how did you make the transport keys not exhibit prelighting ?

paul

2007-02-13 16:42

administrator   ~0003230

fixed in svn.

oofus

2007-02-15 00:33

developer   ~0003287

Fixed for the important buttons (Rec, Solo and Mute), others still exhibit the behaviour.

paul

2007-02-15 13:13

administrator   ~0003299

i don't intend to remove "prelight" from every button, only those where its presence causes confusion in users about the current state of the button.

if you think there are other buttons where this confusion exists, please list them.

Issue History

Date Modified Username Field Change
2004-01-06 10:37 obligog New Issue
2004-02-11 19:38 paul Note Added: 0000407
2004-02-11 19:38 paul Priority normal => low
2004-02-11 19:38 paul Description Updated
2004-02-11 20:04 paul Status new => confirmed
2004-12-08 22:52 vandongen Relationship added has duplicate 0000094
2006-11-06 18:21 taybin Note Added: 0002682
2006-11-06 18:21 taybin Status confirmed => feedback
2006-11-06 20:26 obligog Note Added: 0002688
2006-11-06 20:35 taybin Note Added: 0002689
2007-01-26 12:55 oofus Reporter obligog => oofus
2007-01-27 18:09 paul Note Added: 0003115
2007-01-27 18:56 oofus Note Added: 0003120
2007-02-06 11:09 timbyr Relationship added related to 0001380
2007-02-13 16:42 paul Status feedback => resolved
2007-02-13 16:42 paul Resolution open => fixed
2007-02-13 16:42 paul Assigned To => paul
2007-02-13 16:42 paul Note Added: 0003230
2007-02-15 00:33 oofus Status resolved => closed
2007-02-15 00:33 oofus Note Added: 0003287
2007-02-15 13:13 paul Note Added: 0003299