| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2444
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | SGI: CTRL key not working in editor/input widgets over X remote connection |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | greg.ercolano
11:02 Nov 13, 2010 |
| Hitting CTRL-A, CTRL-C, CTRL-V generates the respective ascii characters
(a,c,v) instead of triggering the CTRL-shortcuts. Seeing this with the test/input and test/editor programs.
However, the menubar program's CTRL-A shortcut is triggering properly.
So there must be something different about how menu shortcuts are handled vs. how input/editor widgets handle the CTRL key.
This seems to be a regression; fltk 1.1.6 doesn't have this problem;
the editor's ^A/^C/^V shortcuts work normally.
Also, the SGI's own 'nedit' GUI program's shortcuts work normally as well.
Test environment:
From a linux 32bit (ubuntu8.04) machinem I'm rsh into a 64bit SGI with FLTK built locally on the SGI, and run the various test programs over the X connection, where the apps run on the SGI, but open the GUIs on the linux machine. | |
| |
| #2 | greg.ercolano
11:29 Nov 13, 2010 |
| Some digging.
I decided to focus on the Fl_Input::handle_key() function Fl_Input.cxx
to see what comes in when sequences like CTRL-C are used. Specifically:
char ascii = Fl::event_text()[0];
When running in the SGI environment described above, hitting CTRL-C
calls the handle_key() function twice, once for each keystroke:
1) User hits CTRL, ascii = 0
2) User hits C, ascii = 0x63 <-- 'c'
When running locally on the linux machine, it too calls handle_key()
twice, once for each keystroke, but:
1) User hits CTRL, ascii = 0
2) User hits C, ascii = 0x03 <-- ctrl-c!
So that's the problem. I'm not sure how to solve it though.
Seems to go deeper into the FLTK code with respect to how
FL_KEYBOARD events affect the contents of Fl::event_text(). | |
| |
| #3 | greg.ercolano
12:34 Nov 13, 2010 |
| This might be new with the UTF8 mods.
I've traced it down to what appears to be a difference in
the behavior of XUtf8LookupString() between the SGI and Linux.
In Fl_x.cxx, it's after this call to XUtf8LookupString()
that the buffer[0] gets 0x63 on SGI, and 0x03 on linux:
----
if (fl_xim_ic) {
if (!filtered) {
Status status;
len = XUtf8LookupString(fl_xim_ic, (XKeyPressedEvent *)&xevent.xkey,
buffer, buffer_len, &keysym, &status);
----
On both platforms, XUtf8LookupString() is passed in an xevent.xkey
structure that seems to have the same values going on both platforms
for these values, and except for buffer[], the keysym and status return
values are the same as well.
Both platforms show these values:
<CTRL> -- xkey.keycode=0x25 xkey.state=0x00 keysym=0xffe3 status=0x03
<C> -- xkey.keycode=0x26 xkey.state=0x04 keysym=0x0061 status=0x04
..vs just hitting the 'C' key:
<C> -- xkey.keycode=0x26 xkey.state=0x00 keysym=0x0061 status=0x04
^^^^
So it seems like the linux box's XUtf8LookupString sees xkey.state
being 0x04, and makes the buffer[] contain the CTRL-C, whereas the
SGI ignores this, returning the 'c' character. | |
| |
| #4 | greg.ercolano
14:56 Nov 13, 2010 |
| Hmm, I see.
FLTK has its /own/ implementation of XUtf8LookupString()
in src/xutf8/utf8Input.c, and /both/ platforms, SGI and Linux
are using it.
So the platform specific behavior is not XUtf8LookupString(),
but it's in the calls it makes.
Seems the problem is with platform specific behavior in:
** XmbLookupString() ***
On entry to that function, from what I can tell of the xevent
structure, the same data goes in on both platforms, but different
data comes back from that function (0x03 vs 0x63).
Not sure which is correct. Maybe we need our own version
of that function? Or maybe it's a bug long since patched on SGIs.
(I haven't patched the sgi in years). | |
| |
| #5 | greg.ercolano
10:01 Nov 14, 2010 |
| Attaching 'sgi_workaround_v1.patch' which solves the immediate problem.
It's a hack. It'd be much better to 'fix' our XUtf8LookupString()
code so that it works consistently. (Specifically its use of XmbLookupString() which seems to be the real problem)
Of note: I tried changing our call in Fl_x.cxx to XUtf8LookupString()
back to XLookupString() (older FLTK versions used to use) and that
solved the problem too. So it's clear our XUtf8LookupString()
does not act the same as XLookupString() with CTRL keystrokes.
Comments welcome! | |
| |
| #6 | matt
01:15 Dec 19, 2010 |
| Greg. Do you want to fix this or keep it open. If you keep it open, would it be OK to move it to 1.4? | |
| |
| #7 | greg.ercolano
11:01 Dec 19, 2010 |
| Afraid I don't know how to fix it, I'd say bump to 1.3.1 and mark it as a known problem. | |
| |
| #8 | greg.ercolano
14:09 Aug 01, 2014 |
| (testing str mail delivery for this str) | |
| |
| #9 | greg.ercolano
06:50 Jun 24, 2015 |
| Closing this because the days of SGI are far behind us. | |
[ Return to Bugs & Features ]
|
| |
