Archive for os x

Dvorak keyboard regression fixed in OS X 10.5.7?

Last December Apple introduced the OS X 10.5.6 update. With it a serious regression for users of the Dvorak Simplified keyboard layout. This regression broke many keyboard shortcuts under Carbon based applications. A number of bug reports by different users were raised with Apple and an active thread on Apple’s forum started.

Despite the impact for affected users Apple (typically) never communicated anything else then that they were aware of the issue and working on a fix. They did not bother giving these users, their customers, a timeline in which to expect a fix. Nor did they bother releasing a hot fix to remedy the issue. No these customers had to wait five months till the release of OS X 10.5.7 for the regression to be supposedly fixed.

I say supposedly as I won’t be upgrading to OS X 10.5.7 immediately. I have learned my lesson. I know Apple’s disregard for its customers. I know the time I have spent on finding a workaround and I don’t want to be pulled through something like that again. I depend on my Apple computers to get my work done and I have learned that that dependancy is an unreliable one. I have learned that Apple doesn’t take regressions seriously. Because that’s what this was; a regression. Not some bug introduced in a newly released feature. No they broke something that used to be working and that I was depending on for my day-to-day work and they didn’t take it seriously.

So I leave it up to other Apple users to try out OS X 10.5.7 and to report any regressions they might find. I leave it up to Apple to not take these users seriously. In the mean time I’ll stay on OS X 10.5.6 with my workaround and keep wondering what I’m given Apple my money for.

Leave a Comment

Solved?: OS X 10.5.6 update broke Eclipse shortcuts

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

Comments (7)

Continued 3: OS X 10.5.6 update broke Eclipse shortcuts

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.

Leave a Comment

Continued 2: OS X 10.5.6 update broke Eclipse shortcuts

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:

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!

Leave a Comment

Continued: OS X 10.5.6 update broke Eclipse shortcuts

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.

Comments (1)

OS X 10.5.6 update broke Eclipse shortcuts

This evening I installed the PyDev plugin for Eclipse to write a little Python code. Seemed to go well until I noticed that some of my keyboard shortcuts didn’t work anymore in Eclipse. Most notably copy and paste (CMD-C and CMD-V). As this was working before I figured the PyDev plugin to be the culprit. However, in a version of Eclipse without the PyDev plugin the issue was still present. 

Some Googling turned up a post on StackOverflow titled Eclipse keyboard shortcuts broken in OSX 10.5.6. Turns out that the OS X update to 10.5.6 I did a couple of days ago broke the keyboard short cuts for Eclipse. But only if you’re using Dvorak keyboard layout. Guess what I am using? Right, Dvorak!

I knew I should have waited a little longer with the update. I normally do. Not sure why I didn’t this time. Sincerely hope Apple comes out with a fix quickly.

Leave a Comment

Simple Command Line Date/Time Calculations

Being a contractor I have to sent my customers an invoice every month. With regards to payment terms I generally settle on a pretty standard 30 day credit period. However sometimes the customer and I settle on a slightly different credit period. Regardless of the credit period I always have to think carefully what the final due date will be. It’s nothing complicated, the calculation being a simple modulo operation, but I always have to determine the number of days in a given month in order to use the correct divisor.

Eg. given today’s date, October 8th, 2008, a credit date of 45 days results in a due date of:

(8 + 45) % 31 = 22

November 22nd, 2008. The 31 being the number of days in October.

However I recently found out that the date command under OS X can do this even more easily:

$ date -v +45d
Sat Nov 22 21:11:56 CET 2008

The parameter -v is the adjust parameter. It not only handles days as in the example above, but all the other units of time as well. Simple and convenient.

Leave a Comment

More unhappy Leopard users

