STR #2599

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 ]

STR #2599

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:expose dead keys to applications
Created By:ossman
Assigned To:AlbrechtS
Fix Version:1.3.3
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 ossman
04:36 Mar 31, 2011
#2 ossman
04:36 Mar 31, 2011
#3 ossman
04:36 Mar 31, 2011
#4 ossman
04:55 Apr 06, 2011
#5 ossman
04:55 Apr 06, 2011
#6 ossman
04:02 Apr 15, 2011
#7 ossman
04:02 Apr 15, 2011
#8 manolo
12:55 Apr 20, 2011
#9 manolo
15:06 Apr 24, 2011
#10 manolo
01:15 Apr 25, 2011
#11 ossman
05:47 Apr 28, 2011
#12 manolo
03:32 Apr 30, 2011
#13 ossman
02:01 May 05, 2011
#14 ossman
04:07 May 05, 2011
#15 ossman
05:19 May 05, 2011
#16 ossman
05:23 May 06, 2011
#17 ossman
03:22 May 10, 2011
#18 ossman
05:40 May 13, 2011
#19 ossman
05:40 May 13, 2011
#20 ossman
05:40 May 13, 2011
#21 hean01
01:23 Sep 16, 2011
#22 hean01
01:24 Sep 16, 2011
#23 hean01
01:24 Sep 16, 2011
#24 astrand
05:28 Jun 19, 2012
#25 astrand
05:28 Jun 19, 2012
#26 astrand
05:28 Jun 19, 2012
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 ossman
04:35 Mar 31, 2011
Currently dead keys are pretty much hidden away from applications. For most, they don't care and this is just fine. Unfortunately I need to know when these keys are pressed for my application, and since FLTK controls the low level event handling, that means FLTK needs to be improved.

I've composed a bunch of patches that fixes this for all three platforms. Existing applications should be unaffected, but applications that want information about dead keys get some new API functions that can examine the current state and what the current symbol is for each event.

The patches also fixes some bugs in the same code. For X11 it returned a bogus key code for composed characters, and OS X generally had a bad connection between key presses and key events.

These patches are fairly large given this somewhat obscure use case, but I still urge you to seriously consider them. The primary reason being that it's impossible for the application to do this without the help of FLTK, as FLTK controls the event loop.
#2 manolo
09:49 Mar 31, 2011
Thanks for these patches.

I have tested the Mac side of it. It's good to have a clean access
to the internal steps of character composition.
However, input via the character palette is removed by your patch.
So I believe I can't commit it in its present stage.

Also, file src/Fl_compose.cxx appears in the x11 and the mac patches,
so it's unclear what changes to apply.

Under Mac OS, if you add the "input menu" to your menu bar
(Language and text system preferences), add several languages
to this menu, and request keyboard viewer with this menu, you'll
be able to test character composition with any language and keyboard.
Dead keys are orange colored in these keyboard viewers,
and some languages require to press the alt key to reveal dead keys.
The Vietnamese keyboard is especially dead key-rich.
#3 ossman
04:26 Apr 01, 2011
Ah. Mac is still new to me, so please continue to examine those portions extra carefully. For this specific case, it seems that you can get input directly through insertText. Since this isn't a key press, I'm reluctant to present it to the application as such. I see three possible solutions here:

 1) Fake a keydown (and possibly key up) using a special key code meaning "this isn't really an actual key".

 2) Send the text as a FL_PASTE event.

 3) Create a new event type, something like FL_TEXT.


For the next question, the X11 patch also includes the basic groundwork for this change. The second modification to Fl_compose.cxx is because the Mac code was structured a bit oddly compared to other platforms:

- The input widgets rely on Fl::compose() returning false for keys that need special care.

- All platforms except Mac has a test in Fl::compose() for control characters, fixing this.

- For Mac, the check was instead done in the platform code and achieved the correct result by clearing out e_text.

