Guido Kollerie

I think I have found a solution to the serious regression with regards to Dvorak keyboard shortcuts in Carbon based applications that Apple introduced with the OS X 10.5.6 update. This weekend I might follow up with a more thorough write up. For now just the solution will have to do as I am short on time.

Unfortunately the solution requires you to have access to an OS X 10.5.5 installation which not everyone might have at their disposal. It basically boils down to replacing the 10.5.6 installation’s /System/Library/Frameworks/Carbon.framework with that of the 10.5.5 version. I haven’t tested it extensively. In fact I have only confirmed that cmd-c and cmd-v finally work again in Eclipse.

The 10.5.6 installation lives in:

/System/Library/Frameworks/Carbon.framework


The 10.5.5 installation is mounted from an external hard drive at:

/Volumes/Bak MacBook/System/Library/Frameworks/Carbon.framework


These are the steps I performed:

$ cd /System/Library/Frameworks
$ sudo cp -Rpv Carbon.framework ~/Temp/
$ sudo rm -rf Carbon.framework
$ sudo cp -Rpv /Volumes/Bak MacBook/System/Library/
Frameworks/Carbon.framework .


BTW the 10.5.6 installation is a PPC one and the 10.5.5 is an Intel one. That doesn’t seem to matter as, as far as I can tell, all the files in the Carbon.framework directory are resource files which are platform independent.

Be careful though. I have barely tested this and hence it might have serious unwanted side effects.

Update:  As it turns out some things do break when reverting to  the 10.5.5 version of the Carbon.framework. For instance pressing ENTER in Finder does not allow you to rename a file or directory anymore. And according to Apple forum user LEgregius it also breaks something in iPhoto. To work around these issues LEgregius has a short shell script that switches between the two versions of Carbon.framework when starting Eclipse. I have adjusted this script slightly to make the switch conditional:


#!/bin/sh
FRMW_DIR=/System/Library/Frameworks
CARBON_FRMW=${FRMW_DIR}/Carbon.framework

if [ -e $CARBON_FRMW -a -e ${CARBON_FRMW}.1055 ]
then
    sudo mv $CARBON_FRMW ${CARBON_FRMW}.1056 &&
    sudo mv ${CARBON_FRMW}.1055 $CARBON_FRMW &&
    echo "Switched Carbon.framework 10.5.6 -> 10.5.5"
fi
open -W /Applications/eclipse/Eclipse.app 
if [ -e $CARBON_FRMW -a -e ${CARBON_FRMW}.1056 ]
then
    sudo mv $CARBON_FRMW ${CARBON_FRMW}.1055 &&
    sudo mv ${CARBON_FRMW}.1056 $CARBON_FRMW &&
    echo "Switched Carbon.framework 10.5.5 -> 10.5.6"
fi


Finally got a response from Apple in response to my bug report. According to Apple:

This is a known issue, which is currently being investigated by engineering.

No hint as to when we can expect a fix though.

Almost two weeks after the release of the OS X 10.5.6 update Apple still hasn’t provided a fix for the serious regression with regards to Dvorak keyboard shortcuts in Carbon based applications. Worse they haven’t even indicated that they’re working on it or provided a timeline for a fix or temporary workaround. I did open a bug report with Apple on https://bugreport.apple.com. However as these bug reports are not public it is impossible for others that have been affected by this bug to subscribe to it. Furthermore it arguably makes it difficult for Apple to track how many people have been affected by this issue. Although the thread 10.5.6 breaks Dvorak keyboard shortcuts in Eclipse on the Apple Support Forums makes it clear this issue is causing problems for many people using just as many different applications.

With Apple not taking their responsibilities I figured I’d give it another try to find a workaround. Problem is that I am no OS X developer and though I do know the basic difference between Carbon and Cocoa applications I know next to nothing on OS X application development. So all I have to go on is my intuition and hints I find on the Web.

With some of the keyboard  shortcuts working (cmd-s) and others not (cmd-c, cmd-v) I still suspect the culprit to be with an incorrect keyboard mapping instead of some logic error in a piece framework code. I my previous post I created a new Dvorak  mapping and installed it. This didn’t solve the problem as it didn’t change any of the mappings specified in the Carbon Framework. At least that’s what I suspect the reason to be.

So is there a way to adjust the mappings in the Carbon Framework? It seems there is. Hinted by references to HIToolbox in the Eclipse bug report on this issue, and a path to this part of the Carbon Framework mentioned on http://wordherd.com/keyboards/ I figured I had to replace the Dvorak mapping in:

/System/Library/Frameworks/Carbon.framework/Frameworks\
/HIToolbox.framework/Resources/English.lproj/Localized.rsrc


Using ResKnife, an open source resource editor, I had a look in Localized.rsrc and did indeed found a Dvorak KCHR resource (with ID 16300). With the form on http://wordherd.com/keyboards/ I created a layout.r using the following settings:

In the resulting layout.r file I changed the type “uchr” to “KCHR” and its ID to 16300. Then I made a backup copy of Localized.rsrc and executed:


gkoller@Kardamom (593) $ /Developer/Tools/Rez -append -useDF -o \
/System/Library/Frameworks/Carbon.framework/Frameworks\
/HIToolbox.framework/Resources/English.lproj/Localized.rsrc \
layout.r


Another look with RezKnife revealed that the old Dvorak mapping had indeed been replaced with the new one. I restarted my computer, fired up Eclipse, and …. *damn* it still did not work.

For all I know my attempts to find a workaround are completely misdirected and naive, but I just had to try as this issue is driving me nuts. Maybe this post might give others a few hints and put them on the right track to find a solution, or more likely prevent them from wasting time on similar futile attempt. However it would be much better for Apple to step in and take their responsibility in fixing this regression!

Tried to find a workaround for the nasty Dvorak keyboard mapping bug introduced by Apple with their 10.5.6 update of OS X. I had the idea that if I could create a keyboard mapping for Dvorak myself, this might ‘trick’ OS X accepting the proper keyboard shortcuts for Carbon based apps. Looking for a tool to create such a mapping I came across the following website:

http://wordherd.com/keyboards/

Using the standard settings it was easy to create a new Dvorak layout, save it as “Dvorak Workaround.keylayout” in my Library/Keyboard Layouts directory, and select it from the Input Menu in the International System Preferences menu. Alas, this did not resolve the problem.

This might have worked if problem was in the Apple default Dvorak keyboard layout itself. However if that was the case keyboard shortcuts would have been messed up in Cocoa based applications as well. It was a long shot to begin with, but I had to try something as it is really impacting my ability to do any programming in Eclipse on my Mac.

It might be due to the holidays or the relatively low number of users impacted by this bug (who uses Dvorak?), but I find Apple slow to respond to this serious regression.