Re: [gtk-list] shift-Tab question



Steve Sarette wrote:
> 
> I'm developing a UI where I'm trying to control which widget gets the
> focus when Tab and shift-Tab are pressed.  I can capture the Tab key
> press event with no problems, but I'm having problems with the shift-Tab
> event.  It appears that the Tab key is unique in that a GDK_SHIFT_MASK
> cannot be applied to a Tab key-event.  Unlike other keys (such as Return
> or Escape), gtk/gdk appears to see a shift-tab as a unique key (as
> opposed to a key with a modifier).  That is, gdk_keyval_name()
> identifies a Tab as a Tab but a shift-Tab as an ISO_Left_Tab.  Thus the
> following code would never see the shift mask because the case would
> never be satisfied:

Your problem (if it really is one) is from the X-Server configuration
rather than anything to do with Gtk.  The X-Server has a table which
maps key presses to names and can map a given key to a different thing
when modifiers are pressed.  If you run:

	xmodmap -pke | grep -i tab

you will likely get output like this:

	keycode  23 = Tab ISO_Left_Tab

This means that the TAB key is keycode 23.  When you press is normally,
X considers it to be a "Tab".  If you press it with Shift though, it
get a new meaning of "ISO_Left_Tab".

I have no idea why it does this and it seems quite strange and counter-
intuitive but the reality is that thats the way it is and will be on
most
peoples systems so you've got to code around it!

If you wanted to you could use the command "xmodmap -pke >/tmp/x.map"
and
then edit x.map to change keycode 23 to just "Tab".  But then the user
will have to make sure they use a "xmodmap x.map" command before they
use your software.

I've had to do this in the past since I've seen X server that come with
Shift-F1 being the same as F11 so that you can't tell the difference
between the two key presses in software (and I really needed to give the
user the ability to uniquely use all keys).  But it can be a hassle!

I too would like to get better focus control in Gtk.  What I want is to
be able to catch before the focus leaves a widget and if it is a input
field, do some validation first.  If the validation fails, I want to
turn the field a different color to highlight it, beep, and leave the
focus on that widget.  If validation is fine then focus changes as is
usual (though I way want to programatically decide what the next focus
widget will be).  This focus handling has to effect both focus changes
from Tab and Shift-Tab but also mouse presses.  And it should know the
difference between focus leaving a widget because the user clicked in a
different application vrs focus changing within an application.

If anyone can help with any of the above, I would most appreciate it!

-- 
Brad Pepers
Linux Canada Inc.            Home of Linux products in Canada!
http://www.linuxcanada.com   Proud supporter of Cyclades, Red
brad@linuxcanada.com         Hat, and Caldera.



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