FLTK logo

STR #2366

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 greg.ercolano
15:29 Jun 05, 2010
acr-fix.patch
0k
 
 
#2 greg.ercolano
16:11 Nov 13, 2010
str2366-erco.patch
3k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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
 
 
#3 acr
04:29 Jun 04, 2010
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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.