GNOME Bugzilla – Bug 610515
No way to programmatically update visual state of a button
Last modified: 2018-04-15 00:09:38 UTC
GtkButtons only react to the left button by default. That is, the button_press/release handlers check that this was the mouse button used, and will only call gtk_button_pressed/released in that case, which eventually will also trigger 'clicked'. Epiphany has a policy in its toolbar buttons that, for any action, if the action could conceivably be done either in the current window or in a new tab (eg, go back), left click will do it in the current window and middle click will do it in a new tab. For this it needs buttons to react to a middle click, so it connects to button-{press,release}-event on them and calls the deprecated functions if event->button == 2, since it knows GtkButton won't do it. Since those functions are deprecated now, it seems there's no sane way of doing this anymore. Am I wrong? Should GtkButton we modified to accept middle clicks by default or through an option?
I would say those deprecations were simply in error then, and should be undone.
Alternatively, use g_signal_emit_by_name
(In reply to comment #2) > Alternatively, use g_signal_emit_by_name The signals are also deprecated.
What GtkButton::pressed does is, connect to GtkWidget::button-press-event and check the event type and button. released is implemented analogously with button-release-event. Why don't you use the widget signals now?
(In reply to comment #4) > What GtkButton::pressed does is, connect to GtkWidget::button-press-event and > check the event type and button. released is implemented analogously with > button-release-event. > > Why don't you use the widget signals now? Use them how? What I basically need is the default handlers for GtkButton::pressed and GtkButton::released to run, since they are the ones that update the internal state of the widget correctly. I can't neither call the functions nor emit the signals, since they are theoretically deprecated. I am *already* connecting to button-press-event and button-release-event, since as I said in my first comment it's there where I call the deprecated functions. If I emit the signals again I would enter an infinite loop. Might be missing what you are suggesting, but I don't see how this can be solved using the public non-deprecated APIs.
Ah, so the actual problem is that there is no API to make buttons look pressed down. And until now you used the signals as a hack to achieve that. One possibility would be to revive the functions and document them to update the visual state of a button programmatically.
(In reply to comment #6) > Ah, so the actual problem is that there is no API to make buttons look pressed > down. And until now you used the signals as a hack to achieve that. > > One possibility would be to revive the functions and document them to update > the visual state of a button programmatically. Well, the default handlers also update various internal state flags and emit the 'clicked' signal (which I need), so it's not only about appearance. The problem is that there's no way to programatically press a button (both the action and the looks of it) and the button by itself won't react to anything other than left click.
Seems that nautilus is affected by this too. Take a look to bug #600475 This is patch attached there: https://bugzilla.gnome.org/attachment.cgi?id=148472&action=edit
Created attachment 158603 [details] [review] Implement gtk_button_depress This implements gtk_button_depress, which basically sets the internal state of the button so that it is drawn and treated as depressed. I also changed the release handler so that any mouse button can release the button, but only the first button triggers the 'clicked' and 'released' signals. The main difference with the old API is that it doesn't depend on the signals, so we can remove them in the future. I left a test snippet in there, in testgtk, which shows how it works.
Created attachment 158604 [details] [review] Implement gtk_button_depress + _release For completeness, the addition of gtk_button_release, if we want to allow releasing programatically. Albeit I'm not sure how useful that is in practise. It is not needed for the cases where Ephy or Nautilus just need other mouse buttons.
I don't get this. The original request was to simply be able to change event->button = 2 to event->button = 1 in the button_press_event handler, right? So where is the problem in simply subblassing GtkButton, implementing GtkWidget::button_press_event() and ::button_release_event(), create a new GdkEventButton with event->button = 1 and chaining up?
(In reply to comment #11) > I don't get this. The original request was to simply be able to change > event->button = 2 to event->button = 1 in the button_press_event handler, > right? > > So where is the problem in simply subblassing GtkButton, implementing > GtkWidget::button_press_event() and ::button_release_event(), create > a new GdkEventButton with event->button = 1 and chaining up? Other than being a horribly laborious task for such a simple need, nothing I guess. If being able to press buttons with other than button=1 is deemed reasonable I'd rather see the API undeprecated or GtkButton fixed to cope with it.
Any new opinion on this? GTK+ is going to freeze API soon, so perhaps we want to decide something :P. (raising importance since Nautilus and Epiphany need this)
How about setting GTK_STATE_FLAG_ACTIVE on button_press_event() if event->button==2?
A quick test throws: - the button is drawn as clicked/released, but it is not "clicked" (no signal is emitted, so the button does nothing) - set_state_flag + unset_state_flag produce some funky results The second point is trivial of course.
Well, in a subclass you can perfectly make it emit a signal :), this bug is about programmatically updating the visual state of the button, and that's doable AFAICS
(In reply to comment #16) > Well, in a subclass you can perfectly make it emit a signal :), this bug is > about programmatically updating the visual state of the button, and that's > doable AFAICS I'm not sure why the title was updated to say that, but my comments make it quite clear that the deprecated functions update both the appearance and the internal state of the widget, including making it actually emit "clicked". If the solution is to subclass buttons I guess we can go with that, but honestly I'm not sure of why GtkButton shouldn't be just updated to react to middle and right clicks?
What's the current situation for this bug? Bypass it, or fix it with a patch, because this needs to be in before GNOME 3, I suppose.
[Removing GNOME3.0 target as decided in release-team meeting on March 03, 2011. This report has an "important" categorisation for GNOME3.0 but is not considered a hard blocker. For querying use the corresponding whiteboard entry added.]
Did this make it into GTK+3? Is this bug still relevant?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new