I changed the code so that Mac behaves like the other platforms by looking for control characters. To be honest, Fl::compose() probably needs a rewrite to make it cleaner.
#4 manolo
05:41 Apr 01, 2011
I like the suggestion of sending the character palette input
with an FL_PASTE event. I have checked that replacing the
fake keydown and keyup events by an FL_PASTE event in the present
[FLText insertText] method works well.

Another issue is that dead keys are just part of
the more general topic of text input methods that include things
such as CJK input methods. In Mac OS, these methods are
supported by the so-called NSTextInput protocol (or its newer
version NSTextInputClient) that FLTK should implement to fully
support text input.
The present implementation of this protocol is extremely rudimentary
and provides only full support of dead-key character composition,
and some functionality for the Pinyin simplified Chinese input
Functions such as setMarkedText, unmarkText
are essential actors of this protocol, and they should not be
modified in a way that renders them unable to support more
of the general Mac OS text input methods. I would just like
to draw your attention to this aspect of changing these functions.
#5 ossman
05:31 Apr 06, 2011
Updated patches for X11 and Mac. The X11 patch fixes a header issue for Solaris. The Mac patch starts doing FL_PASTE for insertText calls that aren't part of a keyboard event.

As for CJK, I have to admit that I have no experience how that works. As the current code states that CJK is a future project, my assumption was that I didn't need to fix that now. It's not really something I have the means to deal with now anyway.
#6 ossman
04:02 Apr 15, 2011
Updated patches for todays snapshot.  
#7 manolo
12:57 Apr 20, 2011
I have checked the new Mac OS patch. I see that all character composition
sequences work well, as does character palette input.

I am however concerned that the changes introduced in functions setMarkedText
and insertText hinder the present text input capabilities of FLTK.
Presently, it is possible to use with FLTK1.3 the "Pinyin - Simplified" input
method of Chinese characters, to some extent at least.
If you activate this method, and type
li <space> wu <space> luo <space>
you'll obtain these three Chinese characters 立无罗, the same as you would
obtain if you type the same sequence in, say, TextEdit.
With the patch, the result is unpredictable, that is, not reproducible.
This is because there is a memory allocation problem in these statements:
        Fl::e_text = (char*)[received UTF8String];
        Fl::e_text = (char*)[aggregate UTF8String];
After them, Fl::e_text points to a memory location that can become reused
as soon as the "received" or "aggregate" NSString objects are deallocated,
that is, some time after return from the functions where these objects
are defined.

I propose a modified version of your patch that handles both character
composition and the small part of CJK input that's already supported
(see fltk-1_v4.3.x-dead-chars-mac.patch).

Also, I don't understand why you build Fl::e_text in setMarkedText as
the concatenation of the previous Fl::e_text and the received string.
Besides the fact that the memory allocation in there is very problematic,
I don't see why there's need for a concatenation. Are there cases
where more than one character is a dead key in character composition
under Mac OS ?

Thus, please, test the modified patch and post if it does not cover
some character composition cases.

I would also suggest that you put the cocoaDead2FLTK function in your
application code rather than in FLTK itself. Indeed, there are many
more dead keys than the five considered by this function. Thus, it's
a feature of your application to take care of these five only, rather
than a feature of the application-neutral FLTK library. Do you agree ?

I have also added a couple of missing  
fl_lock_function() / fl_unlock_function() pairs of calls.
#8 mingodad
03:52 Apr 21, 2011
I don't know if it's after the modifications that are in place here are the problem, but I do know that with the svn trunk on win32 there is no way to use "@|#[]{}€" from a Spanish keyboard, it worked before.

@ = ALT_Gr + 2
€ = ALT_Gr + e
# = ALT_Gr + 3
#9 manolo
06:09 Apr 21, 2011
Nothing from this STR has been committed yet.
Domingo: could you help identifying when did these key combinations
stop working ?
#10 mingodad
08:20 Apr 21, 2011
Not really because I was away for weeks and today I did a svn update and noticed that I can't enter any ALT_Gr + any key on win32, didn't tested on other OSs.  
#11 manolo
01:38 Apr 24, 2011
I have tried the x11 patch, and I find that dead-key compositions
work well, but that compose-key compositions are broken.
Linux standard compose key character composition sequences are in:
These work with the svn FLTK 1.3. With your patch added, the composed
character does appear, but the first character of the sequence also
appears. For example, c with cedilla is obtained with
<compose> , c
With the patch ,ç is inserted in the text.

