On Tue, May 09, 2000 at 03:15:05PM -0300, Leonardo Zide wrote:
> Also, the program that I'm writing is a conversion of a Win32 program
> and sometimes I need to know if the Alt key is pressed. What's the best
> way to do that ?
Is this a general question, or are you trying to implement Alt+<letter>
mnemonics such as appear in dialog boxes? (I'm asking because I'm not
sure whether the "is a conversion of a Win32 program" is meant to imply
that Alt is being used in a fashion in which it's not always used in
UNIX/X programs - the toolkits that I have the impression are the Big
Three for UNIX/X, namely Motif/Lesstif, GTK+, and Qt, all include
varying amounts of support for Alt+<letter> mnemonics for widgets, but a
lot of UNIX applications don't use them, which I find unfortunate, as I
like to be able to drive dialog boxes through the keyboard.)
If it's the former, then:
if you want to detect Alt being pressed, I think that'd be a
"key pressed" event, and I think the keys you'd check for would
be GDK_Alt_L and GDK_Alt_R;
if you want to check whether Alt was down when another event
arrived, I think you check the "state" field in the
GdkEvent-type structure passed to the signal handler for the
event - if it has GDK_MOD1_MASK set, the Alt key was down at the
time;
I'm not sure what you'd do in other situations.
If it's the latter, the way I've done that in Ethereal for buttons is
to, in the routine that creates the dialog box:
allocate a GtkAccelGroup, and add it to the window with
"gtk_window_add_accel_group()";
copy routines such as "gtk_radio_button_new_with_label()" and
modify them to:
take an additional argument, which is a pointer to the
GtkAccelGroup;
pass the label widget and the label string for the label
to "gtk_label_parse_uline()", and, if the return value
isn't GDK_VoidSymbol, add to the GtkAccelGroup accelerators for
the key returned by "gtk_label_parse_uline()" and for
that key with GDK_MOD1_MASK (that's the mask for the Alt
key), and have that accelerator deliver a "clicked"
signal to the button.
Making it easier to do this might be something worth considering for
GTK+ 1.4, especially with the changes Havoc's been making to beef up the
GtkDialog widget.
Windows mnemonics also transfer the keyboard focus to the widget whose
label specifies the mnemonic.
Qt appears to have a couple of mechanisms for this:
a label widget can be given a "buddy" widget, and if the
accelerator specified by the label (Qt uses Windows-style
syntax, with '&', for this) is pressed, keyboard focus is
transferred to the buddy widget;
a button widget can itself have an accelerator, and if the
button's label text specifies an accelerator, that becomes the
button widget's accelerator, although it appears that the
accelerator just clicks the button - it may not give it the
input focus, and my experiments with the KDE Control Center
appear to bear this out. (I don't know whether the input focus
not being transferred is a bug or a feature, but, then again, I
don't know whether the fact that Qt appears not to follow the
ICCCM's specification that
The selection named by the atom CLIPBOARD is used to
hold data that is being transferred between clients,
that is, data that usually is being cut or copied, and
then pasted.
and instead appears to use the PRIMARY selection is a bug or a
feature; I suspect the people I've seen complain about
cut-and-paste not working between KDE applications and Netscape
would consider it a feature - C&P sure works fine between the
GTK+ applications I've tried it with and Netscape, as GTK+
*does* follow the ICCCM here.)
The latter of those is what the stuff I describe above provides; I've
not looked into making accelerators/mnemonics transfer the keyboard
focus. (I don't know whether GTK+ should emulate Windows or Qt here.)
--
To unsubscribe: mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
