FrogBlog

I am long-time vim user. For some years I also use a Mac. Last year I discovered the MacVim project. This is a Cocoa based GUI to vim (so far there was only gvim on the Mac, a Carbon based GUI).

The Carbon gvim is not that great so I sticked to the console vim version. But with the new MacVim, I now have a GUI vim that not only looks much better but also has additional features:

• It has a fullscreen mode.
• Vim’s tab feature uses real tabs instead of ASCII-art tabs.
• There is an ODB input manager that adds an “Edit in MacVim” menu entry to all applications (see Edit in SubEthaEdit for the principle).

There are probably other things, but those are the three I really like. With the “Edit in MacVim” feature, I can now easily write my mails from Apple Mail in vim. Unfortunately, the feature does not work for me in Camino.

Apple has a nice overview of thread communication means in their multithreading documentation (for both, Carbon and Carbon). However, I think the documentation is missing another technique that is very simple.

(more…)

I had the following problem on the Mac: in certain circumstances I want to always display a tooltip and change the text of the tooltip as the mouse moves over different objects. So I looked around and I found the Carbon Help Manager Reference.

The functions HMDisplayTag() and HMHideTag() seemed to be exactly what I was looking for. Implementing this was rather straightforward and it worked most of the time. But sometimes it simply stopped working; after some debugging I found out that after the call of HMHideTag(), I did not get any mouse moved events anymore.

So I looked around for other solutions and found the tooltip article on CocoaDev. That one looked really promising. It has two different approaches of implementing your own tooltips with Cocoa. But since they simply display a window with a style that resembles tooltips, I continued looking (after all, if I use Apple’s tooltip API, I am more likely to get a correct look of the tooltips, especially if Apple decides to change the look of tooltips at some point).

But on CocoaDev there is also an article that shows a different approach: it uses the Cocoa NSHelpManager class to do this job.

This code simply uses the showContextHelpForObject:locationHint: function to show the tooltip and the removeContextHelpForObject: to hide the tooltip. Happy to have a found another solution, I tried this and showing the tooltip worked just find. But to my disappointment, I was not able to get rid of the tooltip anymore — the removeContextHelpForObject: did in fact not hide it. I tried several different ways, but with no luck.

So to cut a long story short, I ended up with using HMDisplayTag() again to show the tooltip. And since the HMHideTag() call was the only thing that caused me trouble, I simply replaced it with:

    WindowRef helpTagWindow = GetFrontWindowOfClass(kHelpWindowClass, true);
    if (helpTagWindow)
        HideWindow(helpTagWindow);

As far as I can tell, this works just fine for me. So I will stick to this unless I discover any mayor problems.

When we pre-announced Squish for native Mac OS X testing, maybe half of the people being interested in it, were developing with Carbon. At that time we had Carbon on our todo list, but nothing was implemented yet, since we believed that Cocoa was the more popular toolkit.

It seems that we were wrong. So we decided to give Carbon support a higher priority and I started working on it. The work on it progressed smoothly and after implementing the object model for Carbon (based on the HIObject/HIView classes), I was soon able to record simple mouse clicks. Today I finished the replaying of mouse clicks.

So now, it is possible to record and play back the first tests for Carbon applications. Much is left to do, though (the object model is very basic, recording of other events than mouse clicks, etc.); but still, we reached a point that shows that there are no unsolvable technical obstactles left — what’s left is just to implement the missing features.

One of the nice things Apple did, was to make it easy to mix Carbon and Cocoa into one application. So we don’t need separate wrappers for Carbon and Cocoa; and the tester does not have to specify what toolkit the application uses. The same binary just works for Carbon-only, Cocoa-only and mixed-Carbon-Cocoa applications (it works for both, Carbon-in-Cocoa and Cocoa-in-Carbon).

But now I have to go back to do some hacking, so that you can get your hands on this soon.