Re: Button patch (Was: enhancing GTK visual quality)

[Damon Chaplin <damon helixcode com>]

Antonio Campos wrote:

> Hi Damon, I've testing the patch again Gtk+-1.26 sources and it behaves
> quite well, except for this (I don't know the cause, only the symptom):
> 
> Try the testgtk program built with the sources, in the section "toggle
> buttons".
> A window with three toggle buttons, "button1" through "button3", and a
> normal "close" button appears.
> 
> If you press the "close" button just after the window is shown, then the
> window closes as it should happen.
> But if press some of the toggle buttons (randomly), and then press the
> "close" button, then the close button remains clicked (stalled) without
> closing the window.
> 
> So, some changes in the GtkButtonClass are affecting the derivated
> GtkToggleButtonClass.

I can't reproduce that here (with 1.2.7).

Looking at the GtkToggleButton code, I can't see what could cause this
problem. GtkToggleButton has its own 'clicked' class function, so my
code to add the timeout isn't even executed. (Maybe your compilation
wasn't clean. Try a clean rebuild of GTK+ - I added a field to GtkButton
which may mess up any code using it.)

To be honest I hadn't looked at the impact on subclasses. I don't think
it should affect GtkToggleButton, GtkCheckButton & GtkRadioButton.
I'm not sure about GtkOptionMenu yet. And it may affect any external
subclasses of GtkButton.

It may be best to only perform my new code in gtk_real_button_clicked()
for the GtkButton class itself, i.e. skip it for subclasses. That should
avoid any problems with subclasses. If they need similar functionality,
they can add it themselves. I don't think any of the GTK+ subclasses
need it.


(Also, since Tim wants it to act just like a click with the mouse button,
the code to add the timeout function should probably be moved to the
new "signal cleanup" function he mentioned. If we do that, then the
button will always remain ACTIVE until after the signal emission is finished,
just like normal button presses.)


> Another thoughts, correct me if the following is not the correct
> approach:
> 
> When you click with the mouse on the button, three signals occur, and in
> this order: pressed, released and clicked.
> Pressed is sent when the click is started in the button. Released is
> sent when the mouse click is released (quite obvious). After the
> released signal, the clicked signal is emmited.

The "clicked" signal is emitted in the middle of the "button_released"
class function. The "button_released" signal is specified as 'RUN_FIRST',
which means the class function is run before all signal handlers. So any
"clicked" signal handlers will be run before "button_released" handlers.


> Shouldn't happen something similar with the keyboard? I mean, if I press
> a button a pressed signal should be emmited, and while I keep pressing
> it (without releasing the key pressed) the button is down. After I
> release the key then a released signal is sent, and after that a clicked
> one. Isn't it more natural and homogeneous?
> 
> For doing this I think that the button_press_event, and the
> key_press_event should connect with the same callback that will in turn
> decide which event was sent (a mouse button one or a keyboard one) for
> handling correctly the enter_notify_event and leave_notify_event in the
> case of the mouse. The same for the button_release_event, and the
> key_release_event.
> 
> The only problem arrising from this is that not all keyboards (hardware)
> may produce key_release_event events. But I can't imagine nowadays a
> keyboard don't doing this.

I'm not sure how many keyboards don't produce key_release events. But I
think people still try to avoid depending on them.

Anyway, the current GTK+ code for accelerator keys and keyboard 'activation'
of widgets only uses key_press events.



> Oh, by the way: what's the use of the activate signal for the button
> class?. It's sent in the callback of gtkwindow.c that handles keyboard
> input on a window. What's its purpose?

It is so you can use buttons via the keyboard - you move the keyboard focus
to a button and press the space key, and it sends the "activate_signal"
which GtkButton has mapped to the "clicked" signal. i.e. it acts just like
you clicked on it with the mouse.

The "activate_signal" also allows you to press 'Enter' to "activate" the
default button in a dialog box.

Damon