Our GUI builder is the result of many twists and turns in our product line mostly due to corporate bureaucracy
hacks and last minute deadlines from our days at Sun. Its also written using Swing which is pretty much a dead
end API that isn’t seeing any maintenence and since FX is even worse off there isn’t much hope for the
The GUI builder is also one of the most controversial parts of our UI. While it has its strengths and simplicities its
UI could do with a facelift and its architecture was designed before tablets existed. It was designed when
Apple just barely surpassed Blackberry sales and had just announced the iPhone 4 (first with Retina display).
With that in mind we decided to rethink the GUI builder from the ground up with a complete from scratch
rewrite. This allows us to keep the existing GUI builder for 100% compatibility for the forseeable future
and add a decent migration path to developers who want to move to the new approach.
We did learn from the bad experience with FX where there is still no decent migration path for Swing apps to
this day so we intend to make the long term migration as easy as possible and intend to support the existing
tool for a very long time!
The obvious question is how will the new GUI builder differ from our current GUI builder?
Built Using Codename One
With the new certificate wizard you saw the beginning of a trend that we hope to accelerate. Writing our
tool using Codename One itself. This has numerous advantages to us but is also probably the best tool out
there with Swing/FX being effectively dead, SWT somewhat stagnated there is really no decent Java UI
library for us to use other than Codename One.
the value proposition is even bigger!
The Resource File Format
The resource file format is a binary format we originally invented for themes, images etc. This made features
like the GUI builder powerful yet somewhat awkward.
As we moved forward we added an auxiliary XML format that supports themes and allows teams to work
more effectively on the resource file. As part of that we added GUI builder XML file format support, this
is the format that we will use for the GUI builder which will make the migration process very easy.
The original GUI builder was designed for simpler mobile apps that had far simpler UI. Most of the UI builders
work was navigating between forms and adding commands. The state machine was a common practice that
made a lot of sense for that point in time.
Today we support, tablets, desktops and even web. With that in mind we decided to switch to a more traditional
approach similar to standard desktop GUI builders where every Form/Container or Dialog in the GUI builder is
represented by a single class and an XML file used to maintain the GUI builder state (see above).
However, we intend to add a statemachine compatibility layer in the future to allow easier migration from the existing
GUI builder to the new GUI builder with as little work as possible (although we can’t promise 100% seamlessness).
The new GUI builder will generate code directly into a class representing the UI. So if you have a form called
“MyForm” then you will have a Java source file named “MyForm.java” under the “src” hierarchy and an XML file
called “res/guibuilder/mypackage/MyForm.gui” under the “res” hierarchy. This “.gui” file will be used to store/load
the actual state from the GUI builder. The GUI builder ignores the source file almost completely except for the
special case of event handling.
The code generation will happen thru a new ant task that we already introduced in the build XML. It runs during
build and scans the res directory for “.gui” files which it then converts to Java source blocks. The “MyForm.java”
will have a special commented section that you aren’t allowed to touch, this is very similar to the NetBeans GUI
builder architecture but we probably won’t physically lock these code blocks like NetBeans does.
Releases & Limitations
We’d like to have a technology preview out for 3.2 but will probably release something sooner than that maybe
within the next month (which marks the 5 year anniversary of the launch of the previous GUI builder).
We don’t recommend the technology preview for production apps since the new tool might generate invalid
code and require that you manually edit the XML files to workaround issues. With the 3.3 release
we hope to graduate into beta level where we will start emphasizing this tool as “the gui builder”
for new projects.
The initial release won’t include standardized migration tools although we’ll try to add them as soon as possible
as this is the best possible way for us to test the tool (by converting existing apps).
The following big ticket features from the designer won’t be available with the initial release:
- List renderers – currently the designer uses a separate container as a renderer. Since the new GUI builder
works in isolation this would be more tricky for us to expose.
- Commands & Navigation – similarly to renderers this requires something more than a simplistic view of a single form.
- Back Navigation, Embedded Container – These features won’t be available in the standard GUI builder since they
rely on the statemachine architecture. We will add back navigation to the compatibility layer we plan to add and
will try to include embedded container there too
Toolbar– the old GUI builder was very flexible in terms of command behavior which effectively made it
very limited since it assumed nothing about command behavior. This turned out to be very in-flexible and prevented
basic usability features such as “placing a button on the title”. The new designer assumes that the
Toolbarclass is used and will allow greater control over command placement to facilitate that.
- Style manipulation/Localization – the existing GUI builder allowed customizing styles directly from the GUI builder UI. Since
we are now separating the tools styles & localization won’t be available. You’d still be able to make use of both
but not directly from the GUI builder UI.
We are looking for feedback on the tooling and direction, we want to make the transition as seamless and painless
as possible as we move forward. With that in mind I hope that once we launch this tool you’d give it a try
and let us know what you think.