Compose key usage is a major feature of non-ascii input on the
unix/linux platform. Thus the enhancement you propose should
support it.
#12 manolo
15:08 Apr 24, 2011
I propose the attached fltk-1_v4.3.x-dead-chars-x11.patch
to fix the compose-key character composition procedure.
#13 ossman
05:05 Apr 28, 2011
First off, thanks for helping out so thoroughly in this rather pesky area. :)

We'll start of with the mac portions:

> With the patch, the result is unpredictable, that is, not reproducible.
> This is because there is a memory allocation problem in these statements:

The object lifetime handling on Mac takes some getting used to and I can't say I was entirely sure things were correct. From what I understood, most things are put in a "autorelease pool", which generally meant they lived long enough for the event to be processed but no longer. I assumed that e_text and friends were only valid from an FLTK event handler, and hence the lifetime of these objects were sufficient. This was also before I had considered the more advanced input methods.

A more robust allocation scheme like the one you have proposed is very much welcome.

> Also, I don't understand why you build Fl::e_text in setMarkedText as
> the concatenation of the previous Fl::e_text and the received string.

This was added to deal with how OS X deals with bad compose sequence. E.g. press dead tilde twice, which will result in:

Press 1:
    setMarkedText (tilde)
Press 2:
    insertText (tilde, overwritting the earlier tilde)
    setMarkedText (tilde)

Hence the need to concatenate the data from insertText with the one from setMarkedText.

> I would also suggest that you put the cocoaDead2FLTK function in your
> application code rather than in FLTK itself.

I added this method for two reasons:

1. We need a set of platform independent symbols, as we cannot rely on all three platforms having the exact same representation of dead keys (they don't).

2. I did not want to use the "non-dead" versions of the symbols as that could possibly create ambiguities.  Say on X11 where you could generate ò using either "<dead grave> <o>" or "<compose> <grave> <o>". So for applications that want to see the specific symbols, differentiating between "dead" and "non-dead" seemed important. And since Unicode has an equivalent concept in combining characters, that seemed like a good symbol set to use.

(The Win32 code has a similar translation routine)
#14 ossman
05:47 Apr 28, 2011
For X11:

I'm not sure I can follow your changes. It seems like the variable you set makes it hide the next character, not the current one. And what's the deal with the Shift keys?

The bug in my patch is that it assumed that Xutf8LookupString() would always return nothing for intermediate stages. This is wrong, and the obvious fix is to clear out the buffer whenever XFilterEvent() returns true.
#15 ossman
05:48 Apr 28, 2011
Updated X11 patch that just makes sure that e_text is empty when we're in the middle of a composition.  
#16 manolo
01:31 Apr 29, 2011
The concern now, is whether the patch you propose interferes with
CJK text input which is, according to some user feedback, supported
by the current unix/linux FLTK version. My problem is that I don't
know how to check for possible interference.

I have no idea about the current situation for the MSWindows version.
#17 ossman
01:46 Apr 29, 2011
Neither do I, unfortunately. Do you have some contacts in your end that you could ask to help out? It would be a shame to have the process stall now that we've gotten this far.  
#18 sparkaround
02:19 Apr 30, 2011
Hi Manolo, I am here. I can do a simple test with cjk input method.
But it seemed that there are some problem with the version:

$ svn co fltk-1.3
$ cd fltk-1.3
$ LC_ALL=C svn info
Path: .
Repository Root:
Repository UUID: ea41ed52-d2ee-0310-a9c1-e6b18d33e121
Revision: 8628
Node Kind: directory
Schedule: normal
Last Changed Author: manolo
Last Changed Rev: 8628
Last Changed Date: 2011-04-30 04:25:04 +0800 (Sat, 30 Apr 2011)

$ wget ''

$ patch -p1 < fltk-1_v5.3.x-dead-chars-x11.patch
patching file FL/Enumerations.H
Hunk #1 succeeded at 423 (offset -2 lines).
patching file FL/Fl.H
patching file src/Fl_compose.cxx
Hunk #1 succeeded at 30 with fuzz 2 (offset -1 lines).
Hunk #2 succeeded at 96 with fuzz 2 (offset 2 lines).
patching file src/Fl_x.cxx
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
#19 manolo
03:33 Apr 30, 2011
Hi Sparkaround,
It's great to get your help!
Please, use the new svn diff file I just attached that groups the
Linux and win32 changes.
#20 sparkaround
10:54 Apr 30, 2011
CJK input does not work if the new svn diff is applied. When I run the editor in the test directory and press "ctrl-space" to activate the input method, the input panel appear. Then I try to press some keys to input the cjk characters . While if these keys used to select cjk characters are pressed, the ascii characters of the keys are inserted to the editor directly as if the cjk method were not activated.  
#21 sparkaround
20:14 Apr 30, 2011

1.The above test was done on my linux box with a Chinese XIM Input Method called fcitx.

It seemed that compose keys and XIM can't be supported at the same time:

2. On the other hand, I have just finished the test on win32. It seems that this diff does not interfere IME on windows. At least, I can input CJK characters in the editor window successfully. I can't see any problems until now.

You are welcome!

#22 manolo
03:51 May 01, 2011

Thank you so much for helping on this CJK input issue where I
am essentially helpless!

My understanding is:
1) with the patch, CJK input functions well under MSWindows;
2) with the patch, CJK input is destroyed under Linux;
3) without the patch, that is, with the svn FLTK 1.3, CJK input
functions well under Linux.

