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.

Update: I’ve since learned new information and decided Quartz is right after all.

iPhone Outlook Sync: Take II

So after my phone stopped syncing with Outlook again, I realized the trigger might have been my re-import of my old tasks. So I’ve redone what I said in my last post and just manually entered the tasks I had. So far, things are behaving. The true test will be one full week of meetings changing, etc.

Update: So far, so good! Things are now syncing fine. I think it was my tasks, but what might also be helping now is iTunes 7.3.2, which I believe has a new sync services bundle. It must, since if I reset my sync history now, the sync service no longer crashes.

Outlook Calendar iPhone Sync Fun

Since I’ve gotten my iPhone (which btw I refer to as the first true 21st century device - yes, it’s that much better than anything I’ve used), I’ve had major problems trying to sync it with Outlook’s calendar. Everything else would sync fine, but the calendar would come over really weird, and once it even got to the phone it wouldn’t sync back and forth properly. On top of that, every appointment that was sent to me via an email seemed to be in GMT, so it was 7 hours earlier than it was supposed to be. This is the story of how I think I’ve finally fixed it.

EDIT: since I first wrote this, I’ve just experience a non-sync again. See my latest post for more info.

(more…)

More DOM Fun

As per my last post, I’ve been working up a storm to redo our Konfabulator DOM. We did in fact end up coming up with a whole new way of exposing our objects into JavaScript. It’s so much nicer than anything we had in the past, though it does involve the use of a custom tool to help us generate the glue. But the end result is absolutely great. We’re able to whip up classes in no time now. Too bad we’re whipping up the same classes we had and not new ones At the same time, I’ve been fixing layering issues in our code. Too much lower level stuff knew about too much higher level stuff. Some people seem to think this is OK. I however do not.

I’ve been finding that as I progress in my coding life, I’ve become more and more of a purist. I think most of my design purity stems from my life at Apple, to be honest. We had to completely re-layer most of our stuff for the transition to Mac OS X (it was part of the whole design). This and many other things have stuck with me as I’ve moved on from there. I like abstractions and the ability to separate pieces of code so that I can mix and match them later (and invariably, the need will arise). I’ve been developing various tenets and axioms as I go which perhaps someday I can compile and put up here.

Bringing the original Konfabulator hair tangle into this new, clean architecture has been a long time coming. But once complete, it can be used for far more than just Widgets in theory. And it can be used in far more scenarios than just embedded inside Yahoo! Widgets. That’s why you design layered and pure from the beginning: flexibility.

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!

Messenger for the Web

So if you haven’t seen recently, Yahoo! now has a version of Messenger that runs in a web browser. I’m actually running it in another tab as I write this. I can’t figure out if this is genius or insanity yet, but I’m leaning towards the latter.

The plus side is simple: server-side history (which I hope works on the client version too), and the ability to IM from anywhere without having to install software. It’s perfect for interweb kiosks, etc.

But damn, it’s a web page and that makes it… oh I don’t know… large. And now, I have a messaging pending, so the tab is displaying the message like a marquee, scrolling across. Annoying. It should just probably change into a different title that indicates there’s a message unread.

The jury’s still out on this one. It definitely will be useful at times, no doubt, but I don’t know if it’s what I want to run 100% of the time.

Badges of Honour

Yes, you can now put a badge on your website pointing to any Widget in the Yahoo! Widget Gallery by going to our Badgers page. You can point to any Widget you want, be it your own or your favorite. Badge away!

(I’ve badged the Flickr Widget over on the right as an example.)

Developer Day!

We’re offering the first ever Yahoo! Widgets Developer Day at our headquarters in Sunnyvale, CA. If you happen to be a Widget developer, we’d love to see you there.

You can get more information on the Widgets Blog.

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…)