More people unhappy with Leopard’s quality. The announcement of Snow Leopard is encouraging were it not for its requirement of an Intel processor. I guess Leopard 10.5, in all its lack of quality, will be the last major release for my iMac G5. :-(

Leave a Comment

Why do I even bother using Apple Mail?

This happens when I archive an IMAP mailbox from Apple Mail as an mbox and then reimport it again under a new account:

Process: Mail [318]
Path: /Applications/Mail.app/Contents/MacOS/Mail
Identifier: com.apple.mail
Version: 3.3 (924)
Build Info: Mail-9240000~1
Code Type: PPC (Native)
Parent Process: launchd [79]

Date/Time: 2008-06-11 21:06:57.158 +0200
OS Version: Mac OS X 10.5.3 (9D34)
Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000010
Crashed Thread: 14

Apple Mail can’t even import what it archived. Madness!

Many years ago I was able to force an incorrectly formatted mbox into a correctly formatted one using ‘formail’. Not sure if the mbox created by Apple Mail was incorrectly formatted, but I gave it a try anyway:

formail -ds <archived.mbox >>fixed_archived.mbox

No luck; Apple Mail still keeps crashing. :-(

Leave a Comment

Giving up on Gmail IMAP and Apple Mail

With my imminent move of house I plan to switch from Internet provider as well as I have hinted at in my blog post New vs. Existing Customers. The downside to such a switch is that I’ll be losing my long held email address in the process. Fortunately Google seems to have a solution to that problem. With Google Apps and their hosted solution for email I can use my own domain name to create an email address that will always be mine and for the time being will be hosted by Google. Should Google ever fall out of grace with me I can always move that email address to another hosted solution or run my own email server again. Google can even fetch the email from my old address while it’s still active. Perfect.

Two years ago when I was still running my own email server, I used an IMAP server for storing my email. This was extremely convenient as I was able to access my email from everywhere. However I grew tired of managing my server and more importantly the noise it made so I threw it out. Ever since I have been using POP3, limiting my email access to my iMac G5. As it is Google Apps (Gmail) supports IMAP. Hence I figured I could get the best of both worlds: a hosted solution and access to my email from everywhere.

Unfortunately things didn’t work out. My primary email client is Apple Mail. It functions relatively well. My prime reason for using it, however, is Spotlight. Spotlight allows me to find everything very, very fast. I can’t imagine working without it anymore. So unless there’s a better email client that has support for Spotlight, Apple Mail it is.

I enabled IMAP in Gmail. Configured Apple Mail to use it and started dragging my email from my old mailboxes of my POP3 account into Gmail’s IMAP mailboxes. Big mistake! After a few hundred emails, sometimes a few thousand, Apple Mail crashes! Repeatedly. I never managed to completely migrate all my email to Gmail using Apple Mail.

Next I tried archiving my mailboxes, importing them into Mozilla Thunderbird and repeat the drag and drop process. Bang! Same thing. Thunderbird crashes. What is it with these email clients? Throw a couple of thousand of email messages at them and they crash. A sad state of affairs making me long to the time I was using Mutt exclusively; the most reliable email client I have ever used.

However the idea of being able to access my email from everywhere using Gmail IMAP was too tempting to give up on. Hence I tried a third possible solution: install my own IMAP server (Dovecot) and migrate all my email from that IMAP server to Gmail’s using imapsync. The nice thing about imapsync is that you can run it repeatedly and it will only transfer the emails that have not been transferred yet. This is how I ran it:

while true
do
imapsync --host1 localhost --user1 <user1> --passfile1 ~/Temp/passfile1.txt \
--authmech1 PLAIN --host2 imap.gmail.com --user2  <user2> --passfile2 \
~/Temp/passfile2.txt --authmech2 LOGIN --ssl2 --fast --delete \
| tee ~/Temp/imapsync_run_`date "+%Y%m%d-%H%M"`.txt
done

This actually worked in transferring all my email to Gmail. Problem solved, right? Not quite.

As many people have already blogged about, Gmail’s IMAP support is non standard in that it treats Gmail labels as mailboxes on IMAP clients. This has the unfortunate side effect of duplicating lots of messages as Gmail’s “All Mail” mailbox always contains all the emails in your Gmail account. Assign a label to a particular email and that email will not only appear in the “All Mail” mailbox, but also in the mailbox specified by the label.

Supposedly Gmail supports unsubscribing from mailboxes. Though that doesn’t work with Apple Mail. Workarounds such as replacing the “[Gmail]/All Mail” mailbox on the file system with a link to /dev/null doesn’t work either. It crashes Apple Mail each time I perform a Spotlight search. Leaving things as they are and put up with the duplicates is not an option either as it makes things really slow. Apple Mail clogs up my bandwidth by constantly trying to sync with Gmail and the wasted hard drive space only means I have to backup even more data.

So after all these efforts I am giving up on Gmail IMAP and Apple Mail. I’ll keep on using Gmail with my own email address, but will be using POP3 to access it. Yes I’ll be missing out on the excellent search facilities offered by Gmail’s web interface. Though I still got Apple Mail’s Spotlight searches that are just as convenient. And yes I won’t be able to access my email from everywhere. Though I wasn’t able to do that for the past two years anyway.

I really wish Apple started focussing on making things more reliable. Apple Mail is not a brand new application; it has been in development for many years. Instead of adding new features such as email stationary, taking notes, RSS feeds, etc, they should focus on the core functionality of the application and make that work. Apple’s announcement of Snow Leopard is encouraging in that regard. I have seen plenty of features in Leopard that I don’t have a need for. I do, however, have a need for the things that I do use to work reliably and consistently. Printing is another example.

Leave a Comment