Is that correct ? In particular is statement 3) above true ?
Because we know that character composition runs well with the svn
FLTK under Linux. This would suggest that composition and CJK input
are somehow compatible, may be not for the same locale though.

If CJK input is destroyed by the patch, I will not commit this patch,
because CJK input is more important than detection of intermediate
steps of character composition, unless you or the author of STR 2599
can correct the problem.
#23 manolo
03:57 May 01, 2011
Transformed into an RFE because that's what it is.  
#24 sparkaround
07:24 May 01, 2011

Yes, it is correct. 1,2 and 3 are all true. For more detail of statement 3:
1. under Linux:
a. CJK input for gbk locale will be supported only if cp936 option is enabled(./configure --enable-cp936). If cp936 is not enabled, the character input with XIM is "?" but not CJK character.
b. CJK input for UTF-8 locale works well whether cp936 is enabled or not. It seemed that all CJK characters supported by the locale can be inserted to the editor buffer correctly.
c. CJK input for GB18030 locale works whether cp936 is enabled or not.
But the extended characters(outside of gb2312) can't be input correctly. The characters appended to the buffer is irrecognizable CJK characters if I try to insert the extended characters with XIM.
c. CJK input for gb2312 locale does not work whether cp936 is enabled or not. Nothing will be appended to the editor buffer if XIM is activated. While it is not a very critical problem since gb2312 is a subset of gbk.
2. under MSWindows:
The CJK input just works well.

Is it possible to test character composition with normal keyboard? If it is, I can try to confirm whether the composition functions and CJK input functions in fltk-1.3 can work at the same time for my locale.

I am sorry that I am a little busy recently and have no time to try to correct this problem. But I can test the diff if it is updated for CJK input.

#25 manolo
08:49 May 01, 2011

Many thanks for your precious help.

Yes, I believe you can test compose characters with any keyboard.
You have to define a compose key, if you don't have one already
defined. For this, use the options of the
keyboard layout in the keyboard preferences.
For example, I use the right alt key
as a compose key. Then type for example
<compose-key> , c
to obtain this letter: ç
This web page lists many character composition sequences:
#26 ossman
07:24 May 02, 2011
I think I've managed to get fcitx running here. I don't understand much of it, but I think it's enough for me to see what's going on. :)  
#27 sparkaround
19:58 May 02, 2011

