[gtkada] Q re keypresses in a notebook.

[Bobby D. Bryant]

[Sorry for the long delay in my response. These questions regard a hobby project
that I work on as time allows, but unfortunately I have not had time to look at
it since I got your response quoted below. But I thought I should go ahead and
reply now before your message gets lost in the depths of my inbox.]

briot at gnat.com wrote:

> Bobby D. Bryant writes:
>  > Part of a UI that I am working on is a notebook where the first page is
>  > a set of control widgets and the remaining pages are nothing but
>  > pixmaps.  When a pixmap is on top I want to be able to manipulate it
>  > with keypresses.
>  >
>  > If I simply set up a keypress callback for each page, nothing happens
>  > when I press a key (unless it is an arrow key, CR, or TAB, in which case
>  > there is navigation among the page tabs.) [As an aside, I should say
>  > that the widgets in the control page work normally -- the only thing I
>  > have trouble trapping is the keypresses.]
>
> This might be a case where you would need a binding to the GtkBinding widget
> (which is in fact the underling implementation for the accelerators (You have
> looked at gtk-accel_group, haven't you ?).

No, I have not looked at that; I'll check it out next time I have time to work
on it.


> Unfortunately, GtkAda does not include this binding yet, this is probably one
> of the two or three widgets/files from gtk+ we haven't worked on yet.
> You should look at the C file, and see if you think this could help you.
> I believe the binding is fairly easy to do.

I did have one evening to work on the project between the time I posted the
question and the time I got your reply. During that session I did get it
*mostly* working by setting the Can_Focus and Can_Grab flags for the
pixmap-derived widgets and having a higher level of the application issue the
grabs at appropriate times. I wasn't altogether happy with the solution because
of the non-local operations on the widgets, but perhaps my expectations were
unrealistic (after all, I'm not whining about having to read spin buttons far in
the code from where they are configured). I also saw that while most of the keys
were trapped, the diagonal keys on the keypad were not for some reason, and
pressing them caused the notebook itself to re-grab the focus away from the
derived widgets. (Please don't spend any time looking in to this -- I have not
even had time to figure exactly which keys are affected, let alone to
investigate the cause of the problem. If it is a real problem I'll report it
when I have more information.)

At any rate, it looks like some solution will be feasible.  I'll back up and
have a look at what you suggested before I pursue my tentative solution any
farther.

Thank you for taking the time to look at this.

Bobby Bryant
Austin, Texas