Page 2 of 4   « previous page   next page »

JDJ: When SWT started did you think about using the AWT model, which is essentially a native toolkit but with a wrapper delegating to the peer? If SWT had extended AWT, then widget interoperability, not to mention karma in the Java community, might have been better.

Steve: For starters AWT is free-threaded. That can't be changed because it's built into the toolkit. Also, there are a number of other technical issues with AWT that I won't discuss here that made this option unattractive.

I think that most of the strong feeling comes from people who are passionate about their technology and get carried away. For our part, we had different design constraints that led us to a different solution. Being native was a requirement. At the time, although we had quite a good reputation in the Smalltalk community, we were largely unknown in the Java world. Extending or rewriting AWT was not an option; we had built portable native widget toolkits in the past and there was no time to argue over philosophy. Nobody had any idea that Eclipse would take off like it did and that so many people would want to use SWT outside of it. That part is amazing but it goes to show that there is a real demand for native technologies.

JDJ: SWT has no pre-req on AWT at all, even for seemingly trivial classes like Rectangle. This looks like a conscious decision to have SWT be able to run without AWT having to be present. Are there places SWT can run where the AWT packages aren't available?

Steve: SWT runs on QNX Photon where AWT does not exist.

JDJ: Why isn't there an org.eclipse.swt.graphics.Dimension class? It always seems odd when getSize() and getLocation() both return a Point, rather than a Dimension and a Point.

Silenio: That was a design decision made to keep the number of classes down.

Steve: The only way I know for sure to make something small is to start out that way. Libraries always grow and programmers have a habit of referencing every line of code you've ever written. Attempts to strip out classes later are painful and never really work that well. In SWT, what you see is what you get. For example, by design, there are very few inner classes in the implementation of the toolkit (almost none in the widgets or graphics package).

Carolyn: Why fill up the toolkit with classes that don't pull their weight?

JDJ: Constructor style bits have always puzzled me. I used to tell people that they were everything that couldn't be changed after a widget had been constructed, and that this was everything that affected the size of the trim. Therefore things like BORDER, V_SCROLL, and so forth that change the trim/client area ratio are style bits. However, there seem to be places where style bits are used for things that also have a perfectly good getter and setter and can clearly be changed post-construction. What's the story behind style bits and why and when they are and aren't used on an API?

Steve: There are very few features that are style bits that can be changed after the constructor. These were added later when we discovered that some properties that we had originally thought were create-only could be changed later.

Carolyn: Yes, style bits are for "things that can't be changed after construction." Most of them are things you wouldn't ever want to change after construction. But some - like read-only/editable - occasionally needed to be changed later, so setters were added.

Silenio: Style bits are also used to reduce the number of classes. For example, rather than having a Separator class, Label can display static text or be a line separator, depending on the style bit.

JDJ: Why isn't there a native rich text widget in SWT? The StyledText control used by the Java editor in Eclipse is emulated, so it's just a big canvas with a lot of paints on it. This seems to go against the grain of the SWT philosophy of being a thin layer on top of the platform.

Carolyn: We originally used a native RICHEDIT on Windows (i.e., the same control that MS WordPad uses). It didn't fit the requirements for the Eclipse text editor. It makes sense to use a custom text control here for an IDE.

Felipe: Initially we had to go with an emulated rich text widget because Motif didn't have a native option available. Another reason is that rich text widgets can have too many features, making it very hard to define a common API that can be implemented in all platforms. The door is still open for providing a native rich text editor in the future.

JDJ: Several of the last Eclipse releases have seen more things being introduced that seem to be more emulated than native: the UI forms toolkit, user painting in Table and Tree Items, and the rounded gradient tab item titlebar used by Eclipse. Is there a danger of SWT becoming Swingish, where instead of native functionality an SWT program is doing all of its work building the UI in the middle of a paint event?

Steve: People need to ship applications and whatever they decide is fine by me. For example, the UI designers for Eclipse decided they wanted a certain look for Eclipse so they built it. It's not a question of philosophy or Swingishness.

Felipe: Probably not; the customer would really have to over-use the custom draw capabilities of SWT to cause the application to look non-native. It's important that SWT offers these features to allow branding and custom UIs.

Grant: There are contexts where doing some painting is useful and is not necessarily a non-native practice. For instance, custom drawing of table items can be used to draw an item's image to the right of its text, and any programmer using the native Windows table would have to do this anyway. However, the underlying control is still native and maintains its native behavior.

In general, SWT will not provide non-native implementations for natively available widgets. Exceptions to this, such as the CTabFolder, were created for Eclipse branding purposes, but the programmer has a choice. So there is not necessarily a trend toward SWT doing increased painting. Certain widgets have been painted all along.

JDJ: What do you think of things like Nebula and other efforts that seem to be putting more emulated controls into SWT?

Silenio: They are doing great work and making the toolkit richer.

Grant: Nebula is interesting to watch because its mandate is to create controls that do not overlap with existing ones in SWT. It's not surprising that these widgets are emulated since they often implement functionalities that are not available natively. I think it's great that users have a common place to share controls like these that they find useful. This is good for Eclipse and SWT.

JDJ: Swing used to get beat up quite a bit about not looking and behaving like a native widget toolkit. In Java 6.0 they are using platform API calls to determine the correct way to paint their widgets, so presumably the difference to the user between a Swing app and an SWT one will be indistinguishable. If this had been present at the point when SWT was being discussed, do you think history would have taken a different path?

Steve: Possibly, but Swing wasn't up to the task when we needed it. We were shifting gears from Smalltalk to Java and Swing didn't meet our needs. We couldn't have waited until now for widgets that we could use, otherwise, no Eclipse. Also, with all due respect to Java 6.0 and Swing, there is more to being native than drawing that way, assuming of course that you can get it right for every widget. Eclipse and other SWT applications are tightly integrated with the desktop and get all sorts of benefits from this type of integration.

Carolyn: It's not just the painting; it's the "feel" of a control, too. We are constantly getting stuff from the operating system "for free," like native drag-and-drop support, native accessibility, etc.

JDJ: Following on from the previous question, if Swing hadn't had problems with size, platform fidelity, and reliability, do you think it would have been adopted by IBM as the widget toolkit for Eclipse?

Steve: That's a funny question. If Swing had met our design goals and requirements, could we have used it? Yes, but at the time, it didn't. If you are really asking whether there is value in native widget toolkits, there is. Things just feel and work right. Desktop settings, painting and drawing, key bindings, animations, fonts, input method editors, third-party tools, accessibility, the list goes on. With SWT, Java is a first class citizen on the desktop.

Page 2 of 4   « previous page   next page »