Evan Laforge wrote:
So in the short term it looks like fltk gets by with its own
implementation, because using the OS one is too much work. Entering
Chinese with a character palette is not really practical, it would be
much easier to just write in another app and then paste it into the
fltk
On 16 Feb 2010, at 20:31, Evan Laforge wrote:
Fl_Text_Display is in a similar position, since it's too slow to be
usable.
I suspect that the underlying text engine is actually pretty efficient.
I also suspect, though, that when we redraw the text display, we are
re-rendering far too much
About text entry in FLTK on Mac OS X:
I believe to have reproduced in FLTK-1.3-cocoa all, but not more than,
what was in the carbon version, that is:
- special characters obtained pressing the alt key (e.g., the euro sign)
work well
- national keyboard layouts are correctly handled (this was
On 15.02.2010, at 09:58, manolo gouy wrote:
About text entry in FLTK on Mac OS X:
I believe to have reproduced in FLTK-1.3-cocoa all, but not more than,
what was in the carbon version, that is:
- special characters obtained pressing the alt key (e.g., the euro sign)
work well
- national
I removed about 90% of the X11 specific FLTK keyboard handling in Carbon a
while ago. Assuming that the Cocoa version builds on it, we should still be
letting OS X handle a lot of the keyboard input. I type a lot of German on my
US keyboard and getting Umlauts works as it does on all OS X
On 14 Feb 2010, at 1:18, Evan Laforge wrote:
So from looking around in Fl_cocoa.mm I couldn't help but notice fltk
has this whole complicated system for handling non-ascii text input
that seems to be incompatible with the system provided one. That
probably made sense for X which has (or
Using fltk-1.3, on linux and win32 systems, when I want to input
Japanese or Chinese text, for example, I invoke the host system's IME
and enter text in that.
The IME then sends the composed UTF8 sequences to the foreground
(fltk) window and all seems to be well.
Fltk's own, historical,
On 14 Feb 2010, at 18:02, Evan Laforge wrote:
Fltk's own, historical, compose key mechanism does not seem to me to
be involved (indeed I suspect that mainly handles the typing of LGC
glyphs that don't appear on a your keyboard, e.g. me typing ß on a UK
keyboard that has no key for it...)
Hmm, well if that's true, isn't it all redundant and can be removed
right now?
I don't know.
Possibly it can be, or can be made X11 specific - if we believe the
OSX and win32 implementations cover what's needed.
Even if by some chance the fltk input has some great feature that was
awkward
So from looking around in Fl_cocoa.mm I couldn't help but notice fltk
has this whole complicated system for handling non-ascii text input
that seems to be incompatible with the system provided one. That
probably made sense for X which has (or had, I don't know about now)
no system of its own, but
10 matches
Mail list logo
