| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2366
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 4 - High, e.g. key functionality not working |
Scope: | 2 - Specific to an operating system |
Subsystem: | X11 |
Summary: | <shift> digit does not work in sudoko demo for X11 |
Version: | 1.3-current |
Created By: | a.rburgers.quicknet |
Assigned To: | matt |
Fix Version: | 1.3.0 (SVN: v7862) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | a.rburgers.quicknet 13:55 May 10, 2010 |
| In the sudoku demo <shift> digit to enter hints currently does not work. In the 1.1.10 version it does.
Applies only to the X11 version. | |
|
#2 | a.rburgers.quicknet 12:55 May 27, 2010 |
| when <CapsLock> is set, hints can be entered.
The code of sudoku.cxx has FL_SHIFT|FL_CAPSLOCK. For some reason FL_CAPSLOCK is detected, but FL_SHIFT isn't | |
|
| Hi! I looked into this and it seems to me that the described behavior results from different keycodes being generated for FL_KEYUP and FL_KEYDOWN events. This can also be observed with test/keyboard.
I am no XIM-expert, but looking at fl_handle in Fl_x.cxx (below "case KeyPress:") I would speculate that something like
keysym = XKeycodeToKeysym(fl_display, keycode, 0);
is missing in the if (fl_xim_ic){ ... } block. Indeed, uncommenting "} else {" in line 1145 does the job. I even think that the test for "!filtered" is unnecessary after all, since filtered is always false at this point (?? not sure, but see lines 858-861).
BTW, this ad-hoc "patch" also cures STR #2207. Maybe there is some relation to STR #2344 as well.
PS: I am having fltk-1.3.x-r7626 and SuSE 11.1 here. | |
|
#4 | greg.ercolano 11:11 Jun 04, 2010 |
| This sounds great.. would be nice to fix all these STRs.
I'll try to test this out myself this weekend.. | |
|
#5 | greg.ercolano 15:28 Jun 05, 2010 |
| I think you meant to say: "Indeed, *commenting out* "} else {" in line 1145 does the job."
Making that change seems to work for me; I get consistent behavior when I comment out line 1145.
It does also seem to fix the "foo.cxx" example in STR #2207. It also seems to fix all problems in STR #2344 when CapsLock is off. (However, when CapsLock is on, there is still some 'unexpected' behavior, but it's still much better than it was)
Good work -- can someone familiar with X bless this change?
I've attached acr's mod as a patch (acr-fix.patch) to make it clear what's being changed. | |
|
#6 | greg.ercolano 16:07 Nov 13, 2010 |
| While looking into STR#2444, I've been looking closely at this section of code, and although I don't know much about X11 with respect to event handling myself, I think the fix is correct.
What we have now:
---- if (fl_xim_ic) { if (!filtered) { <xim style handling of keystroke> } else { <-- PROBLEM <call XKeycodeToKeysym() to convert keycode to keysym> } } else { <non-xim handling of keystroke> } ----
The checking of (!filtered) is to see if XFilterEvent() told us to ignore the event or not. My understanding of XFilterEvent() is that if that if it returns true, we should be ignoring the event /completely/.
Yet with the above "else", we call XKeycodeToKeysym() when 'filtered' is set.
My read of the code is 'filtered' is never true at this point in the code, because above it, where filtered gets set, we have:
---- filtered = XFilterEvent((XEvent *)&xevent, 0); if (filtered) { return 1; } ----
I propose we change that to simply:
---- if ( XFilterEvent((XEvent *)&xevent, 0) ) return(1); ----
..and remove all references to 'filtered', because it's never true.
I've attached an alternate patch, "str2366-erco.patch" that rips out the unused variable and related logic, while keeping the spirit of the OP's fix.
It also fixes some indenting that seems to indicate a bad code merge might have caused the whole problem to begin with. | |
|
#7 | matt 13:17 Nov 16, 2010 |
| Fixed in Subversion repository.
Thanks for the patches! | |
[ Return to Bugs & Features ]
|
| |