I have try to enable "Compose key" with
$ setxkbmap -option "compose:ralt"

I can see "Multi_key" with xev when I press Right Alt Key.

But compose sequence can't be recognized in gnome-terminal.
I have checked

The Compose sequence for GBK is NULL. I add some in ~/.XCompose. It does not work.

I also try to set locale to en_US.UTF-8 and startx.  When I press Shift + AltGr or AltGr + <First> + <Second>, the <First> key will not printed on the screen as gbk locale. But I can't input Compose key yet.

Someone say that Compose key works as XIM method. We can't use two XIM at the same time. That may be the reason that I can't input Compose key:
And it seems that fcitx have no built-in Compose support. Some other XIM may have built-in support for Compose key.

Then I disable fcitx and restart X with en_US.UTF-8 locale. But nothing new. I can't input special characters with compose keys. I also try to input special characters with compose keys in xterm, emacs, firefox or fltk.  All attempts have failed. So I think there are some problems in my gentoo box. Maybe the problem can be solved easily if I can load Compose file on the fly. But I do not know how to do this. I need spare time to figure it out. 

I have to say that the support for compose keys in x window does not work at all here. So I can't help you with the compose keys testing for fltk now.

#28 ossman
04:01 May 03, 2011
I've had a look at things and it seems that fcitx doesn't like it when you call Xutf8LookupString() before XFilterEvent().

The XIM API is a bit undocumented and seem to be governed by defacto standards and best practices. I did however find this guide from SGI:

Given this, I'd be hard pressed to say that fcitx is buggy and what we're doing here should be allowed. There is also the fact that XIM leaves room for things like popping up extra windows, having mouse interactions and whatnot...

In conclusion, I think the model I was aiming for is impossible to implement. The input method stuff is designed on the assumption that the application is only interested in what text to insert. That assumption is of course wrong here. So time for plan B. I have two ideas:

1. Implement a hook system in FLTK where applications get an opportunity to handle platform events before FLTK. Then our application can try to sort this out in its own custom way and FLTK will just be told to ignore some events (similar to how XFilterEvent() works).

2. Add functionality so that we can tell FLTK that we do not want fancy IM stuff for a certain widget, and FLTK will as a result only deliver simple key events for that widget.

I'm going to make an attempt at #2 as that allows other people to benefit from our work, and it might make it easier to solve and side issues that occur when you're avoiding input methods now and then.
#29 AlbrechtS
04:18 May 03, 2011
Pierre Ossman wrote: "1. Implement a hook system in FLTK where applications get an opportunity to handle platform events before FLTK. Then ..."

This does already exist, see Fl::event_dispatch(Fl_Event_Dispatch d), so you could do this, but I agree that #2 might be the better alternative for the reasons mentioned above by you.
#30 ossman
04:35 May 03, 2011
Actually, Fl::event_dispatch() is called much later than what is needed here. It allows intercepting FLTK events, but not the native ones. It would be something similar though, just called earlier in the chain.  
#31 manolo
04:53 May 03, 2011

Many thanks for your great help.
We now have all the information needed about the patch and the
issue of composed character sequences.

#32 ossman
02:04 May 05, 2011
Initial stab at a new method.

Instead of trying to augment the existing information, I've now added a new widget flag that switches to a simpler keyboard model (that is based around key presses instead of resulting text input).

I've also done some related fixes:

a) There was two pieces of XIM code, but from what I can tell and google, only one has ever been used. I've removed the other one as part of the reshuffle.

b) The non-XIM code still seemed to be left behind in FLTK 1.1 latin-1 land. I changed it to behave the same for every keysym/codepoint.

Note that this is just a first prototype. I have still to look at the other platforms and do more testing. Feel free to inspect and comment though.
#33 ossman
05:22 May 05, 2011
Basic prototype for all three platforms done. What this does so far is disable advanced input when a certain widget has focus, and reenables when another widget gets focus. Seems to work fine here, but please test more.

