SYS-CON MEDIA Authors: Jason Bloomberg, Kevin Benedict, David H Deans, RealWire News Distribution, Gilad Parann-Nissany

Related Topics: Java

Java: Article

SWT - A Native Widget Toolkit for Java Part 1 of 2

SWT - A Native Widget Toolkit for Java Part 1 of 2

The Standard Widget Toolkit (SWT) is a Java class library that allows you to create native user interfaces. It's designed to provide efficient, portable access to the underlying facilities of the operating system on which it's implemented. SWT uses native widgets wherever possible, giving an SWT program a native look and feel and a high level of integration with the desktop. In addition, SWT includes a rich set of controls such as tree, table, and tab folder. This article introduces SWT by describing some of the basic concepts and classes.

Hello World: A Simple SWT Program
The easiest way to learn SWT is to study a simple example. The following code shows a complete SWT program that creates and displays a new window on the desktop with "Hello World" in the title bar. Figure 1 shows the result of running this program on Windows XP.

1 import org.eclipse.swt.*;
2 import org.eclipse.swt.graphics.*;
3 import org.eclipse.swt.widgets.*;

4 public class HelloWorld {
5 public static void main(String[] args){
6 Display display = new Display();
7 Shell shell = new Shell(display);
8 shell.setText("Hello World");
9 shell.setSize(200,100);
10 shell.open ();
11 while (!shell.isDisposed()) {
12 if (!display.readAndDispatch())
13 display.sleep ();
14 }
15 display.dispose ();
16 }
17 }

Lines 1-3: SWT is divided into a number of packages, each modeling a different area of the user interface. All packages begin with the prefix org.eclipse.swt. The package org.eclipse.swt itself contains classes used by every package in SWT, such as constants and exceptions, while org.eclipse.swt.widgets contains only the widget classes. We didn't actually need to import org.eclipse.swt itself or org.eclipse.swt.graphics in this example because we didn't use any classes from these packages. However, any significant SWT program will use these three packages and this is a good place to introduce them.

Line 6: Every SWT program must create a Display. Typically, the first line of an SWT program creates a display, which SWT uses to establish the connection with the underlying platform window system. The class Display is very important in SWT. For readers familiar with the X Windows system, an SWT Display is equivalent to an X Windows Display.

Lines 7-9: These lines create a shell, and set the title and the size. Top-level windows are represented by the class Shell and are created on a Display. It's not necessary to set either the title or the size of a shell when it's created. A shell can have an empty title and the window system will assign the initial position and size using the standard algorithm of the desktop.

Line 10: A shell is invisible when it's created. The method open() makes the shell visible, brings it to the front on the desktop, and sets user input so when keys are typed, they go to the shell.

Lines 11-14: Like most modern window systems, SWT supports an event-driven user interface. This requires an explicit event loop that repeatedly reads and dispatches the next user interface event from the operating system. When there are no more events to dispatch, the program goes to sleep waiting for the next event, yielding the CPU to other programs on the desktop. The loop terminates when the programmer decides that the program has ended, typically when the application's main window, in our case the shell, closes. It's up to the application programmer to decide the exit condition for the event loop, as only he or she knows when the program is finished.

Line 15: This line disposes the Display. Strictly speaking, it's not necessary to dispose the Display as long as the program exits to the operating system. In all modern operating systems and on every platform SWT supports, exiting to the operating system releases any resources that were acquired by the process, including the resources acquired by SWT through the Display. So why include this line in the sample program? Not only is it good form to dispose of resources that you acquire, it can help you find places where you are not explicitly disposing resources, especially when using third-party or operating system-level tools that look for leaks.

As long as the window remains open, the event loop keeps Java alive and the SWT program keeps running.

Widgets: Shells and Controls
A Control is a user-interface element that's contained in a shell. Controls are common in all user interfaces. Buttons, labels, trees, and tables are all controls and users are familiar with these from other programs on the desktop.

Taking a bottom-up view of the world, every control has a parent and this parent can be another control, called a Composite. Shell is a subclass of Composite, so shells can have children. The parent of a shell is the display or another shell. Stated another way, this time from the top down, a display contains a list of top-level shells, where each shell is the root of a tree containing subtrees composed of composites and controls. Composites contain other composites, allowing the tree to have an arbitrary depth. When the child of a shell is another shell, the child is commonly called a dialog shell. A dialog shell floats on top of its parent shell.

It's important to understand the difference between the runtime and inheritance hierarchy of controls. The hierarchies constructed at runtime are containment hierarchies. A Shell is not a subclass of Display, but a display can contain a list of shells. Figure 2 shows the inheritance hierarchy of Display, Shell, Button, and Group, along with the containment hierarchy that's built at runtime from instances of these classes.

The concept of a containment hierarchy is an important one in SWT, so much so that it's reflected in the constructor of almost every object.

