Printing on GTK

For the longest time, printing was not supported in GTK. That's bad. Heck, even Motif applications can print and they've been doing it since the beginning of time. Now, thanks to the magic of cairo, GTK applications can print too and so can SWT ... we just need to write the code.

CAR is off hacking this up right now with SSQ and FH. In fact, something was just printed, but the font is small like fly shit.



Steve

Conspiracies? What rubish!

I've worked in software for a long time. In the early days, I thought that "software was out to get me". Those guys at Microsoft were evil, making API's impossible to use on purpose, just to make my life hard. Technologies were out to kill other technologies and put people out of work. Companies didn't ship features on time because other companies needed them. Not true!

Ok, sometimes this is true, but it's the exception, rather than the rule. I know, because some people think I'm part of a conspiracy and I'm not!

Here are some popular Eclipse ones:

The name "Eclipse" was chosen to offend Sun. That's false. I was there. It was the age of e-everything and someone said "e-clipse". The name stuck.

SWT is out to get Swing. That's false. SWT is native and Swing isn't. If you believe that native is critical, then Java is a non-starter for you without SWT. It's about bringing more people to the Java platform by embracing technology, not starting flame wars.

Eclipse.org is controlled by IBM. Not true. The foundation is completely independent. When it first started, my CVS connection got slower! Seriously, IBM has one vote and no special status in the charter. Go ahead and search it for the string "IBM".

Steve

"I pulled a Billy ..."

Any of you fortunate enough to know Billy Biggs, know that there is only one word to describe him. That word is awesome. He's a fantastic programmer, cares about your problem, knows everything about everything and even better, knows the guys who can get you the answer. However, as you might have already guessed, he has one particular disturbing flaw.

Ever debug something for hours, only to find out that your test case was wrong and it was working all along? Ever write a piece of code, test it, find a bug, change it, test again, change it, and so on, only to find out that some hack of yours elsewhere in the code meant that you were testing nothing? Ever come to the conclusion that all those assumptions that you were making for the past two hours were completely wrong? If this happens to you, then you pulled a "Billy".

The longest Billy on record: 2 days (but not pulled by the man himself).

I asked him if he cared that we call this a Billy and he said, "Naw, I just want to be famous". Well, you are. The legend lives on.

Steve

@deprecated is a lie

API is serious business. If you don't need to build reusable libraries, your life is easy. Refactoring tools will help you grow your code for the future. If you build in-house libraries and have only a few well known clients, your clients will hate you, but you can still make changes. For reusable public libraries such as SWT, nothing can change. Ever.

To really understand this, I think you need to have been burned by it at least once. Fortunately for me, this happened early in my career, in a different language and on a different project. I learned my lesson.

You can tell when API failure occurs. A quick search for @deprecated is all it takes. Some people think nothing of leaving a trail of dead API behind them, @deprecating all the way. "We'll just deprecate that" they say, like it fixes everything.

What's wrong with this thinking? For one, API never goes away. It still needs to be tested, debugged and maintained. It takes up space in memory and on disk. But there is a deeper cost. Clients have invested their time and energy learning your API and now you tell them, "Throw that away and start again, it's better this time".

Here is my rule of thumb: If there is any way, I mean any way, to keep an API going, then I'll do it.

We've done a good job of API in SWT over the years and I'm proud of it. SWT is particularly hard because the underlying platforms are so different. One false step leads to disaster. In SWT terms, this is an API where a native implementation is impossible. If you search the source of SWT 3.2 for @deprecated, you'll find only 39 matches in the entire toolkit. Some of these are duplicates because the Javadoc is copied onto all the different platforms. The actual number is 19.

Someday, I'll talk about a few of the things we do to keep it this way.

Steve

"Eclipse is not crap ..."

The other day, I was out somewhere and a guy found out that I was Mr. SWT and started haranguing me, saying "Eclipse is crap". Usually, I don't bother with this sort of thing. For one thing, who cares? Also, SWT is my baby, not Eclipse. Anyhow, the guy expected me to start bashing him, his company, his product or at least quote a few statistics. Then we could argue over those! Pointless, pointless, pointless.

But then it occurred to me, "Eclipse is not crap ... and I can prove it". Here goes, "SWT is a large pile of Java and C code, build scripts, directories and other random artifacts. It's complicated and runs on five different platforms. I use Eclipse exclusively to develop and maintain it and Eclipse works well. Therefore, it cannot be crap".

Steve

We care ...

One of the things that's great about open source is the interaction that you have with the community. I've worked on both closed and open source systems and let me tell you, open source is just way more fun. There is no substitute for the level of interaction, quick turn around and raw power in working this way. Give me a guy ranting at me over some processed, filtered and predigested bug list any day!

We helped this guy out yesterday with a bizarre problem that didn't happen on my machine. This bug report resembles a blog with people who hate my guts. Interesting, that all we are doing is writing code, solving problems and trying to ship, just like everyone else. But hey, all it takes is one comment like this to make it all worthwhile.

Steve