JarCastingscala-swing (mostly-unsupported)
This is now community maintained by @Sciss and @benhutchison. If you are interested in helping then contact them or @adriaanm.
Adding an sbt dependency
To use scala-swing from sbt, add this to your build.sbt:
libraryDependencies += "org.scala-lang.modules" %% "scala-swing" % "3.0.0"
About scala-swing
This is a UI library that wraps most of Java Swing for Scala in a straightforward manner. The widget class hierarchy loosely resembles that of Java Swing. The main differences are:
- In Java Swing all components are containers per default. This does not make much sense for a number of components, like TextField, CheckBox, RadioButton, and so on. Our guess is that this architecture was chosen because Java lacks multiple inheritance. In scala-swing, components that can have child components extend the Container trait.
- Layout managers and panels are coupled. There is no way to exchange the layout manager of a panel. As a result, the layout constraints for widgets can be typed. (Note that you gain more type-safety and do not loose much flexibility here. Besides being not a common operation, exchanging the layout manager of a panel in Java Swing almost always leads to exchanging the layout constraints for every of the panel's child component. In the end, it is not more work to move all children to a newly created panel.)
- Widget hierarchies are built by adding children to their parent container's
contentscollection. The typical usage style is to create anonymous subclasses of the widgets to customize their properties, and nest children and event reactions. - The scala-swing event system follows a different approach than the underlying Java system. Instead of adding event listeners with a particular interface (such as
java.awt.ActionListener), aReactorinstance announces the interest in receiving events by callinglistenTofor aPublisher. Publishers are also reactors and listen to themselves per default as a convenience. A reactor contains an objectreactionswhich serves as a convenient place to register observers by adding partial functions that pattern match for any event that the observer is interested in. This is shown in the examples section below. - For more details see SIP-8
The library comprises two main packages:
scala.swing: All widget classes and traits.scala.swing.event: The event hierarchy.
Examples
A number of examples can be found in the examples project. A good place to start is [16] scala.swing.examples.UIDemo. This pulls in the all the other examples into a tabbed window.
$ sbt examples/run
Multiple main classes detected, select one to run:
[1] scala.swing.examples.ButtonApp
[2] scala.swing.examples.CelsiusConverter
[3] scala.swing.examples.CelsiusConverter2
[4] scala.swing.examples.ColorChooserDemo
[5] scala.swing.examples.ComboBoxes
[6] scala.swing.examples.CountButton
[7] scala.swing.examples.Dialogs
[8] scala.swing.examples.GridBagDemo
[9] scala.swing.examples.HelloWorld
[10] scala.swing.examples.LabelTest
[11] scala.swing.examples.LinePainting
[12] scala.swing.examples.ListViewDemo
[13] scala.swing.examples.PopupDemo
[14] scala.swing.examples.SwingApp
[15] scala.swing.examples.TableSelection
[16] scala.swing.examples.UIDemo
Enter number:
Frame with a Button
The following example shows how to plug components and containers together and react to a mouse click on a button:
import scala.swing._
new Frame {
title = "Hello world"
contents = new FlowPanel {
contents += new Label("Launch rainbows:")
contents += new Button("Click me") {
reactions += {
case event.ButtonClicked(_) =>
println("All the colours!")
}
}
}
pack()
centerOnScreen()
open()
}
Versions
- The
1.0.xbranch is compiled with JDK 6 and released for Scala 2.11 and 2.11. The 1.0.x releases can be used with both Scala versions on JDK 6 or newer. - The
2.0.xbranch is compiled with JDK 8 and released for Scala 2.11 and 2.12.- When using Scala 2.11, you can use the Scala swing 2.0.x releases on JDK 6 or newer.
- Scala 2.12 requires you to use JDK 8 (that has nothing to do with scala-swing).
- The
2.1.xseries adds support for Scala 2.13, while dropping Scala 2.10. - The
3.0.xseries adds support for Scala 3.0.
The reason to have different major versions is to allow for binary incompatible changes. Also, some java-swing classes were generified in JDK 7 (see SI-3634) and require the scala-swing sources to be adjusted.
Versions now follow classic Scala PVP style with binary compatibility within x.y.* but not x.*.*.
API documentation (Scaladoc)
The API documentation for scala-swing can be found at http://www.scala-lang.org/documentation/api.html.
Current Work
Current changes are being made on the work branch. Last published version is found on the main branch.
Publishing New Versions
We assume that you are working on a fork of remote upstream with remote origin.
- create a new local branch that will never be pushed remotely, e.g.
git checkout -b release-3.0.0#3.0.0-RC2(do not name the branch the same as a tag) - edit
.travis.ymlto reduce the matrix to only the Scala and JDK versions needed to publish the version (publishing JDK is 8) git commit- add a tag, e.g.
git tag -a 'v3.0.0#3.0.0-RC2' -m 'version 3.0.0 for 3.0.0-RC2' - push only the tag, e.g.
git push upstream v3.0.0#3.0.0-RC2. - check CI status at https://travis-ci.com/github/scala/scala-swing. You should see a message
Running ci-release.followed by e.gpublished scala-swing_3.0.0-RC2 to ...going into localsonatype-staging, followed by the Sonatype plugin uploading the artifacts. - Upon success, nudge Seth to release the bundle from Sonatype.
