Japanese bugs,
was Re: [sldev] OS-SL Development Issues (was Upcoming viewer
releases)
Alissa Sabre
alissa_sabre at yahoo.co.jp
Sat Sep 15 02:21:22 PDT 2007
> I added a comment about this to VWR-250, but can you upload a .zip of
> your source for the following files into that task?
I'm somewhat busy now, but I think I can do it later today. If I have
a time, I will upload the latest copy in my own repository, as well as
the ones that I have already submitted on JIRA as a patch.
The latest ones contains some minor bug fixes and some big
refactoring. My own development is in the final cleanup phase now,
and my original plan was to submit the final patch on the end of
September.
So, if you are to merge my changes manually, I recommend you to start
with the latest one. I can submit further changes as a patch against
your merged code when it is available. (Hopefully during the RC
phase.)
> On Windows, I submitted the changes that put the IME window into the
> right position, but it just missed the latest merge into our release
> pipeline so it will be another week or two before it gets into the RC
> source. This is doing the call to ImmSetCompositionWindow() so it
> shows up in the correct place.
Hmm. I don't think it is the right direction.
# Sorry for most of the sldev readers: the following discussion
assumes you have some deep knowledge on how Chinese/Japanese/Korean
input methods work on Windows and MacOS... If you are not familiar
with these concepts, keep reading further can be a waste of time...
:-)
Using ImmSetCompositionWindow means that you rely on the IME's
composition winodw and just controling the location of it. Is this
correct? I have several reason why I think it is a right direction,
but the first one is that we can't do the same thing on MacOS. MacOS
has no such thing as composition window on Windows. MacOS provides a
bottom line input window, but it is not a MacOS counter part of
composition window. It is something like a famous kinput tool on X
Window.
As long as you rely on availability of composition winodw, you can't
get the same functionality on MacOS.
If you see my patch, you will find that ImmSetCompositionWindow is not
used. Instead, my patch uses ImmGetCompositionString to extract
composition string and pass it to LLTextEditor/LLLineEditor to draw
the composition string at a right position. You can do the same thing
on MacOS through slightly different interface: you receive an
equivalent to the composition string (as well as related information
such as clauses) as parameters to the
kEventClassTextInput/kEventTextInputUpdateActiveInputArea Carbon event
on MacOS.
That's what my patch does essentially.
I patched the LLLineEditor and LLTextEditor so that they can handle
composition string, i.e., to receive composition string with clause
information and to draw composition strings differently than the
ordinary text contents. Some more methods (defined in a new abstract
class LLPreeditor) are also added to facilitate more advanced input
method features.
You may think an LLPreeditor is our own implementation of the
functionality provided by Windows composition window.
I also patched LLWindowsWin32 and LLWindowMacOS so that they drive
LLLineEditor and LLTextEditor through LLPreeditor interface to behave
properly. Most of this job is done in
LLWindowWin32::handleCompositionMessage on Windows and in a
kEventClassTextInput/kEventTextInputUpdateActiveInputArea event
handler on MacOS respectively.
Other parts of my patch are to support advanced features of input
methods, e.g., re-conversion and context-dependent conversion (aka,
application document access from input methods.)
> Unfortunately, as you mentioned, Mac OS X doesn't seem to have the
> equivalent functionality so it will likely require the much more
> complicated code you have worked on.
Yes, it is complecated, but it gives users better typing experiences
than to rely on compositioin window. So, I don't think it is a waste.
The complecation is the necessary cost to provide better user
experiences.
If you are to merge the code, I'm happy to help you, but
unfortunately, I'm leaving Japan tomorrow and will not back until
Saturday. I hope I can read emails and access to SL jira/wiki during
the trip, but I can't log in to SL or to use development environment
during the period.
Alissa Sabre
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/
More information about the SLDev
mailing list