Re: enhacing GTK visual quality



Antonio Campos <acampos@ceronet.com> writes:

> 2) The long and interminable story of the buttons don't getting
> depressed (visually) when the users click on them using the keyboard
> 
> 
> I have worked hardly to try to avoid that ugly imperfection of GTK, but
> without results, or without a clear way of doing it without breaking
> signals semantics...
> Anyway, here are my investigations (please, fell free to e-mail me
> personally if you have something to help here):
> 
> Handling the button_press, button_release and clicked signals (for the
> mouse) are done in gtkbutton.c. button_press then calls
> real_button_press or so, and the like for button_release with
> real_button_release. On those real_... functions are the calls for
> painting the button (pressed/depressed).
> However, keyboard handling is completely done in another ways.
> The first function (when the user press a button using the keyboard)
> that is called is the handler for the keypress signal on the gtkwindow.c
> module. Then this module produces an ACTIVE signal that the button
> widget class connects directly to the clicked signal (in gtkbutton.c all
> of this), so finally the clicked signal is produced. The problem is that
> the redrawing part is never called because the button_press and
> button_release functions are never called with the keyboard. 
> This is more or less what's happening in gtkwindow.c and gtkbutton.c
> I'm asking for help here, because I think it shouldn't be a hard thing
> to tweak by a Gtkhacker. 

This is not the way to do it. 

Instead, there should be two parameters, x_child_offset and
y_child_offset, that a theme could set. These should specify how much
the child widget moves when the button is pressed. The default should
be (0, 0). They should go into the Style class, and GtkButton should
be changed to support it.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]