Re: [gtk-list] Re: Random questions...



Owen Taylor wrote:

> Matthew Berg <wdomburg@pce.net> writes:
>
> > Question about GdkEventKeys -
> >
> > When setting up a callback for for a key_press_event, how do I check for key
> > combinations, e.g. CTRL-W?
>
> if (event->state & GDK_CONTROL_MASK)
>

Okay, so the callback would be something like

   void callback (GtkWidget *text, GdkEventKey *ev) {
      g_return_val_if_fail (text != NULL, FALSE);
      g_return_val_if_fail (ev != NULL, FALSE);

      if (ev->state & GDK_CONTROL_MASK) {
         switch (ev->keyval) {
            case  'A': case 'a':
                somefunction;
                break;
            case 'B': case 'b':
                someotherfunction;
                break;
            }
       else {
          switch (ev->keyval) {
               case GDK_Return:
                   yetanotherfunction;
                   break;
          }
       }

    return TRUE;
    }

Or something along those lines (actually, I'm probably going to keep the the keyvals
and associated function
function pointers in an array and step through that, but this is only example code
:)

I would assume checking for ALT would be much the same, using GDK_ALT_MASK maybe?

> > >From what little I've done with capturing gdk events, it seems that key events
> > are captured propogated from parent to child.  If I set up a handler on the
> > window, is there any way to prevent it being captured by child callbacks as
> > well?
>
> Actually, they are propagated from child to parent. So there is
> effectively no way to prevent them being seen by the child.
> (Except by calling gtk_signal_handler_block() for each child
> individually)

Ooops, remind me not to post to mailing lists when I haven't had enough sleep :)

Actually, thinks work out better for me that way (that question was just for a very
simple app I was working on to replace the root menu in AfterstepClassic with a GTK
based menu that reading in the app.desktop entries in /usr/share/apps.  The
behaviour I was going for was for the menu to disappear when the mousebutton was
released, but it would also be required to activate the button the point was
positioned over first, so I need the child (button) to catch the button_release
event and then the parent to catch the event and call gtk_exit.

So, if I am now understanding correctly, I should be able to implement this behavior
with no signal_handler blocks at all.  :)

> > (I seem to remember that setting the return on the handler to TRUE was
> > supposed to indicate that it was already taken care of, but that didn't seem
> > to work, or maybe I'm misinterpreting what I read?)
>
> What returning TRUE means is that the event shouldn't be propagated
> to the widget's parent. But other handlers for the current widget
> will still be run. You want to call gtk_signal_emit_stop_by_name()
> in addition to returning TRUE.

Thanks for straightening that out for me.   Most of GTK+ is very straight foward,
but there are a few spots that I still get caught on.

Matthew Berg



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