[JanisErdmanis]

Perhaps your experience with QML would be more pleasant if you would write backend in Rust or Julia (my current choice). In Julia I find that it is particularly easy to iterate as it avoids any compilation step although that is not as smooth as using VS Code with hot reload on the side. There is also Felgo for reloading which I guess also preserves the state, but I have not tried it yet.

One quite an advantage for QML is how easy it is to align elements to get started. Personally, I find it quite frustrating to get HTML to do what I want whereas in QML having only used for two months I already see how to model `Kanban` UI with QML.

[onsclom]

I still don't get what advantage QML has over something like Svelte. Writing the QML backend with Rust would be nicer, but why wouldn't I just write my front end using Svelte/TypeScript with something like Tauri at that point? With statically typed languages you get autocomplete, more instant feedback, more editor integration for things like renaming functions variables, and the end result won't have type errors at runtime.

Felgo is what I was hoping for, good find! That covers one pain point, but there's still many, many more. QML does have a simple and great list of components to get started with, where as HTML and CSS have accumulated many years of cruft. But, that being said, aligning elements into rows and columns is easy using CSS flexbox[1]. Flexbox has the benefit of being much more versatile than QMLs layout tools as well. I imagine using flexbox you could make the Kanban UI just as easily, and you'll probably run into less limitations.

[1] https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...

[JanisErdmanis]

The flexbox does not seem to match the power of QML. For instance, I can have a two-pane view as simple as:

Text {

    anchors.top : parent.top

    anchors.bottom : parent.bottom

    anchors.left : parent.horizontalCenter

    anchors.right : parent.right

    anchors.topMargin : 10

    text : "Hello World"

}

which does not reference any dimensions of the objects. It is easy to reference an anchor of a sibling and other parent elements when needed.

Also, making new components is easy; I can inherit properties of a parent element, add my properties and put them in a file for later reuse is something I use extensively. Building each component carelessly using whatever mockery to get the look I need and then isolating it with its own namespace is relieving.

[onsclom]

Thanks for the nice response!

> The flexbox does not seem to match the power of QML. For instance, I can have a two-pane view as simple as:

I'm a bit confused by this example. When you make the other pane wouldn't you need to define all of its anchors too? It seems like the more standard QML approach to a two-pane is using RowLayout[1].

  RowLayout {
      anchors.fill: parent
      Rectangle {
          Layout.fillWidth: true
          Text {
            text: "pane 1"
          }
      }
      Rectangle {
          Layout.fillWidth: true
          Text {
              text: "pane 2"
          }
      }
  }

I agree this is pretty nice and intuitive, but flexbox makes this problem easy too.

  <div style="
    width: 100%; 
    height: 100%; 
    display: flex;
  ">
    <p style="flex: 1">pane 1</p>
    <p style="flex: 1">pane 2</p>
  </div>

Yes inline css has problems, but I didn't want to scare you away with Tailwind[2] and I think inlined CSS makes this example clearer.

> It is easy to reference an anchor of a sibling and other parent elements when needed.

It seems like by composing layouts in QML you can avoid a lot of manual anchor setting. Though layouts do have their limits. Is that why you resort to setting anchors manually? Flexbox is much less limited and flexbox layouts compose really well.

Do you have examples of UI layouts you feel QML solves intuitively that flexbox can't solve intuitively?

> Also, making new components is easy; I can inherit properties of a parent element, add my properties and put them in a file for later reuse is something I use extensively

Svelte works the same exact way. Well, except for the part that new components do not inherit from existing components. Svelte and other modern UI frameworks prefer composition over inheritance[3]. Composition allows you to be just as expressive, but without the footguns of inheritance. If you have a specific UI problem you think inheritance solves well, I'd be happy to try and create a matching composition based solution.

> Building each component carelessly using whatever mockery to get the look I need and then isolating it with its own namespace is relieving.

Svelte uses file based components as well. Each file is its own module in TypeScript/JavaScript.

If you have rebuttals or other additional things to add I'd love to hear it!

[1] https://doc.qt.io/qt-6/qml-qtquick-layouts-rowlayout.html

[2] https://tailwindcss.com/

[3] https://en.wikipedia.org/wiki/Composition_over_inheritance

[JanisErdmanis]

> Do you have examples of UI layouts you feel QML solves intuitively that flexbox can't solve intuitively?

I think your example on the flexbox use for two pane view illustrates that well. Although I have no experience of using it I get that the gist of it is the same of a RowLayout. It’s a good abstraction for listing many items of the same kind which need to respond dynamically with the change of window dimensions. But when I really need to place two panes 10px appart or put elements on top of it in the bottome left corner, bottom right corner and align margins of the content within the pane anchoring elements manually is so much easier. I remember when I started to learn QML my first instinct was to find where can I make a table and align elements within it where instead I just needed to use anchors.

The beauty of QML is that I can treat RowLayout and Row as elements written in QML itself. If I recall accurately it is possible to loop through child elements and assign properties to them such as anchors with respect to sibiling elements. The abstraction thus is more fundamental.

> Svelte and other modern UI frameworks prefer composition over inheritance

Inheritance is the right abstraction for the UI elements. For instance I don’t need to predict all properties in advance for my custom bottom implemntion when used in the code. Assuming that all of them are available is quite powerful and allows to experiment in place. This work exceptionally well in QML but not in OOP languages in general. Nevertheless, can you come up with `footguns of inheritance` to which QML is susceptible to?