What is left is more testing to see that "simple mode" provides enough information to be useful. So more patches are expected.
#34 ossman
00:47 May 06, 2011
I'm having some problems on OS X. As I'm avoiding interpretText, all information is gotten from the NSEvent object. Unfortunately that won't give me any dead symbols (not really surprising as that is also what the docs say).

Now the question is if there is some other place to get this information. I have some guesses:

a) Getting the keyboard layout from the system and calculating manually what the symbol should be.

b) Finding some system function that does a) for us.

c) Getting the input method in some mode where it doesn't pop up extra windows and fancy stuff like that and only calls insertText and friends directly.

I've been digging around but haven't found anything so far. Anyone more experienced with OS X that has some ideas?
#35 ossman
05:28 May 06, 2011
I had a look at what Mozilla does to solve this issue, and copied their approach. The basic principle is that it tells OS X that it only wants "Roman" keyboards.

I have two gotchas though:

1) It doesn't toggle back to the old input manager. This behaviour is also seen with Firefox, so if it's good enough for them then maybe it is good enough for us?

2) This is a Carbon function, not Cocoa. It is also removed in the 64-bit API with no clear replacement. What is the status of FLTK on 64-bit OS X? Do I need an #ifdef for this?

(If you want to test firefox' behaviour, just go to a site with a password field and select it)
#36 ossman
05:42 May 06, 2011
Found more info. Apparently Apple uses this method for WebKit as well:

That should be a reasonable stamp of approval.

The above code also shows some replacement method for newer OS X. The same code can also be found in the latest branch of Mozilla. Unfortunately it requires OS X 10.5 and my build environment is 10.4 so I can't really experiment with it.
#37 manolo
05:58 May 06, 2011
> Getting the input method in some mode where it doesn't pop up
> extra windows and fancy stuff like that and only calls insertText
> and friends directly.

Mac OS won't popup any extra window unless its user activates a fancy
input method. Thus, if your application makes sense only for
"alphabetic" keyboard uses, you can call interpretKeyEvents
that will call setMarkedText that will put the dead key in Fl::e_text.

A tentative way to explore:
- define an NSText subclass with custom setMarkedText, and
program in this setMarkedText whatever is needed when a deadkey
is pressed
- associate widgets that have the SIMPLE_KEYBOARD feature ON
with this subclass by changing this message function
 (id)windowWillReturnFieldEditor:(NSWindow *)sender toObject:(id)client
that gets called at every keystroke, dead or alive.

Once this is done,
    NSText *edit = [[theEvent window]  fieldEditor:YES forObject:nil];
in handleKeyDown will return the custom NSText subclass for
SIMPLE_KEYBOARD widgets, and the custom setMarkedText will be
called for deadkeys.
#38 manolo
06:13 May 06, 2011
32-bit-only functions MUST be avoided because 64-bit compilation
is the default on recent Mac hardware.
#39 ossman
06:38 May 06, 2011
I'm afraid I don't quite understand. We cannot just call interpretKeyEvents as that call is what causes the input method to pop up things.

Do you have a build environment so that you can test on OS X >= 10.5 if I provide patches? If so, then I can explore the method used by newer Firefox and Safari.

(Note that this will be on Monday at the earliest though)
#40 manolo
08:55 May 06, 2011
My understanding is that what you are trying to do does not apply to
situations where input methods are used to input complex
scripts such as CJK, but is limited to following simple things
such as dead keys and character compose sequences with a compose key.

In that case, you can call interpretKeyEvents and won't have any popup.
And you can be sure of that as long as your user does not activate
a "special" input method.

If this is wrong, it means I did not understand your objective.

Please, notice that what you are trying to do modifies a critical,
core feature of FLTK on all platforms. Thus, commit will require
extensive testing by several developers.
#41 manolo
08:57 May 06, 2011
I can test on Mac OS X 10.6  
#42 ossman
00:31 May 09, 2011
This is meant to work on all systems, including those that might normally use advanced input methods (although I can't say we have a heavy userbase of those ATM).

The use case is programs interested in the physical key presses. In my case that's a thin client software. For users that need advanced input, they would be using this FLTK client locally and the advanced input method on the server. So the widget presenting the remote interface just want keys, whilst if I pop up some kind of local input dialog then I want the "normal" way of things.

Since the land of keyboards are so poorly standardised, we also need some basic symbol information to make things behave sanely. Hence the need for resolving things like dead keys and not just trying to use the key codes.

I'd say the method I've found on OS X and Win32 is rather elegant in that it gives a clear visual feedback in the OS that this application is disabling the advanced input methods. It should also be a stable method as Apple are using it themselves in Safari.

Testing is of course crucial. So far I haven't had to break the ABI though, so it doesn't have to hold up 1.3.0. And I can always have a compile time test for this in our code until it gets merged.
#43 matt
00:47 May 09, 2011
Is this ready to go into the RC for 1.3? Otherwise, I will move this to 1.4. Thanks!  
#44 ossman
02:17 May 09, 2011
It is not ready right now, no. But I hope to have in a working state this week.

Even if it doesn't make 1.3.0, I'd still like to see it during the 1.3 life cycle. Or will you have a complete feature ban until 1.4.0?
#45 ossman
03:24 May 10, 2011
Managed to get access to a 10.5 development environment so that I could experiment. This updated patch uses the newer API when possible and falls back to the old one if you are targeting OS X < 10.5.  
#46 manolo
03:54 May 10, 2011
Please, prepare your patches in relation to the last svn version.  
#47 ossman
05:42 May 13, 2011
Updated patches, this time against latest weekly snapshot.

We have a RPM based build system here, which means I need tar balls. Unfortunately I haven't been able to build them myself from svn, so I've been relying on the weekly ones.

I've done some preliminary testing and these patches should be considered final (until more bugs are found ;)).
#48 ianmacarthur
05:54 May 13, 2011
@Pierre: "We have a RPM based build system here, which means I need tar balls. Unfortunately I haven't been able to build them myself from svn, so I've been relying on the weekly ones."

You could try giving EPM a shot -

I think Mike and Matt have tweaked the EPM files a bit for the 1.3.0 rc, and it can generate RPM's, so should be able to generate the RPM's you need from the recent svn snapshots.

Any use?
#49 hean01
01:25 Sep 16, 2011
Posted updates of our set of patches.  
#50 ossman
05:06 Nov 21, 2011
What's the status of feature bugs like this? Can they be applied for a future 1.3.x? If not, what are the plans for 1.4.0?  
#51 astrand
05:29 Jun 19, 2012
Posted updated patches, which applies to latest trunk.

My suggestion is that we reconsider them for the 1.3.x branch.
#52 manolo
08:09 Feb 02, 2013
The current svn repository version (r.9812) completes an extensive
reorganization of text input with the Mac platform.
I believe that with this version, it's possible to follow each
raw keystroke without need for a complex FLTK patch (with mac at least).

- determine with Fl::event_state() what modifier keys are pressed
- determine reading Fl::event_key() if it's a non-text producing
key (e.g., arrows, Fn, delete, newline, escape, tab)
- if not, get the resulting text in Fl::event_text(). Furthermore
call Fl::compose(int del) when processing the FL_KEYBOARD event.
After that, a >0 value of Fl::compose_state will indicate that the
pressed key is a dead key, if that's of interest for the application.
#53 ossman
02:17 Feb 04, 2013
The changes are interesting, but I'm afraid we don't have anyone available to evaluate them right now. We'll have to get back to you at a later time.  
#54 AlbrechtS
05:33 Oct 10, 2014
After reading what this is all about, I got the impression that this STR may not be needed anymore. IIRC we got the early event hook in FLTK recently, and we also have Fl::disable_im(), so that everything needed may be available. Is this true?

Pierre, can we close this STR now?
#55 ossman
05:43 Oct 10, 2014
Correct. Feel free to close it.  
#56 AlbrechtS
05:57 Oct 10, 2014
Thanks for confirmation. Closing.  
bottom left image   bottom right image

Return to Bugs & Features ]


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