Controls are created using a constructor that takes the parent and a style. Styles are bit values used to represent operating system features that are create-only, such as multi- or single-line text edit capability, scroll bars, or borders. Because these operating-system features cannot be changed after creation, the style of a control cannot be altered after instantiation. Style bits provide a compact and efficient method of describing the create-only properties of a control. An alternative implementation would be a large number of constructors in each class containing an arbitrary list of boolean parameters, each parameter in an arbitrary order.

As expected, you can combine styles by using a bitwise-or operation. All styles are defined as constants in the class org.eclipse.swt.SWT. For example, the following code fragment creates a multiline text control that has a border and horizontal and vertical scroll bars:

new Text(composite, SWT.MULTI |
SWT.V_SCROLL | SWT.H_SCROLL |
SWT.BORDER);

To use the default style of a control, the style value SWT.NONE is specified in the constructor. The list of the style constants that correspond to each control is described in the documentation for the control.

A list of the basic SWT controls is shown in Table 1.

Events
So far we've described how to create controls and set various properties, configuring them either in the constructor or through methods that are public APIs. These are all operations performed on a control by the programmer. However, controls are also visual user-interface elements. What happens when the user presses a button or selects an item from a list?

We have already described the display and its role in the implementation of the event loop, reading and dispatching events from the operating system. In fact, without an event loop, an SWT program will terminate and return to the operating system when main() terminates. The event loop plays a critical role interacting with the user. Events are generated by the user, dispatched by the event loop, and application code is invoked in response. Application code registers interest in events by adding an event listener.

