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

[Antonio Campos <acampos extremadura com>]

Damon Chaplin wrote:

> Tim Janik wrote:
>
> > hm, except for you using a timeout, the patch looks pretty sane.
> > what i don't like about using a timeout is that if e.g. a ::clicked
> > handler calls gtk_main() recursively, the button becomes depressed
> > after 100ms when activate via the keyboard, while it wouldn't do
> > that for mouse events.
> > i think we should be consistent there with cleaning up the ACTIVATED
> > state at the end of the signal emission (for 1.2.8, we'd have to do
> > that in an _after() handler which may impose problems for stopped
> > emission, but the patch has to be written against CVS HEAD anyways,
> > and there we'll have something like a cleanup class handler).
>
> I think you have to use a timeout really.
> If you restore the button's state to NORMAL/PRELIGHT after the "clicked"
> emission finishes, you may not even see the button pressed in - it
> may all happen too fast.
>
> (I did miss one thing in the patch - if the button has been set to
> insensitive it should leave it in that state.)
>
> Damon
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

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.

Hope this helps.
Hey, this "stupid" enhace visual quality of buttons, isn't as "stupid"
to
code... >:-(

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.
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.

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?

Thanks for your time...