Standard Widget Toolkit

SWT is a cross-platform GUI library for JVM based desktop applications. The best known SWT-based application is Eclipse. SWT comes with platform-specific jar files. Download them from and add the jar file to your classpath. First, a Display is created which is something like the central place of all GUI-related code. Then a Shell is created which in our example is a top-level window. Then all child controls and listeners are created, including their layout information. Finally, we set the window's size determines by its child controls and open the window. The while -loop processes all GUI related events until the shell is disposed which happens when closing. Before exiting, any claimed GUI resources needs to be freed. For information about contributing to Eclipse Platform in general, see the general CONTRIBUTING page. This repository uses the Git Large File Storage (LFS) extension to host also the precompiled SWT native binaries, which is therefore required unless binaries are compiled locally. When using Git from the CLI follow the Git LFS installation and setup instructions: When using EGit from within Eclipse follow the EGit user guide on GIT LFS Support : Note: Changes to the binary artifacts must not be committed, as the binaries are compiled only in the Eclipse infrastructure. For instructions on building the native binaries of SWT see the section Building native binaries. See the following description for how to contribute a feature or a bug fix to SWT. Information regarding source code management, builds, coding standards, and more can be found under the following link. Also see in the SWT section of the Eclipse FAQ for more background information about SWT. Contributor License Agreement Before your contribution can be accepted by the project, you need to create and electronically sign the Eclipse Foundation Contributor License Agreement (CLA). Contact You can register bugs and feature requests in the GitHub Issue Tracker. Remember that contributions are always welcome! Note: SWT used to track ongoing development and issues in Bugzilla, but we now use GitHub Issues and Discussions. The project concluded with the feasibility demonstration and a report summarizing the results. Given sufficient resources, a follow-up project could convert the demonstrator into a production-ready state.