> 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
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
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)
> 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 C
On 04/10/13 14:56, Ian MacArthur wrote:
>
> 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 user
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 h
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
On 10 Apr 2013, at 21:55, Richard Sanders wrote:
> 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 m
On Wed, 10 Apr 2013 10:05:04 -0700, Greg Ercolano
wrote:
>On 04/10/13 09:25, Howard Rubin wrote:
>> On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano 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 i
On 04/10/13 09:25, Howard Rubin wrote:
> On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano 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.
On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano 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
_
On 04/10/13 03:31, MacArthur, Ian (Selex ES, UK) wrote:
> - With the VBox VM hosted on Win7:
> - With the VBox VM hosted on OSX:
Wow, quite a variety of behavior.. VMs have a lot of work to do
to emulate the entire OS hardware, translating it from API to another.
I'd sure h
> > 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
On 9 Apr 2013, at 23:20, Greg Ercolano wrote:
>>> 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, wit
>> 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,
>
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
On 9 Apr 2013, at 20:18, Howard Rubin wrote:
> On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano wrote:
>> unsigned n;
>> XkbGetIndicatorState(d, XkbUseCoreKbd, &n);
>> caps_state = (n & 0x01) == 1;
>
> That works perfectly, and even better, needs no timer
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() wo
On 04/09/13 12:18, Howard Rubin wrote:
> On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano wrote:
>> unsigned n;
>> XkbGetIndicatorState(d, XkbUseCoreKbd, &n);
>> caps_state = (n & 0x01) == 1;
>
> That works perfectly, and even better, needs no timer. Test p
On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano 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
Oh, and I meant to say:
If I call XQueryKeymap() I can see the Caps Lock key being pressed and released
(well, I see one bit in the mask that tracks whether I am holding the Caps Lock
key down or not, which I infer "is" the Caps Lock key bit...)
But in the diagnostic output I see instances whe
> 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
> 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
On 04/08/13 18:46, Greg Ercolano wrote:
> My X11's a bit rusty, but there might be a way to acquire the realtime
> capslock state by a different X library call
FWIW, 'xset q' will tell you the state of the keyboard LEDs, eg:
$ xset q | grep LED
auto repeat: onkey click
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 be
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_s
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 stat
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, i
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
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 la
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 di
>> 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 sta
> #include
> #include
> #include
> #include
>
> 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 (F
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?
_
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
35 matches
Mail list logo
