Rewrite GUI controls - use Java Swing architecture ideas

[ShlomiRex]

I am dealing with the control / GUI of godot engine and I see ton of messy code all over the place.

I suggest that we rewrite some of the components from scratch, taking inspiration from Java Swing GUI library.

It is a challenging task, but if we want to keep moving forward I think we should take inspiration from other places.

For those who don't know, this is the architecture of Java Swing components:

The main idea is to use inheritance to avoid messy code and allow godot users to use and inherit existing components. This will allow the Godot GUI controls to provide reliable APIs with clear direction.

Why

• The current codebase is a mess.
• • Example: _notification function in all the components
• • Another example: _shape function in all the components
• • Another example: some of the controls have minimum size, but not maximum size.
• • The theme_cache is defined in multiple controls.
• We don't have unified way to contain (add/remove) generic components inside another components
• We don't have universal functions such as: set_enabled, set_editable,
• We should have some uniform base functions such as get_size, width height of the component, and more.

Add new components

Add base classes:

• All godot components will have G suffix, which indicate they are GUI components (it is also like the Godot name, and also like Java Swing nameing: JTree, JButton)
• Add Component - an object having a graphical representation that can be displayed on the screen and that can interact with the user
• Add Container - a generic abstract container that can contain other components
• Add GComponent - a base class for all G* controls

Add the controls:

• Add GLabel - a label
• Add GTextField - a text field
• Add GTree - a tree control component
• Add Scrollable interface - handle scrolling in container. This can be inherited by all the control objects that use scrolling.
• Add GButton - a button
• Add GPasswordField - password protected text field
• Add GTextArea - expandable text field, multi-line
• Add GCheckBox
• Add GRadioButton
• Add GList - A component that displays a list of objects and allows the user to select one or more items.

Change current controls

ItemList

ItemList includes unrelated functionality.

• Should inherit functionality from base classes, such as: GUIComponenet (base class for all controls), Container (only deals with the containment of the viewport), GComponent (like JComponent, base class for all G* classes, such as ItemList, Tree, Button and more).
• set_item_language - should be dealt in base class (inherited)
• tooltips handling - should be inherited
• icons handling - each item in ItemList should independently handle this, what if there are no icons in ItemList? It should only be handeled by object that use icons.
• messy GUI input handling (335 lines) - some of the functionality can be dealt with in base classes
• I has some column properties (number of columns) - but has no implementation of dealing with columns. It should not be handeled by ItemList at all, but by different GUI component such as GTree
• The _notification function can be handled in base class GComponent.
• The _shape fumction can be inherited by GComponent base class.
• The set_text_direction function can be inherited by GComponent - some components will be able to override this function.

Button

• The _notification function can be handled by GComponent base class.
• The button handle icons, it should be handeled by the contained controls. i.e. - add Icon to Button. The button won't need to implement any icon handling. It only sees the contained Icon component. This Icon component will handle icon functionality.
• The _shape fumction can be inherited by GComponent base class.
• The set_text_direction function can be inherited by GComponent - some components will be able to override this function.

[AThousandShips]

Please provide some concrete issues you're having and what to change, a change that just involves "change things" isn't something that can be realised or appreciated

[ShlomiRex]

I am re-writing my post. Please see again. Note: I am still writing some ideas, since the list is long.

[AThousandShips]

Please focus on explaining why this should be done, just aligning with some API structure of another library or API isn't really a reason alone

[Zireael07]

To add to this, I believe the way Java Swing is structured as it is is because Java the language forces deep inheritance hierarchies.

[AThousandShips]

Prefixing G* makes sense for a library in a general purpose language, but little sense in a game engine where all components belong to the same context, Godot is not a library that you use with other code where distinguishing where things come from matters

[AThousandShips]

The GUI system is structured based on functional inheritance, further Godot doesn't offer any interface system or abstraction in this way that Java does, so basing things on a language and API that's fundamentally different makes no sense

[AThousandShips]

All the suggestions for new components to add already exists, what do you mean by that

[theraot]

Some of the things you say already exist:

• Controls have a size, we can get it and set it.
• _notification is the kind of thing you want: defined in a base class (Object) and the derived classes override it.

I suspect there is some complain you are not articulating here, or it is not coming across.

---

Some things I do not agree with:

• Renames:

  • We do not need a G prefix.
  • You say "add" but you list a lot of renames of already existing Controls.
  • In fact, I believe that when you say to add a Component class, you are saying to rename Control.

  I remind you that renames are breaking changes. Thus, I do not expect any more renames until Godot 5.

• I see no point in GComponent. What does it do? Why do we want it?

• And you also talk about base classes handling stuff...

  I wonder how much do you want the base classes to actually handle, and how much do you want to be overridden. Because I'm getting a picture of a base class that does a lot, and would get complex with of all the cases... So we would have each derived class overrides the methods from the base class to what they need, but then we are back to basically the same code, except with a more stuff in the base class.

  I think you are seeing an importunity to reuse code, but I don't see it. Thus, consider suggesting that in particular, instead of this big rework. Skip the superfluos renames and similar, and let us see the actual improvement.

---

This is what I rescue from what you said:

• Let us have a (coming up with names here) InteractiveControl/InputControl that would be a common base for Button and other Controls that react to user input, including TextEdit, LineEdit, etc. Then this class can have set_enabled and set_editable.

• Maximum size is good. I think this has come up in proposals before, but I cannot find it right now.

• text_direction could be moved to Control.

---

I'm having a hard time understanding what you want from Container.

First time reading this I was going to just say that Container exists already.

But you say that Godot lacks a way to add or remove "components". So I think you are talking about Controls such as ItemList.

And I believe you mean that because if you just want to add arbitrary Controls inside of other, those are children. And we have add_child and remove_child as unified way to add them and remove them respectively. In fact, A Controls can have Controls inside even if they are not Containers, since this is a concept that comes from Node... But only Containers take control over the position of children.

So, if ItemList is meant to be a Container it does not sound like the Container we have. But, perhaps a Container dedicated to an specific type of children (or new functionality on Container). But then when you talk about ItemList you mention it would be a Container and that that "only deals with the containment of the viewport". That suggest they have no special functionality. So... Are you suggesting to make ItemList a generic container (a container for arbitrary Controls)?

I can see taking Controls that currently have custom items and converting them into generic containers as both good at bad. For example, if PopupMenu were a Container for arbitrary children, some advanced UI would be easier to implement. On the flip side, the common cases would be harder to implement. So this is detrimental for usability.

Speaking of usability, I sympathize with Button having other Controls inside. Sometimes we have a Button have no text or icon, and then add UI inside the Button. The flip side is that it is not intuitive to do. And if this becomes the standard way to do everything, it would also hurt usability.

---

I do not know if something is worth doing about _shape (I have not looked at that part of the code), or theme_cache (as far as I can tell each class is caching only what they need).