Previously only the x value was used to determine the screen to which a
candidate panel should below. That was incorrect. The entire point needs
to be considered.
This fixes the same issue that affected OpenVanilla:
https://github.com/openvanilla/openvanilla/issues/49
We now let the Installer to call the TextInputSources API. Since macOS
12, users are prompted to allow enabling of third-party IMEs in
Preferences.app the momemnt TISRegisterInputSource or
TISEnableInputSource is called. By moving the activation to the
Installer, a user will clearly see that it's the Installer that wants to
enable the IME.
In addition, we had to make necessary changes so that on macOS 12 and
later, the Installer always enable the default input source. This is due
to the observation that the kTISPropertyInputSourceIsEnabled becomes
unreliable on macOS 12--it may be true even if the user has removed the
input mode from their active input mode list in Preferences.app.
This ensures that, after the Installer has killed the current input method
process, the Installer can tell if the translocated input method bundle is no
longer mounted. It turns out that getfsstat() may return cached results and a
call to statfs() is necessary.
This fixes the bug that the Installer did not always correctly report that a
new version of the input method has been installed over a previous version.
The bug only manifests when getfsstat() returns cached results. That seems to
be the case on newer versions of macOS.
This fixes a bug that, when a span covers several nodes and a long node
has already been candidate-fixed, fixing a short node does not cause
the walk to reflect the result.
A concrete example:
1. type 高中生.
2. move the cursor to 中 and change to 鐘聲: 高鐘聲.
3. with cursor position unchanged, select the candidate to 忠.
4. the expected result should be 高忠生 but instead it is stuck with
高鐘聲 due to the node representing "鐘聲" is still fixed.
Fixes#54
Soon notarization will be required for Developer ID apps. This change allows
the Installer to run in two modes. The "dev mode" still builds the IME as
the prerequisite of the Installer and places the IME app bundle inside the
Installer's resources folder. That has been so since the beginning of this
project, and this continues to allow IME developers to test the input method.
On the other hand, if "McBopomofo-r$rev.zip" is placed in the NotarizedArchives
folder and McBopomofo is not built as a dependency of the Installer and the
app bundle is not copied to the resources folder, the Installer then can be
built as a notarizable app (otherwise Xcode wouldn't even let you submit it
for notarization).
To build the distributable Installer, notarize the IME app first, then zip the
app as McBopomofo-r$rev.zip and place that to the NotarizedArchives folder
under Source/Installer. Then build and submit the Installer for notarization.
This is in line with Apple's guideline in
https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow
("If you distribute your software via a custom third-party installer, you need
two rounds of notarization.")
We don't expect that we make new Installers often enough, and therefore we
don't intend to automate this process via scripting.
Recent versions of Chrome started to rely on whether composing buffer
gets updated after an arrow key event to determine whether to dismiss
(force commit) the composing buffer and handle the arrow key event for
the omnibox URL suggestions.
When Caps Lock is on and when the character code is not printable, we
should simply reject handling such character instead of absorbing it and
inserting the character to the client buffer--not all apps handle those
insertions.
Using numerous NSLog's led to the discovery that when McBopofomo lost
function (as described in #86), -setValue:forTag:client: was often called
not just on the context of the foreground app, but also on the contexts
of the background apps. This led to the theory that calling keyboard
layout override in that method (not a documented way of doing things
anyways) might corrupt the input method context. That we swapped out
language model and the builder when the method got called didn't help.
In this commit, we put back the keyboard layout override code to where
it belongs -- in -activateServer: -- and we now only swap the language
model and re-create the builder if the input method really changes (e.g.
from Bopomofo to Plain Bopomofo, or vice versa).
Similar defensive coding is also used in the function key handler in the
-handleEvent:client: method.
-tableView:objectValueForTableColumn:row: may call -layoutCandidateView,
which in turn may force the table view to reload; the layout code
should only run after all cell values are provided for to break this
potential cycle.
This is caused by a missing method. Our implementation for
-[NSObject(IMKServerInput) inputText🔑modifiers:client:] was changed
to handleEvent: in 0.9.5.
Interestingly, calling -inputText🔑modifiers:client: somehow worked
when we linked against OS X 10.7 SDK (that was the SDK the 0.9.5
distribution used). This is no longer true with OS X 10.8 SDK.
Also fix two subtle issues:
1. Enter (not Return) key now works in candidate list
2. Cursor index should be compared against builder's length, *not*
composed string's length, because the former is counted in
code point but the latter in UTF-16 units. The composed string's
length might therefore be longer if the string contains
codepoints > U+FFFF, which would cause the cursor mechanism to
be off.
This commit:
* Creates a new top-level Xcode project file
* Renames remaining Lettuce (the original codename) uses to McBopomofo
* Renames English.lproj (the old style locale name) to en.lproj
zonble
ovadmin
Lukhnos Liu
Mengjuei Hsieh
Mengjuei
Peter Dave Hello
leafy7382