Confessions of a Carbon Guy

Recently, I started thinking about writing some small application on Mac OS X. The app will never probably be written, but it did get me thinking about how I would write it these days. I figured if I were really writing something from scratch, I should probably do it in Cocoa. Being Mr. Carbon, this was quite a conceit. And if I was going to write it in Cocoa, I should really probably learn what makes Cocoa tick so I could write an app “the right way”. So I got a new book (my old one was way out of date) and started reading and messing around. (more…)

Could CoreGraphics Be Wrong?

I’ve always held CoreGraphics (Quartz) on Mac OS X in the highest regard. It’s an excellent drawing API. But a while back when I did the canvas implementation for Konfabulator, I noticed what I believe to be an error in their compositing modes. This, along with gdiplus lacking some necessary features, forced me to move to Cairo for our Canvas object.

The bottom line is that if you compare the CG compositing modes (currently only exposed via Safari’s canvas) with those of Cairo you’ll notice some differences. Compare this link on Safari and then on Firefox. There is a known issue with Cairo’s ‘darken’ mode. Ignore that one for now.

Instead, let’s focus on one in particular: destination-atop.

Note that on Safari it yields the same result as destination-over. As far as I can tell, this is wrong. When the circle is drawn, all pixels outside of the circles influence should be cleared. This is what cairo does. Otherwise, what’s the point of the different mode?

This all tells me that Quartz is wrong, which to be honest shocks the hell out of me. If I’m wrong, please let me know and link me to some corroborating evidence.

Being One with the DOM

Over the past couple of weeks, I’ve been doing a lot of work with our Konfabulator DOM. In some ways, we are completely redoing it so we can use it as the basis for everything (finally). I have also been looking at better ways to expose it via JavaScript.

What I continuously learn is that I really didn’t know the DOM spec like I thought I did. There is a lot of subtlety in the language that isn’t quite clear until you finally live the life for yourself. Over the weekend I was trying to get some stuff straight in my head. After working through it and getting my head around how to organize things, I was reading the W3C spec and noticed that it had basically said what I had just realized all along. It’s not super-obvious unless you really know a DOM implementation inside and out and have had to understand the design out of necessity. It’s a bit akin to my experience in karate where you’ll have someone tell you things a million times and then once you do it a zillion times you finally get it and say “my god, they’ve been telling me this all along”. There’s so much about learning that’s about experience and not words.

But of course the good news is that our DOM is much cleaner now and can be used for more things. I still need to figure out if I want to switch to use an Interface idiom ala Mozilla. It would simplify some things, but complicate others. More to think about. If I do go with Interfaces, I’ll probably just rely on C++ and not go so far as to use something like xpcom internally. That seems a bit much. But if I do C++ for now, it should be relatively straightforward to switch later if for some reason a COM-like solution was needed.

By far the trickest part is going to end up being how we expose things via Javascript. I’m not happy with the amount of work we have to do to expose a class. Too much repetitive work. I guess if we did use xpcom it would be a lot simpler since xpconnect does all these things for you. But that is biting off way more than we can afford to chew right now. Phasing is critical to success long term. I do have a decent hybrid solution in mind that can bridge the gap from where we were and a completely generic solution such as xpconnect.

Once our new foundation is in place it’s going to make a huge difference in what we’re able to do and how quickly we can do it. A lot of doors are going to open up when I’m done. It’s going to be pretty cool. If only I could finish!

Carbon: The Undead

I just downloaded the Eclipse SDK to check out a plugin for it, and I noticed it was done in Carbon. That got me thinking about the state of Carbon these days. Last year at WWDC, it was made very clear that Carbon is in a holding pattern now. Maintenance mode.

I can understand why Apple might do this, Cocoa is a full-featured application framework, and the objective-C runtime does allow you do do some pretty interesting things with it. Why have two frameworks when you can focus on one. Also, now that Carbon did its job and got the developers over to X, it can be put out to pasture.

Sadly, I think this is a bad move overall. And not because I put so much hard work into it, but simply because I think it allows you to do some things easier than Cocoa. Arguably more important things.

(more…)

Did I Mention XCode Sucks?

OK, so tonight I’m trying to get some work done. I’ve been annoyed that command double-click doesn’t work, so I figure out code sense isn’t turned on. I turn it on… crash. OK. Restart the app, open the project… crash. Third time’s a charm tho, so I open it again… crash. This is single-handedly the buggiest dev tool I’ve ever used. There was another bug I’m reminded of where I was showing someone how to set command line arguments and I had added a blank argument. Well, every time you went to run the target program, XCode would crash. Surprise! We didn’t realize it was that until I remember we played in there and I turned off the argument (it was checked). Worked fine.

XCode, I hate you. From hell’s heart, I spit at thee!

And now I have to now spend time figuring out what the f*#$ is going on with this piece of crap now. Yay! Time-saver!

UPDATE: The problem I had was related to indexing the project. Recently I tried using indexing again and it all finally seems to be working. Yay! But I still hate it

Custom Window Frame in Carbon

I wrote this example ages ago, but it never saw the light of day. Today I decided to clean it up a bit and put it out there for others to play with. It’s a simple piece of code that shows how simple it is to put up a window with a custom frame that replaces the standard frame you’d see in a Mac OS X Window.

This is written in Carbon, not Cocoa. It’s fairly straightforward in Cocoa as well. I think the same basic principles apply, only there’s more of @ and[] and sometimes $#%!#(.

It uses the HIFramework stuff that’s part of the Apple Developer examples.

Enjoy.

CustomFrame.zip

The Tao of Coding

The sword maker… continuously polishing, honing. So must your coding be if you are to be successful. Sure you can throw stuff together and it might work, but what about later, when you have to change something. Will you remember what you were trying to do with some piece of code? Will you even be able to read it? What happens when a major revision is needed? (more…)

I hate xcode

Simple as that. I hate it. It sucks. The sad part is they really think they have something there. But the only thing they have is a worthless lump of crud. The other day it decided to thrash my system for no apparent reason. Same sources as always, etc. but it took about 10 minutes of thrashing before it stopped. My attempts to watch what was going on in ‘top’ saw memory down to 16MB (I have 2G). After it subsided (and I had tried killing that damn thing and starting over, but it did it again), I was greeted with 1.8 gig of memory again. That’s right, to build my (somewhat small) project, it pretty much ate every living resource on the planet. (more…)