A final word about events: they are synchronous (note: don't confuse this term with the Java keyword "synchronized"). This means that your code will never be interrupted to handle an event. Events are only delivered when you call an SWT method. In the case of the event loop, calling readAndDispatch() allows any events that the user has generated to be delivered to your program. If you don't call readAndDispatch(), you'll never see events from the user; your program will appear hung, and the user will eventually kill it.

Listeners: Typed and Untyped
SWT has two ways to listen for events: typed and untyped.

A typed listener is exactly the same as a JavaBean listener. Typed listeners and their events are found in the package org.eclipse.swt.events. For example, to listen for a selection event in a push button, application code uses addSelectionListener(SelectionListener listener). When the user selects the button, widgetSelected(SelectionEvent event) is called from the event loop. SelectionListener is an interface. If there's more than one method defined in the listener interface, an adapter class exists that provides default no-op implementations of the listener methods. This means that you could use a SelectionAdapter to determine when a button has been selected instead of a SelectionListener. Listing 1 adds two typed listeners to a button, listening for selection and a change in focus, respectively.

Untyped listeners provide a generic, low-level mechanism to listen for any event. There are only two classes involved: a single generic interface called Listener and a single event class called Event. These two classes are found in org.eclipse.swt.widgets. Instead of following the JavaBeans pattern that requires a specific method to add each kind of listener, untyped listeners are added using only one method, addListener (int type, Listener listener). The type argument specifies the event you are interested in receiving. Type arguments are constants in the class SWT and are mixed case by convention. For example, SWT.Selection is an event type constant. All other constants in SWT are uppercase.

The Listener interface has a single method, handleEvent(Event event), that's called when the event occurs. One possible way to listen for untyped events is to implement a single listener and use the event argument to determine the type of event that occurred (see Listing 2).

The trade-off between the two listener models is one of speed and space. Using untyped listeners, it's possible to minimize the number of classes and methods used to listen for events.

As well as adding listeners, it's also possible to remove them, but this is generally unnecessary. Listeners are garbage-collected when a control is disposed, providing there are no other references to the listener in the application program.

Disposing Controls
An SWT control is explicitly disposed when it's no longer required. Sometimes the dispose operation is initiated by the user. For example, the user may click on the close box of a shell. More often, a control is no longer required by the programmer and can be given back to the operating system. Controls are disposed using the dispose() method.

When the dispose() method is called, the underlying window system resources are released, giving memory and other operating system resources, such as handles, back to the operating system. When the root of a control hierarchy is disposed, the children are automatically disposed. Therefore, disposing a shell disposes the children. Similarly, disposing the display, disposes all the shells that were created on the display.

When a control is disposed, either explicitly from dispose() or implicitly when an ancestor is disposed, a SWT.Dispose event is sent. The dispose event is a good place to dispose graphics resources that you have created for that control. If you try to access a control that has been disposed, the operating system won't crash. Instead, SWT will raise an exception because it's a programming error to access a disposed control.

If you never dispose a control, but instead hide it or never make it visible, eventually the operating system will run out of resources. In practice, it's hard to write code that does this by accident. For one thing, programmers generally don't lose track of their controls because they require them to present information to the user. Because controls are usually visible, it's obvious when there are too many on the screen.

Positioning and Sizing Controls
Each control is sized and positioned relative to its parent using the methods setLocation(int x, int y), setSize(int width, int height), and setBounds(int x, int y, int width, int height). The following code fragment positions and sizes three different controls:

control1.setLocation(12,23);
control2.setSize(100,100);
control3.setBounds(10,10,200,100);

Sizing and positioning of a control always refers to the entire control, not just the contents. For example, the size and position of a shell includes the window trim and the menu bar. The rectangle that contains the entire control is called the bounds of the control.

The client area of a control is the smaller rectangle within the bounds that the control uses to show its contents. For example, the client area of a text widget is the area where the lines of text are drawn, not including the scroll bars or borders. Child controls are always positioned relative to the client area of the parent, not its bounds. The client area of a control is never explicitly resized or positioned through API. Rather, setting the bounds of a control implicitly sets the client area. Figure 3 shows the bounds and client area of a text control.

Controls can compute their preferred size using the method computeSize(int wHint, int hHint). This method doesn't actually set the size of a control but rather returns a size that's a good default for the control. When the constant SWT.DEFAULT is used for both the width and height hint arguments, the control computes the smallest size necessary to completely show its contents. When a width or height value is used to compute the preferred size instead of the constant SWT.DEFAULT, the control computes its smallest size based on the hint arguments. For example, specifying a width of 100 and height of SWT.DEFAULT when computing the preferred size of a label that wraps is equivalent to asking the question: "If the label were to be resized to be 100 pixels wide, how tall would the label need to be to show the contents, wrapping lines of text as necessary?"

Use the pack() method of a control and set its bounds to the preferred size. Using pack() is equivalent to computing the preferred size and then using the result to set the size of the control.

As we've seen, the preferred size of a control depends on its contents. The preferred size can be queried from a control and used to position it within its parent. Writing code to explicitly size and position each control can be quite tedious and error prone. In addition, this code must almost always run when the parent is resized, so that the children will remain visible as the user resizes the window. SWT provides layout classes to compute the size of the controls and automate positioning of children when the parent is resized.

Layouts and Layout Data
Layouts are found in the package org.eclipse.swt.layout. Layouts are used to encode a positioning algorithm that's applied to the children of a composite whenever it's resized. The method setLayout(Layout layout) is used to set a layout into a composite. The details of the algorithm and API used to configure a layout are specific to each individual layout. Layout strategies are usually quite different and are built around different concepts, causing each layout to have a unique API. By convention, layout classes end with the suffix "Layout".

Some layouts allow each child to supply data that's specific to the positioning of the child, in addition to the preferred size, giving finer control over positioning and sizing. This is done using the method setLayoutData(Object layoutData) on each control. Layout data and its API are very specific to the layout used by the composite. For maximum flexibility, layout data can be of any type but must match the type that is expected by the layout class. By convention, layout data classes end with the suffix "Data".

It's important to note that layouts are set on the parent while layout data is set on the children.

Two of the simplest layouts are FillLayout and RowLayout. More advanced positioning can be achieved using GridLayout and FormLayout. These last two layouts are more complicated but offer increased flexibility. The following section provides a quick overview of these four layout algorithms. In some situations it may be necessary to provide a customized layout algorithm, which can be achieved by subclassing the abstract class org.eclipse.swt.widgets.Layout.

FillLayout
FillLayout is intended to position a single child so that the child fills up all the available client area of a composite. FillLayout has no corresponding layout data. Figure 4 shows a shell using FillLayout with a single text control. The text control occupies all the available space in the shell. Currently, FillLayout provides no margins or spacing between controls.

If more than one control is added, the space is divided evenly between each of the controls, either vertically or horizontally. Figure 5 shows a horizontal FillLayout in a shell with three controls where the size of each is the height of the shell's client area and each control takes up one-third of the width.

In practice, you typically don't add more than one child to a FillLayout because it's not really intended to be used this way. Instead, you might use a RowLayout.

RowLayout
RowLayout lays out controls in a single row, either horizontally or vertically. Details such as wrapping of controls, margins, and the spacing between controls can be configured.

RowLayout has a corresponding layout data that's rarely used, called RowData. Normally, RowLayout uses SWT.DEFAULT when calling computeSize() to get the preferred size of a control. This happens when no RowData is provided for the control. When RowData is provided, it's used to specify values in place of SWT.DEFAULT, allowing you to explicitly set the size of a control within a RowLayout.

Unlike FillLayout, RowLayout wraps controls by default. Figure 6 show a RowLayout that has three controls on it. Although the label and button fit on the same line, the progress bar is placed beneath them because the shell has been resized so there's not enough space to show all three controls on the same row.

RowLayout is more flexible than FillLayout and is generally used to lay out rows of buttons. In practice, most windows are a lot more complicated and require more flexible layout algorithms such as GridLayout.

GridLayout
GridLayout divides a composite into a grid of rectangular cells. The number of columns is critical and determines the final number of rows. This depends on the number of children in the composite. By default, controls are placed into cells in the order they are created. As each child control is created, it's placed in the next available column, which, depending on the number of columns and the span of the control, may be on a new row. By default each control occupies one column.

GridLayout has corresponding layout data, called GridData, that's almost always used by the programmer. Using a GridData, the programmer can control the number of columns to be spanned by a control, the anchoring, the alignment against the edges of the cell, and the width and height values to be passed to computeSize().

Figure 7 shows a GridLayout shell with two columns and three children that are two group boxes and a scale. The group boxes occupy the first and second columns, while the scale occupies both columns on the next line. The scale uses a GridData with a horizontal spanning of two, so the cell it will occupy will include both columns. To force the scale to fill the entire area of the cell, a horizontal fill property was also specified.

The "Gender" group box uses GridLayout with one column to place its two radio button children on separate lines. The "Likes" group box is using a GridLayout with two equal width columns. Its first two check buttons are placed in columns one and two on the first row, and the next two are placed on the second row. Because GridLayout's "makeColumnsEqualWidth" property is true, this makes "Music" and "Art" have the same width as the two wider buttons.

Using GridLayout, it's possible to construct sophisticated user interfaces and achieve just about any positioning and sizing requirement. Many user interfaces, especially those found in dialogs, are inherently grid-based, making GridLayout a good choice. For user interfaces that are not grid-based, FormLayout can be used.

FormLayout
A FormLayout allows you to specify the position of a control in terms of its edges. Edges of a control are attached to a position in the parent. This can be an absolute position, a fraction, or a percentage of the width or height of the parent. Edges can also be attached to the edge of another control, giving FormLayout maximum flexibility.

The corresponding layout data class FormData is almost always used by the programmer. Each FormData has fields that represent the top, left, right, and bottom edges of the control. Each field is an instance of a FormAttachment, which specifies the attachment to use for that edge.

The constructor FormAttachment(int numerator, int denominator, int offset) creates a new form attachment that's used to attach the edge of a control to a position in its parent. In Figure 8, the right edge of the list box is assigned the attachment new FormAttachment(4,5,3), attaching it to be 4/5 of the width of the parent plus an extra 3 pixels. Instead of fractions, percentages can be specified.

The constructor FormAttachment(Control control, int offset) creates a new form attachment that's used to attach the edge of a control to the edge of a sibling. In Figure 8, the combo box attaches its left edge to be 5 pixels from the right edge of the slider using the attachment FormAttachment(slider,5). By default, the opposite edge of a sibling is attached, although an alignment value can be provided to allow attachment to another edge. Under rare circumstances, it might make sense to attach the left edge of a control to the center or left edge of a sibling, potentially causing one control to be positioned on top of another.

Figure 8 shows a shell at its preferred size, while Figure 9 shows the same window resized. As the shell resizes, the controls are repositioned appropriately. The size of the list is automatically increased because of its attachments. The left, bottom, and right edges were expressed in terms of the parent, and the size of the parent has been increased. The slider and combo remain at their original positions. The combo, although attached to the slider, remains at the same location because the scale did not move.

As you can imagine, FormLayout is probably the most flexible layout of all. While it's possible to get almost any positioning imaginable using FormLayout, some user interfaces are more naturally expressed using the other layouts. Most SWT user interfaces are built from a combination of forms and grid layouts.

Forcing a Layout
When a composite is resized, its layout will automatically position and size the children based on the new size of the composite. There are times when the information that was used to calculate the position or size of a control can change without the layout being informed. For example, changing the text of a label will alter its preferred size. When this happens, the positioning and sizing calculations of the layout are no longer valid and children need to be repositioned even though the size of the parent has not changed. To force a layout to recalculate the position and size of its controls without resizing the composite, the layout() method is used.

Conclusion
This article has introduced some of the basic principles behind SWT and shows how to create simple windows and controls. One of the design goals of SWT was to create a UI toolkit that has a high level of integration with the operating system. This is achieved by using native widgets and operating system resources. SWT has been ported to a number of different operating systems, giving it wide coverage on the desktop. Part 2 of this article will show how to use the graphics capabilities of SWT, as well as menus, tab folders, trees, and tables.

Resources

  • Eclipse project home page allows you to download Eclipse, including swt.jar, swtsrc.zip, and the SWT shared library: www.eclipse.org
  • The SWT home page contains lots of code samples and on-line documentation: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/ platform-swt-home/dev.html
  • Contains articles describing SWT, written by members of the SWT team: www.eclipse.org/articles/index.html
  • PDF documentation for the Eclipse project including SWT: www.eclipse.org/documentation/pdf/ org.eclipse.platform.doc.isv.pdf
  • Contains useful links for SWT including how to run it on a Pocket PC, a list of frequently asked questions, and how to use SWT with native Active-X integration: http://eclipsewiki.swiki.net/2
  • Gallery that shows many examples of SWT applications running on different operating systems and desktops: http://gallery.livemedia.com.au/

    SIDEBAR

    Obtaining SWT
    SWT was created as part of the IBM-led Eclipse open-source project whose members include Borland, Rational Software, RedHat, and TogetherSoft. Eclipse is an IDE that's implemented using SWT and is available at www.eclipse.org. On each platform, native widgets are used wherever possible. When a widget is not available, SWT provides an API-compatible emulated control.

    As well as the swt.jar that contains the Java code required to run SWT, there's also a shared library that allows SWT to make operating system calls. The name of the library varies between operating systems, and on Windows is named swt-xxx-nnnn.dll, where xxx is the operating system and nnnn is a version number. When you use the Java command to run a program that uses SWT, you need to specify the location of the shared library. Assuming that you've just installed the Eclipse 2.0.1 to run a class HelloWorld contained in helloworld.jar on Windows, the Java command would be:

    -classpath"helloworld.jar";C:
    \ECLIPSE\eclipse\plugins\
    org.eclipse.swt.win32_2.0.1\ws\win32\swt.jar
    Djava.library.path=C:\ECLIPSE\eclipse\plugins\
    org.eclipse.swt.win32_2.0.1\os\win32\x86
    HelloWorld

    The directory used in the VM argument is the one that contains the file swt-win32-2049.dll, although the exact name and location of the library varies between Eclipse versions and operating systems.

  • More Stories By Joe Winchester

    Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

    Comments (32) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Mark M 07/19/03 07:57:00 AM EDT

    I didn't realize what Swing was missing until I discovered SWT. I always thought I just had to put up with a slow, not-quite-native-look-and-feeling app to use the otherwise excellent Java platform.

    SWT fixes this problem, potentially giving Java the edge over other client platforms. Why use .NET when it won't run on a Mac? Why use C++ when you have to do your own garbage collection and deal with such a complex language?

    But SWT is far from perfect. If you want an MDI app, or a bold list item, or a button with text AND an image, you're out of luck. Plus there aren't any large, robust SWT apps out there yet (Eclipse doesn't really count because IBM had the opportunity to tailor SWT to its requirements), so plenty of managers will see it as 'bleeding edge' and stay away. However, once SWT has a suitably rich set of features and a critical mass of developers, buckle up because it will really take off.

    On a related point, Eclipse is one of the best Java applications I've seen. Fast, robust, feature-packed and flexible. Very Impressive.

    Mark

    Cenray. G 05/14/03 01:15:00 AM EDT

    Hai all,
    Could you please give me a sample code for SashForm example, where i had two panes(leftpane,rightpane) from clicking on a button in left pane i want to show another composite in the rightpane dynamically(Dynamically update the content in the rightpane). The GUI interface i need looks like the eclipse's Run... window

    Regards,
    Cenray

    scarlet 05/08/03 02:57:00 AM EDT

    SWT is great, it's native and many want just THAT. I guess S.Bureau is aging and too old to learn a new API after having learned Swing ;-)

    On my part I'm developping a plugin for both Swing and SWT- I'll write a field report about the advantages/disadvantes of both.

    Swapnonil Mukherjee 05/07/03 01:30:00 PM EDT

    Well Said,

    You are correct. Sun knows a shit about GUI design.

    But you know something, Sun is extremely good at writing APIs and that's why personally I feel that the Swing API is much better, more understandable and more extensible and customizable than SWT's API. Furthermore L&F like Alloy and XP L&F have given Swing a chance to survive for a few years more.
    BUT IMHO, SWT IS THE FUTURE, and may well dominate GUI development in Java, subject to the following conditions.

    1.IBM does not ditch it.
    2.SWT needs people like David Geary, Eckstein who wrote really authoritative books on Swing, after which the intricacies of Swing became transparent to lesser mortals like me.

    3.IBM improves SWT continuously for ex the MDI support request that we read above.
    4.Companies like Oracle, Bea, SAP i.e. so called big names develop their next gen apps with it.

    05/05/03 07:55:00 AM EDT

    Have you actually looked at SWT? It's well designed. It's what AWT should have been but wasn't because Sun can't write software, especially GUI software.

    anonymous 05/02/03 04:53:00 PM EDT

    [Excellent software co-developed by IBM: www.eclipse.org. I am amazed by Eclipse 2.1. They also developed VisualAge for Smalltalk. Excellent. I tried NetBeans, but have ditched it. ]

    You must be smoking something.
    I have yet to see good software from IBM especially UI based.
    All their UIs suck big time, just look at Lotus Notes for instance, and you understand why Microsoft is a distant leader in the Office.

    [I have worked for IBM, and also know about bad software they have written.]

    Now I know why you have such a low standard for "good software".

    IBM only wants to screw SUN and hopes to sell consulting services to implement solutions with their "good software". So good that only they can understand their twisted proprietary design.

    Giriraj 05/01/03 10:26:00 AM EDT

    I'm trying to listen for key events inside a JInternalFrame.
    The following code runs fine sometimes. But very ofetn it gets lost, means,
    the dispatchEvent() code is not executed. Why is it happening? when it stops
    working i run the application twice/thrice and it starts running again. But,
    it disappears suddenly. Whats the reason? Do i need to do something else?
    Please reply me soon regarding this strange problem.

    KeyboardFocusManager.getCurrentKeyboardFocusManager()
    .addKeyEventDispatcher(new KeyEventDispatcher() {
    public boolean dispatchKeyEvent(KeyEvent e) {
    if (e.getID() == KeyEvent.KEY_RELEASED) { takeKeyReleasedAction(e);
    }

    boolean discardEvent = false;
    return discardEvent;
    }
    });

    What the best forum except java(sun's) forum to pose this problem except here?

    Giriraj 05/01/03 03:37:00 AM EDT

    Thanks Joe. I have done that. Hope to
    hear from the SWT team soon about any
    solution. Good Luck!!

    Joe Winchester 04/30/03 04:26:00 AM EDT

    There is a feature request for MDI. Go to https://bugs.eclipse.org/bugs/ and search for PR number 29891. You can add yourself as a cc to this so you get notified of updates, and also add your comments and you can vote for the PR as well.
    Joe

    Giriraj 04/30/03 03:24:00 AM EDT

    hi there!
    Well i developed application for my company in eclipse SWT and i found it
    really fast and easy. Its outstanding
    java development. Well, the point where
    i got stuck was MDI things. That made me
    rollback for the time being to swing.
    But i am still actively looking for
    some solution to this need. Any
    comments?

    Kevin 04/29/03 04:40:00 AM EDT

    First of all, in case ya'll who don't think IBM develops good stuff, ya'll need to check the polls. Eclipse is beating the crap out of every other IDE including the big bad boys of many years prior. It is also kicking butt in the most innovative area. I couldn't agree more. Having used note pade, text edit, Jedit, Kawa, JBuilder, JDeveloper, UltraEdit, and a few others, Eclipse blows them away. For a completely free and amazingly awesome architecture that makes eclipse so expandable for so little money and time, I don't think you could ask for anything else. Actually, you could, which is why over 170 vendors are supporting it and building new apps and plugins on top of it, including C/C++, Cobol, .NET and other things!! When IBM, Oracle, Borland, Rational, and many many others are all on board, there's something to be said.

    As a "attempting" developer of eclipse, I am working on the Equinox project which takes the Eclipse 2.1 core and is adding some very kewl features to it. Namely, reloadable plugins, unloadable plugins, an OSGi implementation to add dynamically locatable services along with plugins, a more "abstract" engine that can be used in any application (thus removes the Java tools, plugin tools, etc so that it is a skin and bones plugin engine you can build your own apps on to), the ability to disable a plugin or have it automatically inactiavte (Freeing up resources) after some unused time, and so forth is all being done.

    So, Eclipse is not only good software, it is perhaps the leading edge of what most software should follow. For those of you using editors like JBuilder and you like JBuilder, I suggest you make sure whoever makes the decisions to pay for those updates you don't let them read about eclipse and all the plugins it has for free. JBuilder does offer a few things that Eclipse isn't quite doing, namely the RAD stuff, but there is already two or three RAD plugins being developed, and the Rational XDE IDE (built on Eclipse) uses graphical UML modeling to turn into code directly (at a premium though).

    For the issue on VB with the RAD (drag/drop of components, connecting them, etc), it can be done with JBuilder as well. Just that it is not as full featured in JBuilder at this time. But this is changing as well, and the great thing is, I can run JBuilder or Eclipse or other java built IDE's on just about any platform. So for me, I love the Mac OS X, so I can develop on that even though my app will run on linux and windows. How bout that crap heh? Not even tied to the release schedule and licensing of the mighty MS!

    Joe Winchester 04/27/03 07:14:00 PM EDT

    Hi Slakeel,

    I read the URL you gave and the stuff you did looks really good - nice work. Your app is very graphics intensive and for that the fully lightweight capabilities of Swing probably worked well for you. For business apps however, where the user is more concerned with data entry and input and things like native behavior of scrolling, drag and drop, etc... I find people tend to be able to use SWT to good effect. For a graphics app like your Swing is strong, however the Java community shouldn't divide itself into SWT versus Swing with quite so much emotion. Each application has a different set of users, the programmers are trying to achieve a different end result, and both widget toolkits have strengths.
    Joe
    P.S. Try not to use words like "waste of time" in your posts, otherwise you'll just turn people off or else just get emotional replies, rather than a reasoned discussion. There does actually exist a ligthweight drawing framework called Draw2D that is based on SWT, that is used by a lot of Eclipse GUI builders, such as IBM WebSphere Studio's WYSIWYG HTML editor and also ( ironically ) its Swing/AWT GUI Builder. If you app is very graphics intensive and dealing with lightweight figures then Draw2D ( or GEF - the Graphical Editor Framework of Eclipse ) might be worth looking at to see if they fit your needs

    shakeel ahmad 04/25/03 11:15:00 PM EDT

    I think people without touching the skys of swing are just dangling around swt. I have developed real GUIs in my projects, and one of my UK based project manager stressed me for swt, I did that as well but let me share my experience with you that not in theory swing is just a classic and swt is not so much mature for real GUIs at this time, its really waste of time. Let me tell you the swing is end for browsers. take my words, because my northstar project really proved that. For example see my public work at following URL. http://members.fortunecity.com/javaclub/jvm.html

    Swopeg 04/24/03 07:09:00 AM EDT

    Sundararaman,

    Try to give answer don't give advice.

    Swopeg

    sundararaman s a 04/24/03 05:43:00 AM EDT

    Why don't you try creating one man?

    sunda

    MorPheus 04/23/03 02:43:00 PM EDT

    Oops! I believe it as a sin of not developing automation tool.Even though there is improvement in the java development after SWT creeps in but I strongly believe that they are not able to compete with microsoft visual studio(in particular visual basic)only because of lack of automation tool.User should not be constrained because of a particular feature not available in a software.

    David McLeod 04/22/03 01:49:00 PM EDT

    He is just an angry man who needs to vent. Have pity on him, but disregard his comments, because he clearly doesn't know what he's talking about. But notice that he has got most of you arguing with him, trying to defend your positions. I think this is all that he really wants...to be noticed in this world; unfortunately, he is only getting "negative attention", but perhaps for him, that is better than no attention at all...

    foo 04/17/03 07:10:00 PM EDT

    Serge:

    I have been programming in java since
    version 0.98

    I agree with you that IBM (generally speaking) simply does not have the ability or aesthetic sense to produce good software.

    However, SWT is a notable exception. SWT
    is so much better than swing that it's
    not even funny.

    Swing looks like shit. It makes my teeth
    ache. Ever seen a file dialog box on
    swing ? Ever seen a native file dialog box on windows ? Ever seen anti-aliased
    fonts on windows on all widgets, user specified skins and preference, user specified window styles, system-wide fonts etc. ? Swing cannot show any of these, swing windows make me vomit.

    Set your windows desktop as follows:

    (display-->control panel->appearance->
    x-large scheme) and then launch a swing
    app and or a SWT app.

    You sheer inability to see how bad swing is is absolutely remarkable.

    And yes, I DO NOT work for IBM, and will not put my email addy here. Unlike you,
    I prefer not getting spammed.

    Serge Bureau 04/15/03 03:49:00 PM EDT

    Again the brave anonymous,

    I will answer even if you do not deserve it.

    VisualAge looks nice on the screen but is a pretty poor environment it's propriatery registry handling was a catastrophy. You could not look at the source with the declaration without exporting. It was one of the worst Java environment.

    Websphere is also pretty week although they improved a little lately they are not close to competition.

    Eclipse is as much from them as Lotus.

    EJB is a poor framework pushed by IBM.

    So an ex-IBM employee and an anonymous person likes IBM software, be my guests.

    04/15/03 08:09:00 AM EDT

    VisualAge for Java was excellent software from IBM.

    Serge, with such a closed mind and such stupid comments, I doubt that you would ever be in a position to fire anyone.

    Geir Ove 04/15/03 04:41:00 AM EDT

    Hello,

    Excellent software co-developed by IBM: www.eclipse.org. I am amazed by Eclipse 2.1. They also developed VisualAge for Smalltalk. Excellent. I tried NetBeans, but have ditched it.

    I have worked for IBM, and also know about bad software they have written.

    But they **have indeed** written some very good software. You generalization makes you look less credible IMHO.

    Geir Ove

    Tom Roche 04/14/03 04:05:00 PM EDT

    Joe: good to see you were able to parse JDJ's unformatting. For those
    who couldn't, I also put instructions for running snippets (both from
    the cmdline and from the workbench) at

    http://eclipsewiki.swiki.net/2583

    Joe Winchester 04/14/03 02:03:00 PM EDT

    Thanks Tom,

    We saw the typo but unfortunately too late in the production cycle to have it fixed. In part 2 which should be in the May issue there should be a correction that includes the correct syntax.

    Joe

    Tom Roche 04/14/03 01:34:00 PM EDT

    http://www.sys-con.com/java/article2a.cfm?id=1947&count=29521&tot=21&pag...
    > -classpath"helloworld.jar";C:\ECLIPSE\eclipse\plugins\
    > org.eclipse.swt.win32_2.0.1\ws\win32\swt.jar
    > Djava.library.path=C:\ECLIPSE\eclipse\plugins\
    > org.eclipse.swt.win32_2.0.1\os\win32\x86 HelloWorld

    I believe two things should be corrected:

    * There needs to be a dash before the "D" giving the library path
    argument. I.e. it should be

    -Djava.library.path=C:\ECLIPSE\eclipse\plugins\org.eclipse.swt.win32_2.0.1\os\win32\x86

    * There should (probably) be a space between the classpath argument
    and its value (though it's possible that using quotes finesses
    this). I.e. I would do

    -classpath "helloworld.jar";C:\ECLIPSE\eclipse\plugins\org.eclipse.swt.win32_2.0.1\ws\win32\swt.jar

    Serge Bureau 04/13/03 09:43:00 AM EDT

    Interresting to have an anonymous opinion, people have a tendency to be braver this way.

    Yes to me the world is black and white, there is the useful and well written software and the rest is useless.

    You talk with no name and have not mentionned me a good software from IBM yet.

    You must be pretty new to software, because you are only using the library that you need from your Java program plus all the SWING libraries are already available on the machine when you installed it.

    I suppose you mean you do not need security, garbage collection, internationalisation, ... I would fire you on the spot.

    04/13/03 08:52:00 AM EDT

    Serge, suppose I don't care about this supposed flexibility, something I will never use. Why should I pay for it? No native app does it so no user expects it.

    Everyone, don't "loose" anymore time arguing with Serge. He's on a one man mission to piss all over IBM and SWT.

    Must be nice to live in a black and white world. The truth is that both Swing and SWT have strengths and weaknesses and that IBM has written both excellent and crappy software, just like Sun and everyone else.

    Serge 04/12/03 12:15:00 PM EDT

    Dear CY,

    I am so happy that there is developper like you, my job seems suddenly much safer.

    Please go on the competition,(JavaPro) and look at the series of articles (around one a month for 5 years) by Clause Duguay about a SWING component per month. Try to do 1% of those component with SWT.

    So read on SWING instead of loosing time on SWT.

    As far as IBM, I still wait an example of a good software !

    CY Ing 04/11/03 03:03:00 PM EDT

    hi Serge, I just dropped by to see your comment. I couldn't help but to say your view on Swing and SWT is so biased and untrue. I am new to SWT but I ran many examples of it. All of them shows great performance and functionality than Swing. It is also unfair to say Swing is worse than SWT, but I'd say a shame on Sun that such a great toolkit is developed by a third-party.

    Your saying about IBM never wrote good software is also untrue. In fact, IBM has sponsored many open source projects and helped some of the full-of-potential projects to grow.

    In my opinion, Swing is a joke. It made a illusion to everyone that Java is so slow that requires higher computing power to run. But SWT reveals that Java is actually not that slow.

    Serge Bureau 04/10/03 05:02:00 PM EDT

    Yes I am the Serge Bureau that had a run at Softlogik when on the Amiga.

    SWT is not having 1% of the capabilities of SWING, and the fact of going to native peers is ridiculous.

    Plus almost nothing is modifiable. As far as speed, it is not faster than SWING at all. I took a quick look because I do not want to waste my time on this, but an article on a magazine about that is too much.

    IBM never wrote a good software, not even in the time of the Amiga, and not now. EJB is another proof. As is WebSphere.

    Look at the design of SWING and tell me this joke of SWT is comparing in any way.

    Joe Winchester 04/10/03 02:54:00 PM EDT

    Hi Serge,

    I'm curious about what part of SWT is primitive and why this hurts ? Do you prefer emulated widgets such as Swing, or is the API that you find primitive, i.e. you prefer the AWT Component>Component peer JavaBeans model ? Are there missing controls or missing functionality that SWT doesn't have that you think is missing ?

    Joe

    BTW - are you the same Serge Bureau of Amiga fame that had a run in with Softlogik a few years back ?

    Serge Bureau 04/10/03 10:09:00 AM EDT

    This toolkit is so primitive that it hurts.

    That Java programmer's even consider it is sickening.

    Ken Walker 04/04/03 11:18:00 AM EST

    You can build a J2ME version of SWT and it will work against CDC or Foundation, a great combination on PocketPC! You can use the J9 VM for any of Win32, PocketPC, Linux to run this.