Modern way to layout UI components

[develar]

What's your vision about layout? Do you think that old good way to layout components using layout managers / custom positioning a way to go? Or do you keep in mind some modern solutions like UI DSL — e.g. Jetpack Compose or something like IJ Platform UI DSL? And only lack of time / priorities is the reason of why currently old good layout managers are used?

[andydotxyz]

Are you refering to how the code works, or how developers build it?
There are plans for a more advanced and flexible layout manager (#4) but also we plan a GUI builder app (#227) - I don't know if either of those ask your question.

[develar]

or how developers build it

I referring to how do you suggest to build layout — how to write code. Your vision about this topic. There are three solutions:

1. Old good imperative using layout managers. Even if some advanced layout manager like MigLayout will be available to use, it is still imperative code.
2. UI Designer.
3. DSL. Like mentioned Jetpack Compose or IJ Platform UI DSL. With some degree even Vue.JS template it is DSL (if you use not html, but some desktop framework like Element).

I have quite enough expertise in all 3 solutions and I am wondering what's your plan (sorry if it is stated somewhere, I didn't find information).

[andydotxyz]

Well, the approach to all coding in Fyne has been to use a compile-time type checked language so we can ensure a correct program before it ever runs. I suspect that a DSL doesn't really add anything in that area.
We prefer test driven development over scripting or other text-based interpretation of code presentation.

Our plans for a UI designer would graphically create the same output as writing the code manually - though it's not all worked out yet. It will offer a "What you see is what you get" approach to writing the code for people who prefer to work visually.

[develar]

Our plans for a UI designer would graphically create the same output as writing the code manually

In my opinion and experience it fails and DSL wins (DSL as a code, not as a extra yet another format). Ok, thanks for comprehensive and quick answer.

[andydotxyz]

In my opinion and experience it fails and DSL wins

Can you explain a bit more about what you mean here?
And more specifically, why does a DSL succeed where our current API does not?
For example the following code looks rather like the DSL examples that are dotted around except we are using Go:

	hello := &widget.Label{Text: "Hello Fyne!"}
	w.SetContent(&widget.Box{Children: []fyne.CanvasObject{
		hello,
		&widget.Button{Text: "Hi!", OnTapped: func() {
			hello.SetText("Welcome :)")
		}},
	}})

[develar]

why does a DSL succeed where our current API does not?

it fails

I mean that proper DSL will provide better UX because we are all developers and DSL will allow to express desired result in a more expressive way (accompanied by a preview tab :) anyway).

From #1230:

The Fyne API is based on semantic outcome - a widget API is about it's logic and state rather than visual appearance.
The rendering of a widget is handled by it's (private) renderer according to the current theme.

It makes task more easier and DSL a better candidate, as you can restrict freedom (style everything) and provide some abstractions introducing some concepts likes "note" / "header" — widgets. For example IJ Platform UI DSL is very restrictive and forces developers to use only what described in the guidelines.

why does a DSL succeed where our current API does not?

I am in no way saying that current approach is bad.
In this example, once we will be needed some advanced layout in some row, another container with another layout manager will be required. MigLayout / DSL impl layouts all controls in one container (or several, it is implementation detail) and allows user to operate in terms of row/column. But MigLayout / some advanced layout manager forces you to explicitly set such layout constraints, and DSL allows you to express it using some markup.
Such DSL in Kotlin is very easy to implement, as inline functions are supported (so, you don't need yet another compiler or some generate steps — all such functions have zero over-head), but it is technical details.