> Svelte uses file based components as well. Each file is its own module in TypeScript/JavaScript.

This sounds interesting. I will give it a try on someday when I will need to make an UI in HTML.

[onsclom]

> two panes 10px apart

`gap: 10px`

> put elements on top of it in the bottom left corner, bottom right corner and align margins of the content within the pane anchoring elements manually is so much easier

These instructions seem a bit more vague. If you make this visually or with QML I'm sure I can replicate it in an intuitive way with flexbox.

Flexbox has `align-items`, `justify-content`, `align-content` which covers all the needs of aligning to centers or corners. `padding` and `margin` work exactly like you'd expect. Unlike QML's layouts, you can also enable `flex-wrap` so content automatically wraps when it overflows the allocated space.

Maybe you're also wondering, how do I memorize all these flexbox properties? I don't! Chrome dev tools give you a GUI for editing a flexbox[1], isn't that really nice?

With all these tools, hopefully it becomes clear that you never need to manually define anchors. You can compose these layouts to build whatever complex layouts your heart desires. But, if you are still really attached to the anchor workflow, you can do that with CSS as well. For example, `position: absolute; bottom: 100%; right: 100%` would anchor a child element to the bottom right of its parent.

> The beauty of QML is that I can treat RowLayout and Row as elements written in QML itself.

I totally agree here. My Svelte example from above would become:

  <RowLayout>
    <p>pane 1</p>
    <p>pane 2</p>
  </RowLayout>

What if I told you it's totally trivial to make this RowLayout component yourself in Svelte? This could totally be valid Svelte code! If this sounds interesting, this example[2] is a great starting point. And it would be even more trivial to pull in a great component library like Skeleton UI[3] which does stuff like this for you.

> If I recall accurately it is possible to loop through child elements and assign properties to them such as anchors with respect to sibiling elements. The abstraction thus is more fundamental.

Hopefully this RowLayout example makes it clear that Svelte can also loop through child elements and assign properties.

> Inheritance is the right abstraction for the UI elements

How are you so sure about this? React is one of the most popular and successful tools for building UI elements, and it avoids inheritance entirely. Do you think React's approach is totally offbase? Similarly, Rust and Go do not have inheritance at all. Do you disagree with their design?

> For instance I don’t need to predict all properties in advance for my custom bottom implemention when used in the code. Assuming that all of them are available is quite powerful and allows to experiment in place.

You can expose properties with composition based elements too! You don't need inheritance to support this workflow.

> Nevertheless, can you come up with `footguns of inheritance` to which QML is susceptible to?

I think the composition over inheritance wiki page[4] explains things much more elegantly than I ever could. Though I do think I made a mistake. Does inheritance actually exists in QML land? I don't think so.

It feels like you compose things very similarly to Svelte or React. Maybe it's a just a semantics thing, but imagine HelloText.qml:

  Text {
    text: "hello world!"
  }

Does HelloText inherit from from "Text"? I'd say no. HelloText simply instantiates Text and sets its' text property to "hello world". Though I imagine you would say HelloText inherits from Text and overrides the text property?

Compare this to the Qt Widget world where the difference between inheritance and composition are much more clear. Sometimes a Qt Widget doesn't expose the properties or functionality you want. The best scenario is when Qt Widgets do expose the properties you need. Then you can instantiate them and change those properties. Notice that even Qt Widgets sometimes expose properties without inheritance! When defining bigger fancier widgets, why require inheritance? Break them into smaller parts and expose useful properties. Then you and other programmers can compose custom behavior without going through the sludge of inheriting and overriding!

Perhaps we already agree on that part and it was just a semantics issue about whether QML is actually using composition or inheritance?

> This sounds interesting. I will give it a try on someday when I will need to make an UI in HTML.

Yay, I'm interested to hear what you think!

[1] https://developer.chrome.com/docs/devtools/css/flexbox/

[2] https://svelte.dev/examples/slots

[3] https://www.skeleton.dev/

[4] https://en.wikipedia.org/wiki/Composition_over_inheritance

[JanisErdmanis]

> Maybe you're also wondering, how do I memorize all these flexbox properties? I don't! Chrome dev tools give you a GUI for editing a flexbox[1], isn't that really nice?

This is quite nice indeed. I didn’t know that Chrome dev tools can be used that way.

> Does HelloText inherit from from "Text"? I'd say no. HelloText simply instantiates Text and sets its' text property to "hello world". Though I imagine you would say HelloText inherits from Text and overrides the text property?

Note that is also possible to create a new properties and signals for the Text which can be referenced by the children. Also it is possible to override the default method on how to treat it’s children for instance if you want to implement a CustomRowLayout. The HelloText thus has properties of the Text and the newly defined ones and it is possible to instantiate it at multiple places with different parameters and children. I don’t see why this is not inheritance…

> Perhaps we already agree on that part and it was just a semantics issue about whether QML is actually using composition or inheritance?

In QML composition is when one places children elements within a component and expose relevant properties and signals to the parent. So I disagree on this part. QML in my opinion is OOP done right.

[rubymamis]

BTW, someone created Flexbox for QML: https://github.com/tripolskypetr/qml-flexbox