Page 3 of 4   « previous page   next page »

JDJ: Apart from the previous two, what's the single question you get most tired of being asked about SWT?
Steve: Nothing really stands out. Explaining design decisions like style bits, constructors, and threading can become tiresome. But really, people can't know the answers to these questions. If they have never done any operating system programming and have a Java-centric view of the world, then asking these sorts of questions is quite natural.

How about, "Why did you do SWT? Are you trying to fracture the community?" The answer is "Anything but."

Silenio: Why doesn't SWT use finalization? I'm sick of that one.

JDJ: There was a JavaLobby story recently about some folks who'd managed to get the SWT API to work with Swing classes, and even had screenshots of Eclipse running under Swing. Does this kind of effort a) amaze, b) frighten, or c) bore you?

Steve: None of the above. I think this is really cool. One of the challenges of SWT is developing an API that can run on all sorts of different platforms. If you consider Swing as just another platform, these guys ported to it. I think our position with respect to other technologies is pretty consistent. I don't expect that to change. Interestingly, this port reaffirms many of the API design decisions we've made.

Carolyn: a)

JDJ: The Linux folks seem to complain about print support for SWT. Is this an issue and something being worked on?

Steve: Fixed > 20060717.

Carolyn: Printing support was added to GTK+ with the release of GTK+ 2.10 in July. We added GTK printing to SWT practically the next day, and it went into Eclipse 3.3M1. The main point is that we were waiting on this from GTK.

JDJ: What's the most exciting thing going on in SWT at the moment, both within the committers and development team, and also the larger community with its usage of SWT?

Steve: For me, it's Vista.

Silenio: WPF port, animation API, theme drawing API, Windows port for 64-bit ...

Kevin: The SWT community is fun to work with because they're a very dedicated bunch who really want to contribute. There are an amazing number of bug reports filed and the reporters are always willing to work with the team to provide more information, testing, and the feedback that we need to make SWT better. It takes a significant commitment to become a committer. For example, I have been an Eclipse committer on another project for over three years but despite that, I still need to earn my commit rights fixing problems and learning the SWT code base.

Grant: Not 64-bit XP. Mozilla everywhere?

JDJ: What's in the pipeline for SWT in the future?

Steve: It's too early to tell. We're looking at lots of things. Right now, it's a very interesting time for user interface technologies. Never has this space been so fragmented. We can't even agree on the computer language let alone the platform. On Windows, it's C/C++ for Win32 and C# or VB for .NET. On the Mac, C for Carbon and Objective-C for Cocoa. Linux systems support GTK+ and Qt. Many of the older workstations are still running X/Motif. Then there are the browsers. Do you use XML or AJAX to program them? Flash is a pretty cool technology. What about PHP? If you choose AJAX, what widget library do you use? You can use Dojo, but there's also GWT, J2S, and a dozen more.

One thing is certain: rather than fight technology, we will embrace it and continue to help programmers build and ship products. That's the interesting part.

JDJ: What do you think of efforts to have a declarative way of describing an SWT GUI in something like XML?

Steve: If the world goes declarative, then we will too. One thing I know for sure though, you will always need an API to manipulate widgets.

JDJ: If you had to do SWT all over again, what would you do differently with the benefit of hindsight?

Steve: Not much really. We made a few API mistakes, arguments in the wrong order and that sort of thing, but nothing major stands out. A really good indicator of this is that almost nothing in the toolkit is deprecated. In this world of bloatware and complexity, I'm really proud of what we did in terms of getting the API right and keeping the size of the toolkit down. For example, the class hierarchies for graphics, widgets, the browser, printing, and drag and drop all fit on one slide without using a tiny font. It's amazing considering the functionality that's packed in there.

JDJ: Why are there so few interfaces in SWT? Classes like org.eclipse.swt.widgets.Layout might be a good candidate for an interface rather than an AbstractClass.

Silenio: Interfaces have a big drawback: they can never change. Once an interface ships, nothing can change, otherwise it breaks binary and source compatibility. I believe API always evolves and abstract classes make this evolution easier, without leaving a trail of dead code behind (Interface1, Interface2, etc.).

Carolyn: You have to get an interface exactly right the first time, because you can't change it without breaking binary compatibility. That's why you get silly names like "ISomething2", or, for example, "IDispatchEx"...

JDJ: Why is LayoutData typed to java.lang.Object, whereas a marker interface might help to do things like validate at compile time that the argument was actually valid? Instead, things like Assert and casts have to be done within layouts, which presumably is more expensive for performance and also a less clear API than using typed arguments. For example, instead of layoutData as an attribute on Control, you could have had Layout.setLayoutData(Control,Object) that was overloaded on each implementation, e.g., GridLayout.setLayoutData(Control,GridData).

Silenio: There should be a common class (no interface, see above) for the layout data objects. This would allow some sharing of some common properties. On the other hand, having declared it as an Object does not necessarily mean bad performance, since usually the layout algorithm performs caching and the validation of the objects only happens when the cache is flushed.

JDJ: Likewise for arrays as arguments. Things like setSelection(String[]) or Widget[] getItems() instead of using lists and collections.

Carolyn: I like Arrays . But the correct answer is that collection classes are not always available (or not completely implemented) in CLDC classes. SWT still runs on Java - what, Steve - 1.2? (I know it runs for sure on 1.4.2_06 - I use that all the time.)

Silenio: SWT runs on JDK 1.1 and collections were only introduced in JDK 1.2.

Page 3 of 4   « previous page   next page »