Mac OS X 10.4 (Tiger) and Spell Catcher X

Posted by Pierre Igot in: Macintosh
May 6th, 2005 • 4:52 am

Minor problems with Mac OS X’s Input Menu (the optional menu on the right-hand side of the menu bar that can be made visible through a check box in the “International” preference pane) are nothing new, as many long-time Spell Catcher X users could probably confirm.

Fortunately, such problems are usually temporary and usually follow the installation of Spell Catcher X. Once the “Spell Catcher X” option has been successfully selected in the Input Menu and your machine has been through a log-out/log-in cycle, the Input Menu usually stays on “Spell Catcher X” and things usually work as expected.

There is one outstanding problem in Mac OS X 10.4, however, which can be easily reproduced. All you need to find is some third-party software installer that still uses a “VISE” type of installer application instead of the standard Mac OS X Installer application that’s included with Mac OS X.

For example, Canon’s driver installer for the CP-300 printer is such an installer. If you have Spell Catcher X installed on your machine and “Spell Catcher” selected in the Input Menu, as soon as you double-click on the CP-300 software installer to launch it, you’ll notice that the Input Menu reverts to your underlying keyboard layout (“Canadian French – CSA” in my case).

Once this happens, unfortunately, it becomes difficult to make the Input Menu switch back to “Spell Catcher“, not just when using the VISE installer, but also in other Mac OS X applications. The only reliable fix that I have found is to log out and log back in.

This occurs not just with the Canon CP-300 installer application, but with any third-party installer based on the same installer technology provided by VISE. Fortunately, once the software in question is installed and you log out and log back in, the problem disappears.


4 Responses to “Mac OS X 10.4 (Tiger) and Spell Catcher X”

  1. Evan Gross says:

    Have you taken a look at the new input menu options? You might want to see if “One input source” works better for you.

    Basic behaviours in this area have changed from previous versions of the Mac OS. I think they’re heading in a good direction, but there are subtle differences even between “One input source in all documents” (the closest to the previous default behaviour, and not the default on Tiger!) and how things worked before.

    I just wish it was all clearly documented (even if just for developers) somewhere.

    There are numerous tricky things that the OS has to deal with – Unicode input sources in non-Unicode apps, full keyboard access throws in another wrench, apps open with NO document window at all poses yet another issue, security-sensitive apps or text input fields often need to deactivate input methods – the list goes on.

    The problem is determining when something’s behaving properly (as-designed, at least) or not, at least wrt the way Apple has designed it to behave.

  2. Pierre Igot says:

    I’ve tried using the “Use on input source in all documents” option — even though I don’t really know what it means. But it doesn’t make any difference with respect to this particular problem.

    I am just curious as to why it is those installers based on the VISE engine that happen to trigger this particular problem (which I have reported to Apple, of course).

    I am sure that the whole situation is rather complex, and there are times when I do wonder how anything ever manages to work properly on a modern operating system like Mac OS X. On the other hand, most things do work reasonably well, so I’d really like Apple to put some effort into fixing this particular aspect of things once and for all. It just feels sloppy — and it’s been like this for a long time now… (although things have improved, as you noted).

  3. Evan Gross says:

    OK, I’ve been able to reproduce what you’re seeing, or at least something very similar (if not worse).

    And I can reproduce it with nothing but keyboard layouts, the Character Palette, and the Keyboard Viewer turned on in my input menu.

    It’s definitely triggered by VISE and InstallerMaker authenticating installers. I’m sure it can be triggered by other processes that require you to authenticate and then run owned by root.

    I can’t quite figure out exactly what’s happening, and a 100% reliable set of steps-to-reproduce is proving a bit tricky to find (need that to submit a radar).

    I’m 99.99% certain it’s a 10.4 bug, but to get to 100% I need to find an Apple-branded app that does this same basic thing (I’m sure there is one, or even some sample code I can find that does it).

    I’ve seen various nasty things happen in the process:

    – For a period of time, the com.apple.HIToolbox.#####.plist file that’s in the Preferences/ByHost directory (this contains your input menu configuration and a few other things) gets its ownership & permissions changed to “No access” for the currently logged-in user.
    – While the installer was open and running as root, the OS was constantly making changes to this plist. Launch an app while the installer is open, and sometimes the items in the input menu are wrong, choosing some of them does nothing, and I even saw the items in the input menu spontaneously change to include items that were off while it was being opened! And those items replaced ones that were on.
    – On a couple of occasions, the entire contents of the input menu were blown away – totally – even after a logout and login. Nothing but your default keyboard layout (the one you choose when installing OS X) was left.

    Anyway, it’s bad, real bad. Sure hope it’s not a Jaguar-disappearing-input-menu thing all over again. Panther was really pretty solid in this area.

    Looks like I’ll be living in radar this evening.

  4. Pierre Igot says:

    Launching a VISE-based installer is a 100% reliable way to trigger this problem. Isn’t this enough for Apple? Do we really have to find a way to trigger the problem exclusively with Apple’s own software?

    Your findings about the

    com.apple.HIToolbox.#####.plist

    definitely confirm my impressions. I do occasionally find myself left with only the default keyboard layout in the IM menu — even though the SCX option is checked and should appear in there as well. Typically I then trash the plist file, log out and back in and reconfigure the IM manually in International… But it sure is a pain.

    Again, thanks for exploring this and filing the bug reports.

Leave a Reply

Comments are closed.