toggle buttons look untoggled when the mouse is over them

Bug #528964 reported by Sage Ross on 2010-02-27
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gtk2-engines-murrine (Ubuntu)
human-theme (Ubuntu)

Bug Description

Binary package hint: human-theme

A toggle button (such as the "QUESTION" button in the Lernid application when a chatroom is active) looks the same whether it is activated or not activated when the mouse is hovering over it. It takes the pressed look while it is being clicked, but then takes the unpressed look as soon as the click is released, until the mouse moves away. In the case I happened upon it, I didn't realize the button was a toggle at first because of this. A related problem is that if a user toggles and untoggles the button repeatedly, until the mouse is moved there is no way to tell it is in the toggled or untoggled state.

An active toggle button with the mouse over it should look different from an untoggled button. Likewise, an untoggled button that is being pressed to toggle it should look different from a toggled button that is being pressed to untoggle it.

Vish (vish) wrote :

Could you post a screenshot of the problem in Lernid?

Does it look different from the toggle button used in nautilus location bar or the search button?

Changed in human-theme (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Sage Ross (ragesoss) wrote :

I will post a screenshot next time I get the chance. The button is only there when a scheduled chatroom session is active, so I'll have to wait for that.

It does look basically the same as the Nautilus location bar, but the location bar doesn't behave like a single on/off toggle, since only clicking a different button (directory) will deactivate the active one. In Lernid, it is activated pressing it once and deactivated by pressing it again. So in Nautilus it's not a problem, since you have to move the mouse away anyway to activate a different directory (and since one of the directory buttons is always active). But for a simple on/off toggle, it becomes confusing.

Sage Ross (ragesoss) wrote :

I made a short screen recording of how the toggle button looks. I notice now that there is a very slight difference between the pressed and non-pressed button when the mouse is over it, but it is too subtle to be useful for this kind of button.

James Schriver (dashua) wrote :

Please test the attachment. Drop/drag to gnome-appearance-preferences and report back. This is from psyke's visual-refresh branch with the bg[PRELIGHT] adjusted.

Sage Ross (ragesoss) wrote :

I installed the Human Prelight attachment. It behaves a little oddly for me: installing it adds another theme also called simply "Human", which looks different in the Appearance Preferences widget but doesn't change anything that I can tell when selected (see attached screenshot). I selected customize and manually set the 'Controls' and 'Window border' to "Human Prelight". That made everything very different from the human theme, although the toggle button works well and it's easy to tell whether the toggle is active or not even when the mouse is over it (see attached screenshot in next post).

Vish (vish) wrote :

The problem here is that the same prelight is used for both the pressed and the un-pressed states , [this happens even for the nautilus search button and every other toggle button]
Either we make the Human buttons more raised [which changes the whole theme], to make the pressed state more obvious.

or there needs to be an option in the murrine-engine to specify a different prelight color for pressed buttons.

Changed in gtk2-engines-murrine (Ubuntu):
status: New → Confirmed
Vish (vish) wrote :

This bug is an upstream murrine one and it would be quite helpful if somebody experiencing it could send the bug the to the people writing the software. You can learn more about how to do this for various upstreams at Thanks in advance!

Changed in gtk2-engines-murrine (Ubuntu):
importance: Undecided → Wishlist
Vish (vish) wrote :

IMO , users can notice the words going lower[pressed] and raise[toggled], which seems enough for me though.

I would not add a custom prelight color for pressed state, neither I
think I should "mix" the color of the active state with the prelight
one (could have problems with some colored themes)

Vish (vish) wrote :

@Cimi: No need mix or custom prelight ..
Why not use 0.9 of defined prelight for the pressed button?[by default in murrine] ..
The problem now is that the same prelight is used for both , making pressed-togglebutton's prelight a bit darker could work , right?

Andrea Cimitan (cimi) wrote :

Darker for the themes that have a darker bg[ACTIVE], but what about
the themes that have a brighter bg[ACTIVE] ?

Vish (vish) wrote :

@ Cimi : I'm not sure why bg [ACTIVE] matters?
The same bg [PRELIGHT] is being used for the buttons irrespective of their state. (irrespective of the bg[ACTIVE] )

When the toggle[press] occurs there is a removal of the shadow around the button , light/shine increases/shows on the bottom edge and the text moves lower. Since the prelight color is usually bright, these changes seem more subtle when the user is still having the pointer over the button.

The only problem here is that the toggle-button color doesnt change. (while the mouse is over the button ) .
If we make the toggle-button color (in this case bg[PRELIGHT] )a bit darker for the pressed state [along with the above changes]that should negate the problem .Changing prelight color too will make the "press" much more obvious without having to move the pointer.

And when the button is not prelight , it would return to the bg[ACTIVE] color (as being done now).
But I'm not really sure why you mentioned bg[ACTIVE] as a problem.[Am I missing something here?]

Angel Abad (angelabad) on 2010-03-08
Changed in murrine:
importance: Undecided → Unknown
status: New → Unknown
Vish (vish) wrote :

Not a theme bug

Changed in human-theme (Ubuntu):
status: Incomplete → Invalid
Vish (vish) wrote :

Thanks for sending upstream.

Changed in gtk2-engines-murrine (Ubuntu):
status: Confirmed → Triaged
Changed in murrine:
importance: Unknown → Wishlist
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.