Brainstorming: Requirements of a Swing Replacement

Question

What is required of an updated and legacy free Graphical User Interface API for Java?

//TODO: Add your ideas below.

Answer 1

My wishlist for a GUI API is:

• No absolute coordinates.
• No separate layout hierarchy. Layout managers should be implemented as widget containers
• Don't attempt to solve every thinkable layout algorithm.
• Design the API in such a way that you can actually prototype the GUI directly writing the code for it.

I probably have more items on the wishlist, but that'll do for starters.

Answer 2

Ideas so far:

• Ability to Parse of a XAML or a similar layout-formats at runtime
• Ability to Compile XAML or a similar layout-formats into bytecode
• Threadsafety
• A Collection of pre-configured Windows for common use cases

Answer 3

XAML based.

Instead of a conversion between declarative formats, have it be the main format :) / with a corresponding class model.

Answer 4

I'm no expert on the matter, but here's my contribution:

• A rules-based approach that implements a contract over the layout. Certain items should not be aligned too far from another one, etc.
• Some other paradigm than ActionListeners, which seem to spiral out of control. I don't know if that's possible in an encapsulated world. I guess I wish that you could define a function and pass it as the action (if that's all you need), but that really isn't in the paradigm.

Answer 5

• A good HTML-Component. Maybee based on Webkit. If you have a good HTML-Component that is able to do Javascript, you don't need very much GUI-glue these Days :). Write the logic in Java and let HTML do the presentation.
• A good Editor-Component that is easily extendable with a good RTF-Component. The current EditorKit wasn't touched in years and sucks really hard.

Answer 6

I think a new GUI should be opengl-based nowadays

Answer 7

• Do away with the current layout system.

• Do away with revolving around single mouse-pointer metaphor for events. Soon enough we'll all have multi-touchpads on our keyboards in addition to mice. Current Swing cannot really scale there.

• Better definition of event flows and responsibilities.

• Support for defining constraints and binding object states to one another.

• An inherent support for 3D, rather than requiring a separate API. At a minimum, all coordinates should have a depth element.

• Do not directly build via inheritance on any existing API that you already consider broken (e.g., the mess with Swing containers inheriting from AWT containers).

Also, if this is a commercial or a major open-source project, get API usability experts to go over the API before it is published. Same goes for the documentation of the API.

Answer 8

I am for declarative UI design (XML is nicely toolable and parsable).

• Timeline support. Pluggable Custom

• Shaders, which take advantage of GPU.

• Native application theming packaged (MACs in mind).

• Inherent localisation support via UID of elements.

I'll keep thinking a come back with more ideas.

Answer 9

• Declarative, extendable markup. For all their sins, JSP/JSTL are a good model here.
• Easy for non-programmer designers to design and change a GUI.
• A component model such that tools can use new user-generated components in the same way as the pre-supplied components.
• Tooling for non-programmers to design. The tooling will come later on, but will be affected by the API/facilities being done now.
• Sane separation between design and behaviour, so that programmers need not know about layout, and designers need not know about programmers.
• Cross platform. Cross platform.

Answer 10

• scripting support (perhaps integrate a scripting language out of the box)
• use OpenGL (or similar) to render the widgets
• design a WYSIWYG UI builder along with the actual API

Answer 11

Visual Basic/Delphi-like IDE.

Answer 12

• Native widgets
• Simple
• Light weight

Answer 13

Only one for me:

• Speed!