Re: [fltk.general] Caps Lock detection
If I understand correctly, the capslock state info is correct during regular keypresses, just not when the capslock key is hit. Yes - in all the tests I tried, the Caps Lock state was always correct during (and after) regular key presses. However, any attempt to discern the Caps Lock state immediately after the Caps Lock key was pressed / released a few times, with no other key pressed since, was unreliable. (For X11 on Linux, in a VBox VM... real systems may be more consistent!) As a rider, I suggested in an earlier post that the OSX hosted VM was not even delivering the Caps Lock key down/up events to the hosted OS until the next regular key was pressed. However, subsequent testing using xev shows this is not strictly true; however, the keyboard state in the VM is so messed up by the flurry of events that are delivered (for a single Caps Lock key transition, I see half a dozen events, where a normal key sends 1...) that any attempt to discern the Caps Lock state (e.g. via XQueryKeymap or otherwise) returns unreliable status... Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/11/13 02:18, MacArthur, Ian (Selex ES, UK) wrote:
If I understand correctly, the capslock state info is correct during
regular keypresses, just not when the capslock key is hit.
Yes - in all the tests I tried, the Caps Lock state was always correct
during (and after) regular key presses.
Yes.
However, any attempt to discern the Caps Lock state immediately after
the Caps Lock key was pressed / released a few times, with no other
key pressed since, was unreliable.
Right, though this seems to be specific to your VM.
Originally I thought the behavior was random, but looking closer,
it's actually predictable and reliable (just not what I'd expect).
Digging deeper, I found that the behavior across all versions of X
I currently have access to (Irix/redhat9/centos5.6) is /consistent/
and /predictable/ across all of them for this, with both X11 and FLTK
code.
I rewrote the two programs (see below) to show clearer output,
including some fflush()s so that they would pipe correctly through
grep(1).
When capslock is toggled, the state info in the xevent and
Fl::event_state()
for the CapsLock key Press/Release and FL_PUSH/FL_RELEASE events is:
KeyPress: what the state was BEFORE the key was pressed
KeyRelease event: state is *always* 1.
So the reliable info is on KeyPress, it tells you what the state of
capslock
WAS, and not what it will become.
Ditto for FLTK.
So if I pipe both programs thru grep Press, I see the capslock state
flag toggle
reliably, the state being what the key WAS before the key was hit, no
matter how
fast I toggle the key (And if I grep Release, the flag is always on)
Here's the output of the below X11 and FLTK programs piped through
grep Press while I toggle capslock:
$ ./test-capslock-x11 | grep Press
X11 Press: off
X11 Press: on
X11 Press: off
X11 Press: on
X11 Press: off
X11 Press: on
..
$ ./test-capslock-fltk | grep Press
FLTK Press: off
FLTK Press: on
FLTK Press: off
FLTK Press: on
FLTK Press: off
FLTK Press: on
Consistent and reliable behavior.
I guess we should see how Win32 and OSX behave, and if they're
reliable
as well, we should either:
1) Document the OS specific behavior, whether different or same,
and leave the code alone
2) Pick one behavior, and modify the code to enforce it, and
document it
In a perfect world I'd say (2), though if we start fiddling around with
the
FLTK event structure's state info, we might be asking for trouble, not
sure..
at very least we could do (1) for the short term.
Anyway, here's the two test apps, X11 and FLTK, which basically do the
exact same thing, but with clearer messages that are grep(1) friendly:
--- snip: start
//
// X11 CAPSLOCK TEST
// Slightly modified X windows hello world
// ref: http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_c.html
// compile: g++ test-capslock-x11.c -o test-capslock-x11 -lXtst -lX11 -lXext
#include stdio.h
#include stdlib.h
#include string.h
#include X11/Xlib.h
#include X11/Xutil.h
int main(int argc, char *argv[]) {
Display*dpy;/* X server connection */
Window win;/* Window ID */
XEvent event; /* Event received */
// OPEN DISPLAY
if ((dpy = XOpenDisplay(NULL)) == NULL) {
fprintf(stderr, %s: can't open %s\n, argv[0], XDisplayName(NULL));
exit(1);
}
// CREATE WINDOW, SELECT EVENTS WE WANT, MAP WINDOW
win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), // create
500x500 window
50,50,500,500,// x,y,w,h
0,// border width
0,0); // border
color, bg color
XSelectInput(dpy, win, KeyPressMask|KeyReleaseMask);// select input
events we want
XMapWindow(dpy, win); // map window
// EVENT LOOP
while (1) {
XNextEvent(dpy, event);// get the event
switch ( event.type ) { // event
received?
case KeyPress:
case KeyRelease: {
const char *emsg = (event.type==KeyPress) ? Press :
Release;
const char *lmsg = (event.xkey.state2) ? on : off;
printf(X11 %s: %s\n, emsg, lmsg); fflush(stdout);
break;
}
default:
fprintf(stderr, * Ignored event '%d'\n, (int)event.type);
break;
}
}
return(0);
}
--- snip:end
Re: [fltk.general] Caps Lock detection
On 11 Apr 2013, at 18:34, Greg Ercolano wrote:
I guess we should see how Win32 and OSX behave, and if they're
reliable
as well, we should either:
1) Document the OS specific behavior, whether different or same,
and leave the code alone
2) Pick one behavior, and modify the code to enforce it, and
document it
Can. Of. Worms.
Attached below, my take on this. It's messy...
However, the code given returns the correct state on OSX 10.6.8,
Linux-in-a-VM, and WinXP.
What I find (at least on my systems...)
- On Linux, ONLY look at the FL_KEYDOWN events
- On WIN32, ONLY look at the FL_KEYUP events (and the sense is maybe inverted
wrt the linux case)
- On OSX, I need to process both up and down events, because it looks (and I
may be really losing the plot here) as if I only get keydown events when the
Caps Lock is going on, and I only get keyrelease events if the Caps Lock is
going off...
So... The code works, but it is not nice:
--
//
// FLTK CAPSLOCK TEST
// compile: fltk-config --compile test-capslock-fltk.cxx
//
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
static Fl_Box *state_box = 0;
static unsigned updn = 0;
static unsigned updn_old = 0;
static void change_state_box(void) {
if(updn != updn_old) {
updn_old = updn;
if(updn) {
state_box-color(FL_RED);
state_box-label(ON);
}
else {
state_box-color(FL_BLACK);
state_box-label(OFF);
}
state_box-redraw();
}
} // change_state_box
class MyWindow : public Fl_Window {
public:
MyWindow(int W,int H) : Fl_Window(W,H) { }
int handle(int e) {
switch (e) {
case FL_KEYUP:
#ifdef __APPLE__
if ((Fl::event_state() FL_CAPS_LOCK) != 0) {
updn = 999;
}
else {
updn = 0;
}
change_state_box();
#endif // __APPLE__
#ifdef WIN32
if ((Fl::event_state() FL_CAPS_LOCK) != 0) {
updn = 0;
}
else {
updn = 999;
}
change_state_box();
#endif // WIN32
break;
case FL_KEYDOWN:
#ifndef WIN32
if ((Fl::event_state() FL_CAPS_LOCK) != 0) {
updn = 999;
}
else {
updn = 0;
}
change_state_box();
#endif // !WIN32
break;
default:
break;
}
return(Fl_Window::handle(e));
} // handle
};
static MyWindow *win = 0;
int main(int argc, char **argv) {
win = new MyWindow(500,500);
win-begin();
state_box = new Fl_Box(10, 10, 80, 40, OFF);
state_box-color(FL_BLACK);
state_box-box(FL_FLAT_BOX);
state_box-labelcolor(FL_WHITE);
win-end();
win-show(argc, argv);
return Fl::run();
} // main
// end of file
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
Try the xkbvled(1) application. Do you find it too doesn't properly represent the shift lock LED? It also fails. I've tried this now with F17 and Ubuntu-12.10, hosted on Win7 and OSX 10.6.8, though in VirtualBox VM's in each case. I don't have ready access to another brand of VM to try at present. If anything, the Win7 hosted version might have been slightly better, but none worked right. Well, in passing, I poked at the VM's a bit more, though nothing useful arises... In summary, it looks as if the Caps Lock key is subject to special handling, probably both in X11 itself *and* by the VM. For comparison, the Num Lock key appears to map straight through to xkbvleds (and my own test code) entirely unmolested and can be read reliably within the VM. But the Caps Lock shows some unusual features. - With the VBox VM hosted on Win7: I can read the keyboard in real time with XQueryKeymap and see the Caps Lock key being pressed and released. I take this to mean that the VM is passing the key stokes through pretty much unmolested on Win7. However, the state reported for Caps Lock (either by X11 or by fltk) does not reliably reflect the true state until after the *next* key is pressed (sometimes it is OK, but not often enough to be considered reliable!) This, I *assume* is special handling within X11 in some way. Num Lock is always fine, AFAICT. - With the VBox VM hosted on OSX: When I read the keyboard in real time with XQueryKeymap I *never* see the Caps Lock key being pressed and released. It just never seems to get flagged, ever. I take this to mean that the VM is NOT passing the Caps Lock key stokes through at all. I think the Caps Lock state is somehow only coming through to the VM on the next key stroke. As a result, the state reported for Caps Lock (either by X11 or by fltk) does not reliably reflect the true state until the *next* key is pressed. So in this case, it would appear there is special handling of the Caps Lock key by *both* the VM and by X11. Num Lock is always fine, AFAICT. The end. Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano e...@seriss.com wrote: It's also rare apps try to do anything with the capslock state. I don't agree. Most login screens warn immediately if capslock is on because their password fields don't echo input. Howard Rubin ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On Wed, 10 Apr 2013 10:05:04 -0700, Greg Ercolano e...@seriss.com wrote: On 04/10/13 09:25, Howard Rubin wrote: On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano e...@seriss.com wrote: It's also rare apps try to do anything with the capslock state. I don't agree. Most login screens warn immediately if capslock is on because their password fields don't echo input. Right, though login screens have quite a few oddities about them that are unlike regular GUIs.. inability to be 'stowed', fullscreen with no docks/taskbars, running without a window manager (to prevent window manager hotkey backdoors). I imagine there's a bit of Xlib coding needed on top of fltk to pull off a secure login screen, flwm being one example. If you wrote the code in pure Xlib, you'd still encounter this problem, the workaround apparently being to access the LEDs directly I think. Anyway, not sure if hacking X11's event structure in the case of capslock is a good idea or not -- seems like an X11 bug to me, and not sure if it's appropriate for FLTK to try to cover that up with a hack. Would like to hear what other devs say. Out of curiosity I did a bit of googling and found this. http://www.jveweb.net/en/archives/2010/11/making-better-use-of-the-caps-lock-key-in-linux.html It would seem that trying to trap cap locks could be fruitless because of key re mapping. Cheers Richard ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 10.04.2013 19:05, Greg Ercolano wrote: If you wrote the code in pure Xlib, you'd still encounter this problem, the workaround apparently being to access the LEDs directly I think. Anyway, not sure if hacking X11's event structure in the case of capslock is a good idea or not -- seems like an X11 bug to me, and not sure if it's appropriate for FLTK to try to cover that up with a hack. Would like to hear what other devs say. There's a (big?) warning that using another Xlib call to get the key state has at least two drawbacks: (1) Speed. It's slow because it needs another client/server roundtrip. (2) AFAIK all you can get is the CURRENT keyboard state. This can differ from the state as seen (or should be seen) when processing events, since this is an asynchronous call. I.e. event handling can be three key presses and two releases behind, and calling for the current state would give you no better values. Note that speed may not be so problematic, if you're working with X on a local machine, but X is designed to be a remote protocol over tcp/ip. This is all off the top of my head, and ISTR that I read such a warning in the FLTK code somewhere, but I don't have personal experience with native X11/Xlib calls. The same problem arises with Windows, BTW, although tests showed in this case that it seemed to work. So, if there is not an OBVIOUS bug in the FLTK code WRT direct event handling, I'd recommend leaving it as-is. We should not try to fix one bug and get another unpredictable behavior. The intended behavior (warning about CapsLock in password entry fields) can be achieved even when the warning is issued when a real key press arrives, so it's usually not too late - and this works reliably, as my tests and Ian's tests seem to show. -- Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 10 Apr 2013, at 17:25, Howard Rubin wrote: I don't agree. Most login screens warn immediately if capslock is on because their password fields don't echo input. Though it does appear that, at least if there is any prospect that your users will be running Linux in a VBox VM, that we may have to embrace the possibility that the very best we can do is detect the Caps Lock state when the user starts typing - reliably detecting Caps Lock otherwise seems... fraught... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
X11's own KeyRelease events seem to behave similarly; in my tests with the pure X11 code below, when X11 sends a KeyRelease event for the capslock key, the event.xkey.state shows accurate info when capslock is ENABLED, but INACCURATE INFO when capslock is disabled. You have to hit some other key to get the accurate state of capslock after lock release. Yes - though with Howard's example I find (on a F17 VM, not a real computer) that (as Howard said) quite often (not always!) just wiggling the mouse about in the window gets the state to update correctly... (Or, hitting the space bar always seems to!) So, something in the state is getting updated by other events, and perhaps not just the X11 KeyRelease ones? Or I'm missing the point again... Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
I tried the following FLTK code with the above X11 only code and it seemed to work more reliably. Not so much for me - though that may be an issue with the VM rather than a real problem. I find that, with this code, if I toggle Caps Lock on/off a few times, I can easily get to a state where the test code is resolutely reporting Caps Lock OFF, but the keybd LED is ON. Hitting any key (focus to any window) then seems to fix it up... Also, I tweaked the Tiiner_CB to show what fltk's event_state shows for FL_CAPS_LOCK, and it is not always (at least for me) the same as the X11 XkbGetIndicatorState seems to be showing... Which seems... odd... Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote:
unsigned n;
XkbGetIndicatorState(d, XkbUseCoreKbd, n);
caps_state = (n 0x01) == 1;
That works perfectly, and even better, needs no timer. Test program below.
Will this be fixed in a future release of FLTK?
- Howard Rubin
==
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Output.H
#include FL/Fl_Secret_Input.H
#include iostream
#include X11/XKBlib.h
bool isCapsLock() {
Display* d = XOpenDisplay(NULL);
if (!d)
return false;
unsigned n;
XkbGetIndicatorState(d, XkbUseCoreKbd, n);
return (n 0x01) == 1;
}
class myWindow : public Fl_Window {
public:
myWindow(int x, int y, const char* l) : Fl_Window(x, y, l),
pOutput(NULL) {
}
Fl_Output* pOutput;
virtual int handle(int event) {
static bool haveDoneOnce = false;
if (!haveDoneOnce || (event== FL_SHORTCUT Fl::event_key() ==
FL_Caps_Lock)) {
haveDoneOnce = true;
if (isCapsLock()) {
pOutput-show();
} else {
pOutput-hide();
}
}
return Fl_Window::handle(event);
}
};
int main(int argc, char* argv[]) {
myWindow* win = new myWindow(300, 200, );
new Fl_Secret_Input(20, 20, 100, 15, );
win-pOutput = new Fl_Output(120, 50, 0, 15, Caps Lock);
win-end();
win-show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/09/13 12:18, Howard Rubin wrote: On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote: unsigned n; XkbGetIndicatorState(d, XkbUseCoreKbd, n); caps_state = (n 0x01) == 1; That works perfectly, and even better, needs no timer. Test program below. Will this be fixed in a future release of FLTK? Again, I think FLTK is doing the right thing to pass the state information X11 is providing; seems it's an X11 issue (see the other X11 code I provided that shows the problem is with X11's events for KeyRelease) We could try to hack our events to use the above to test the state whenever the capslock key is set, and force-set the event state info.. but that's kinda hacky. I'd offer it should be investigated first to see if it's an X11 problem. I'd offer that we could perhaps provide a wrapper to get the state of the keyboard LEDs (for operating systems that provide this) e.g. fl_get_indicators() or some such that returns flags. Arguably if we provided that, we should provide fl_set_indicators() as well. And I suppose the return value could indicate if the OS provides this feature or not (assuming there are OS's that don't provide it) Also: not sure if the XkbGetIndicatorState() function is available on all Unix OS's we support; might need a configure option to detect this. Seems easy enough to implement under X11 at least. Anyone familiar with Win32 + OSX keyboard LED access? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/09/13 12:29, Greg Ercolano wrote: we could perhaps provide a wrapper to get the state of the keyboard LEDs (for operating systems that provide this) e.g. fl_get_indicators() or some such that returns flags. Maybe fl_get_keyboard_leds() and fl_set_keyboard_leds() would be better. There might be some resistance to adding this though, since FLTK is primarily a GUI toolkit trying to stay light on its API, its intention to abstract GUI related features, and not abstract all features of the window manager. Guess I'd be curious what other devs have to say. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 9 Apr 2013, at 20:18, Howard Rubin wrote: On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote: unsigned n; XkbGetIndicatorState(d, XkbUseCoreKbd, n); caps_state = (n 0x01) == 1; That works perfectly, and even better, needs no timer. Test program below. Hmm - might need to be careful though: didn't really work reliably for me, at least not in a F17 VM. I'm entirely prepared to believe that the VM is exacerbating the problem, of course, but it does suggest that this might not be a 100% reliable fix, or that at least some users will get caught out... Maybe... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 9 Apr 2013, at 22:02, Greg Ercolano wrote: On 04/09/13 12:29, Greg Ercolano wrote: we could perhaps provide a wrapper to get the state of the keyboard LEDs (for operating systems that provide this) e.g. fl_get_indicators() or some such that returns flags. Maybe fl_get_keyboard_leds() and fl_set_keyboard_leds() would be better. There might be some resistance to adding this though, since FLTK is primarily a GUI toolkit trying to stay light on its API, its intention to abstract GUI related features, and not abstract all features of the window manager. Guess I'd be curious what other devs have to say. I'm not opposed per se, though I do woory about clutter... However, as I said to Howard earlier; for me, on F17 (and now also Ubuntu 12.10) I find that it doesn't actually work, with the linux image in a VirtualBox VM. I *assume* this is some VM weirdness, but am not sure... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
I tried the following FLTK code with the above X11 only code and it seemed to work more reliably. Ian writes: Not so much for me - though that may be an issue with the VM rather than a real problem. I find that, with this code, if I toggle Caps Lock on/off a few times, I can easily get to a state where the test code is resolutely reporting Caps Lock OFF, but the keybd LED is ON. Try the xkbvled(1) application. Do you find it too doesn't properly represent the shift lock LED? If so, I'd suggest a problem with the VM or X or both; perhaps report to the VM guys, as it sounds like an emulation issue. Or, it might be the VM is exposing a problem with the one of the two OS's interface to reading the keyboard LEDs.. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Caps Lock detection
On Fri, 05 Apr 2013 23:39:28 -0700, Greg Ercolano wrote:
an fltk timer would probably be needed to get the correct
state info shown reliably.
Thanks for the replies.
No luck with an fltk timer, on Ubuntu Linux 10.04. Test program below.
In the console we can see that (Fl::event_state() FL_CAPS_LOCK)
correctly changes to nonzero as soon as you press Caps Lock.
But it doesn't change back to 0 when you press Caps Lock again
until e.g. you move the mouse over the window.
Howard Rubin
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Output.H
#include iostream
void TimerProc(void* p) {
Fl_Output* pOutput = static_castFl_Output*(p);
if (Fl::event_state() FL_CAPS_LOCK) {
pOutput-show();
std::cerr 1;
} else {
pOutput-hide();
std::cerr 0;
}
pOutput-damage(~0); pOutput-redraw(); Fl::check(); Fl::wait(.1);
Fl::repeat_timeout(0.25, TimerProc, p);
}
int main(int argc, char* argv[]) {
Fl_Window* win = new Fl_Window(300, 200, );
Fl_Output* pOutput = new Fl_Output(120, 50, 0, 15, Caps Lock);
win-end();
win-show();
Fl::add_timeout(0.25, TimerProc, pOutput);
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/08/13 10:35, Howard Rubin wrote:
On Fri, 05 Apr 2013 23:39:28 -0700, Greg Ercolano wrote:
an fltk timer would probably be needed to get the correct
state info shown reliably.
Thanks for the replies.
No luck with an fltk timer, on Ubuntu Linux 10.04. Test program below.
In the console we can see that (Fl::event_state() FL_CAPS_LOCK)
correctly changes to nonzero as soon as you press Caps Lock.
But it doesn't change back to 0 when you press Caps Lock again
until e.g. you move the mouse over the window.
I'm not sure if this is a bug in X11 or not.. kinda seems so.
X11's own KeyRelease events seem to behave similarly;
in my tests with the pure X11 code below, when X11 sends
a KeyRelease event for the capslock key, the event.xkey.state
shows accurate info when capslock is ENABLED, but INACCURATE INFO
when capslock is disabled.
You have to hit some other key to get the accurate state of
capslock after lock release.
So I think FLTK is simply passing this X11 behavior on to the app.
Not really sure if FLTK can fix this if X11 gives similar info.
My X11's a bit rusty, but there might be a way to acquire the realtime
capslock state by a different X library call -- if there is, you should
probably #ifdef that into your code.
#include stdio.h
#include stdlib.h
#include string.h
#include X11/Xlib.h
#include X11/Xutil.h
//
// Slightly modified X windows hello world
//
// ref: http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_c.html
// compile: g++ hello.c -o hello -lXtst -lX11 -lXext
//
int main(int argc, char *argv[])
{
Display*dpy;/* X server connection */
Window win;/* Window ID */
GC gc; /* GC to draw with */
XFontStruct *fontstruct;/* Font descriptor */
XGCValues gcv;/* Struct for creating GC */
XEvent event; /* Event received */
XSetWindowAttributes xswa; /* Temporary Set Window Attribute struct */
// OPEN DISPLAY
if ((dpy = XOpenDisplay(NULL)) == NULL) {
fprintf(stderr, %s: can't open %s\n, argv[0], XDisplayName(NULL));
exit(1);
}
// CREATE 500x500 WINDOW
win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy),
50,50,500,500,// x,y,w,h
0,// border width
0,0); // border color, bg color
XSelectInput(dpy, win, ExposureMask|KeyPressMask|KeyReleaseMask);
// MAP WINDOW
XMapWindow(dpy, win);
// EVENT LOOP
while (1) {
XNextEvent(dpy, event);
switch ( event.type ) {
case Expose:
fprintf(stderr, * Expose event\n);
if ( event.xexpose.count == 0) {
while (XCheckTypedEvent(dpy, Expose, event));
// GET CURRENT WINDOW SIZE (FOR TEXT CENTERING)
XWindowAttributes xwa;
if (XGetWindowAttributes(dpy, win, xwa) == 0)
break;
XClearWindow(dpy, win);
}
break;
case KeyPress:
case KeyRelease: {
const char *ename = (event.type==KeyPress) ? Press :
Release;
printf(%s keycode=0X%04x, state=0X%04x\n, ename,
event.xkey.keycode, event.xkey.state);
break;
}
default:
fprintf(stderr, * Ignored event '%d'\n, (int)event.type);
break;
}
}
return(1);
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
Howard Rubin schrieb: Thanks for the quick reply. Here's what I have now. It's reporting the opposite of of the Caps Lock state. In other words, (Fl::event_state() FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off. Is that what you meant in your last message? Yes, it shows every time the wrong of of two states, so you know for sure the right one - it's !state. I'm less than enthusiastic about displaying the 'Caps Lock is on' message when the test in the code says it's off. Is there really no alternative? It seems, that caps-lock handling starts to work after key handling and I think there might be other problems, like switching caps lock, when there is another window in focus. I think a better way is, to use a timer and to check for change of state e.g. all 0.25 seconds. For humans this is fast enought to appear as instantly. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/05/13 22:58, Edzard Egberts wrote: It seems, that caps-lock handling starts to work after key handling and I think there might be other problems, like switching caps lock, when there is another window in focus. I think a better way is, to use a timer and to check for change of state e.g. all 0.25 seconds. For humans this is fast enought to appear as instantly. Perhaps this problem is perceived in test/keyboard as well by the 'LOCK' state flag staying set while the caps lock key is toggled repeatedly. I found it updates correctly if I just resize the window, so I was thinking the same thing, Fl::event_state() might not have valid state info for the caps lock key at that point in time in the handle() function, and that indeed an fltk timer would probably be needed to get the correct state info shown reliably. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Caps Lock detection
I need to immediately detect when Caps Lock is turned on or off in our
login screen, so I can alert the user. Neither of the approaches I've
tried works.
Both the overrides of Fl_Window::handle and Fl_Secret_Input::handle
don't report that Caps Lock has been turned off until the message after
it's been turned off.
Here's the below sample program's output for the transition from Caps
Lock on to off.
caps lock 7
caps lock 6
caps lock 7
caps lock 8
caps lock 9
caps lock 8
caps lock 10
Howard Rubin
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Secret_Input.H
#include iostream
class myWindow : public Fl_Window {
public:
myWindow(int x, int y, const char* l) : Fl_Window(x, y, l) { }
virtual int handle(int event) {
static int n = 0;
if (Fl::event_state() FL_CAPS_LOCK) {
std::cout caps lock ++n std::endl;
} else {
std::cout caps unlock ++n std::endl;
}
return Fl_Window::handle(event);
}
};
class mySecretInput : public Fl_Secret_Input {
public:
mySecretInput(int x, int y, int w, int h, const char *l)
: Fl_Secret_Input(x, y, w, h, l) { }
int handle(int event) {
static int n = 0;
if (Fl::event_state() FL_CAPS_LOCK) {
std::coutcaps lock ++n std::endl;
} else {
std::coutcaps unlock ++n std::endl;
}
return Fl_Secret_Input::handle(event);
}
};
int main(int argc, char* argv[]) {
myWindow* win = new myWindow(300, 200, );
mySecretInput* inp = new mySecretInput(20, 20, 100, 15, );
win-end();
win-show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/05/13 08:59, Howard Rubin wrote: I need to immediately detect when Caps Lock is turned on or off in our login screen, so I can alert the user. Neither of the approaches I've tried works. Do you see the same problem when using the fltk test/keyboard application? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Secret_Input.H
#include iostream
class myWindow : public Fl_Window {
public:
myWindow(int x, int y, const char* l) : Fl_Window(x, y, l) { }
virtual int handle(int event) {
if (event== FL_SHORTCUT)
{
static int n = 0;
if (Fl::event_state() FL_CAPS_LOCK) {
std::cout caps lock ++n std::endl;
} else {
std::cout caps unlock ++n std::endl;
}
return 1;
}
else
return Fl_Window::handle(event);
}
};
int main(int argc, char* argv[]) {
myWindow* win = new myWindow(300, 200, );
new Fl_SecretInput(20, 20, 100, 15, );
win-end();
win-show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
virtual int handle(int event) {
if (event== FL_SHORTCUT)
if (event== FL_SHORTCUT Fl::event_key()== 65509)
Without check of key every shortcut signals caps lock, thats wrong. And
it seems, the real state establishs after the events had run through,
but because of binary state it's no problem.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
Thanks for the quick reply. Here's what I have now. It's reporting the
opposite of of the Caps Lock state. In other words, (Fl::event_state()
FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off.
Is that what you meant in your last message?
I'm less than enthusiastic about displaying the 'Caps Lock is on'
message when the test in the code says it's off.
Is there really no alternative?
Thanks,
Howard Rubin
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Secret_Input.H
#include iostream
class myWindow : public Fl_Window {
public:
myWindow(int x, int y, const char* l) : Fl_Window(x, y, l) { }
virtual int handle(int event) {
if (event== FL_SHORTCUT Fl::event_key() == FL_Caps_Lock) {
static int n = 0;
if (Fl::event_state() FL_CAPS_LOCK) {
std::cout caps lock ++n std::endl;
} else {
std::cout caps unlock ++n std::endl;
}
return 1;
} else
return Fl_Window::handle(event);
}
};
int main(int argc, char* argv[]) {
myWindow* win = new myWindow(300, 200, );
new Fl_Secret_Input(20, 20, 100, 15, );
win-end();
win-show();
return Fl::run();
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 05.04.2013 22:02, Howard Rubin wrote:
Thanks for the quick reply. Here's what I have now. It's reporting the
opposite of of the Caps Lock state. In other words, (Fl::event_state()
FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off.
Is that what you meant in your last message?
I'm less than enthusiastic about displaying the 'Caps Lock is on'
message when the test in the code says it's off.
Is there really no alternative?
Well, there should be a better way, but it looks like you found a bug
or at least some inconsistency. I'll post two different modified test
programs (derived from yours) that do unfortunately show inconsistent
behavior on Windows and Linux on my test systems, i.e. Windows 7 and
Linux Ubuntu 12.04 an a Virtualbox VM. Maybe someone can test it on
a real Linux box and on Mac OS X ?
Howard, what's your environment ?
Here's #1 that shows more events and gives a clue how to handle the
key, and it works well on Windows, but doesn't on my Linux VM:
$ cat capslock.cxx
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Button.H
#include FL/Fl_Secret_Input.H
#include FL/names.h
#include iostream
class myWindow : public Fl_Window {
public:
myWindow(int x, int y, const char* l) : Fl_Window(x, y, l) { }
virtual int handle(int event) {
if (event == FL_FOCUS) {
std::cout event = fl_eventnames[event] ... ;
if (Fl::event_state() FL_CAPS_LOCK)
std::cout WARNING: CAPS LOCK is set;
std::cout std::endl;
return 1;
}
if ((event == FL_SHORTCUT || event == FL_KEYDOWN || event ==
FL_KEYUP)
Fl::event_key() == FL_Caps_Lock) {
std::cout event = fl_eventnames[event] ... ;
static int n = 0;
if (Fl::event_state() FL_CAPS_LOCK) {
std::cout caps lock ++n std::endl;
} else {
std::cout caps unlock ++n std::endl
std::endl;
}
return 1;
} else
return Fl_Window::handle(event);
}
};
int main(int argc, char* argv[]) {
myWindow* win = new myWindow(300, 200, );
new Fl_Secret_Input(20, 20, 100, 20, );
new Fl_Button(20, 120, 100, 20, Test);
win-end();
win-show();
return Fl::run();
}
// end of file
Compilation and output on Windows:
$ fltk-config --compile capslock.cxx ./capslock.exe
g++ -I/fltk/svn/fltk-1.3 -I/fltk/svn/fltk-1.3/png
-I/fltk/svn/fltk-1.3/zlib -I/fltk/svn/fltk-1.3/jpeg -mwindows -DWIN32
-DUSE_OPENGL32 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -o 'capslock'
'capslock.cxx' -mwindows -static-libgcc -static-libstdc++
/fltk/svn/fltk-1.3/lib/libfltk.a -lole32 -luuid -lcomctl32
event = FL_FOCUS ...
event = FL_KEYDOWN ... caps lock 1
event = FL_KEYUP ... caps lock 2
event = FL_KEYDOWN ... caps lock 3
event = FL_KEYUP ... caps unlock 4
event = FL_KEYDOWN ... caps lock 5
event = FL_KEYUP ... caps lock 6
event = FL_KEYDOWN ... caps lock 7
event = FL_KEYUP ... caps unlock 8
event = FL_KEYDOWN ... caps lock 9
event = FL_KEYUP ... caps lock 10
event = FL_KEYDOWN ... caps lock 11
event = FL_KEYUP ... caps unlock 12
You can see (or guess) that the CAPS LOCK state is updated *before*
the handle message is called on FL_KEYDOWN events, if CAPS LOCK is
being turned ON, but *after* the FL_KEYDOWN event, if it is turned
OFF. That's why the program shows the caps unlock message only on
FL_KEYDOWN events.
Obviously it's a little difficult to get the state of these toggle
keys in a platform independent way, and hence this doesn't seem to
work well on my Linux VM:
$ fltk-config --compile capslock.cxx ./capslock
g++ -I/home/albrecht/svn/fltk-1.3 -I/home/albrecht/svn/fltk-1.3/png
-I/home/albrecht/svn/fltk-1.3/zlib -I/home/albrecht/svn/fltk-1.3/jpeg
-I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'capslock'
'capslock.cxx' -static-libgcc -static-libstdc++
/home/albrecht/svn/fltk-1.3/lib/libfltk.a -lXext -lfontconfig -lXinerama
-lpthread -ldl -lm -lX11
event = FL_FOCUS ...
event = FL_KEYDOWN ... caps unlock 1
event = FL_KEYDOWN ... caps lock 2
event = FL_KEYUP ... caps lock 3
event = FL_KEYDOWN ... caps unlock 4
event = FL_KEYDOWN ... caps lock 5
event = FL_KEYDOWN ... caps lock 6
event = FL_KEYUP ... caps lock 7
event = FL_KEYDOWN ... caps lock 8
event = FL_KEYUP ... caps lock 9
event = FL_KEYDOWN ... caps unlock 10
event = FL_KEYUP ... caps lock 11
event = FL_KEYDOWN ... caps lock 12
event = FL_KEYUP ... caps lock 13
event = FL_KEYDOWN ... caps unlock 14
event = FL_KEYDOWN ... caps lock 15
event = FL_KEYUP ... caps lock 16
event = FL_KEYDOWN ... caps unlock 17
event = FL_KEYDOWN ... caps lock 18
event = FL_KEYDOWN ... caps lock 19
event = FL_KEYUP ... caps lock 20
event = FL_KEYDOWN ... caps lock 21
event = FL_KEYUP ... caps lock 22
event = FL_KEYDOWN ... caps unlock 23
event = FL_KEYUP ... caps lock 24
Re: [fltk.general] Caps Lock detection
Correction: On 06.04.2013 02:10, Albrecht Schlosser wrote: [... about compiling and running program #1] ... event = FL_KEYDOWN ... caps lock 9 event = FL_KEYUP ... caps lock 10 event = FL_KEYDOWN ... caps lock 11 event = FL_KEYUP ... caps unlock 12 You can see (or guess) that the CAPS LOCK state is updated *before* the handle message is called on FL_KEYDOWN events, if CAPS LOCK is being turned ON, but *after* the FL_KEYDOWN event, if it is turned OFF. That's why the program shows the caps unlock message only on FL_KEYDOWN events. The last line should read: FL_KEYUP events., of course. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
