I've always tried to build GUIs declaratively, but always failed to see the advantages over a traditional imperative building blocks. It's all good if we want to display a static dialog box, which is always the same, but complications arise when we want to do some nonstandard stuff. And this "nonstandard" is defined differently depending on the framework, but for some frameworks this status is achieved pretty easily.

With declarative + nonstandard we end up with some declarations, which are not the GUI we expect it to be, plus imperative code that mutates this anyway. So it's like we don't have the advantages of declarations, and we still need to write the code to build the GUI.

I'm still waiting for nice Qt bindings for Rust, as qmetaobject-rs seems to be QML-only?

I think I get what you mean. In my experience, declarative frameworks are great for simple UIs but don’t scale all that well with UI complexity. Eventually you find yourself doing somersaults and handstands to achieve what you need with them and find yourself wanting to fall back to a boring old imperative framework.

Granted, my experience is with SwiftUI and Jetpack Compose, not QML but it doesn’t seem like developing complex (especially full fat desktop-style) apps with declarative frameworks is as nice as it could be.

SwiftUI is still relatively young and... idiosyncratic. I hate how hard or weird it makes some basic things. (empty, transparent element with an action attached just to handle an event of the window appearing?)

But there are some really good systems available. .NET WPF is great overall for example. I could of course complain about how things are implemented and how mvvm is not baked in and how converters are too big and many other details. But I never needed to hack around the declarative part - that always just worked.

Have you seriously looked at/studied XAML?

I was convinced that XAML was the perfect answer for rust and had the idea that I could write an independent XAML library/engine that rust appdevs would use and then match to a backend that would codegen the XAML into code that utilizes its corresponding api.

I had a sample that worked with both imgui and one of the other rust gui engines (not immediate mode) to prove it could be done. Biggest benefit was abstraction from actual ui toolkit choice (inspired by Windows where you can use a subset of the same XAML with WPF, Avalonia, WinUI 3, UWP, Noesis, Uno) and being able to take an imperative ui library like ImGUI and use it in a declarative fashion. Moreover, you could reuse existing XAML designers or avail yourself of XAML export functionality in some design software, without having any of that be rust-specific.

I put out feelers in the community to gauge interest but I think XAML is too foreign to most FOSS devs that picked up Rust early on and people couldn’t see what I saw in it (having worked with XAML for over a decade in C# land).

I tried for a year to learn XAML (mostly using Avalonia) and it just never clicked for me. Feels like it needs too much secret insider knowledge that you're only going to get with that decade of C#. To much is implicit and magical, and it was very, very hard to trace through what was happening when something behaves unexpectedly.

I got to the point where I could build a basic app with it fine, and I might pick it up again if I find the right project, but it just never seemed like it was adding anything, just making simple things more convoluted to me. I also found the C# community to be pretty hostile and insular, not in an intentional way, just more of a "hey we really want to help but everyone is too dumb and lazy to learn these hundreds of 'basic' things", and there's no good places to learn outside of noisy discords, SEO Spam q&a sites, and weird and vaguely hostile chatrooms.

I haven't used XAML even once, but I've tried to use FXML (JavaFX), but generally it felt too superfluous and inconsistent. But I'm not sure how XAML and FXML are related (if at all), also I'm not sure if XAML is even used outside C# and Windows?

I haven’t used JavaFx so I can’t answer that part of your question but XAML has been cross platform with Xamarin on macOS and Android and now everywhere with MAUI. I also mentioned Uno which lets you develop for web/electron with XAML.

Language wise, it has been largely C# or other .NET like VB.NET, F#, or managed C++ though I think Noesis lets you use it from C++ and other languages directly.

C# itself is completely uncoupled from Windows ever since .NET Core and now with later .NET versions like .NET 8 all Windows-specific bits have been torn out altogether. Microsoft probably uses C# on Linux more than they do on Windows these days.

Could you make some actual example? Because I read 3 paragraph and I have no idea what you're talking about.

I've got a potential example; I always wondered how that would be achieved with something like slint or qml:

With tools like xournal++ or other things like document processors, you can usually define your own panels, reorganize them, move them around, add icons or separators, etc, and all of that in a drag&drop fashion, live from the program running.

I feel like having a (compile-time) declarative description of that wouldn't cut it, or be very abstract, with most of the logic outside of the declarative description. Another option might be something that's "runtime declarative", and drag&dropping icons and panels around just change the ui definition?

Yes, panels are one example. Which panel goes to which window corner? What is the resize policy? It will probably be read from the file according to user preference, so it can't be hardcoded declaratively in QML.

What is the current theme? Window position? Maximized/minimized state? Those need to be read from preferences and applied at runtime.

I can declare a listview. What are the columns? Those are probably read from preferences. Along with their order and sorting preference. So I can't declare that in QML, I need to dynamically create the GUI in window creation code.

GUI style: basic/advanced. I might be able to get away with different QML files for that, although I need to figure out which QML file to use in runtime (because I need to read it from prefs), so I can't hardcode it.

Maybe the main window can have a splitter in the middle. In this case the left and right widget needs to be saved/restored somehow, and the splitter position needs to be persisted. Maybe we support tabs in the main window, and those tabs could be dragged outside of our window into a separate standalone window. We need to serialize the state of the window manager, and deserialize it later, so user preference would be preserved. Is the scrollbar standard or custom? Because we might be doing a text editor and we maybe want to support visualizing buffer map inside the scrollbar. This widget is probably fully owner-drawn anyway, so can't be declared in the QML.

I guess nowadays most of those topics are not even considered because there is no such thing as user preference for GUI. User takes what the javascript developer gives, nothing more, nothing less.

I feel like half the things you describe as needing to do at runtime are ok to exist in the declarative QML, but as a property with a signal. Position? Property. Basic/advanced view? Property. Splitter config? Property. Etc.

Leaving some things as parameters that can be adjusted in the model doesn't make the GUI not declarative. Preferences are just fine in a declarative world. Some things are harder than others, so list views that handle very generic data may need to be built manually, but those are exceptions.

> nowadays most of those topics are not even considered because there is no such thing as user preference for GUI.

very sad state of affairs indeed

I think it works completely fine in QML.

Qt has had panels and splitters that you can move around at runtime since forever. There's a function to call to save the state and restore it when loading. What's the problem?

KDE's System Monitor is written in QML and supports most of this.

Have you tried https://slint.dev/?

I have tried it, and I feel like this is not a good toolkit for desktop apps. It's great for embedded hardware with custom interfaces such as vending machines, car on-board PCs, screens in public transport, but it does not have that native look-n-feel on desktop, at least not out of the box.

I thought slint supports a Qt backend for desktop apps: https://slint.dev/releases/1.3.2/docs/slint/src/advanced/bac... ?

But yeah I've had same issues when using QtQuick for desktop use cases.

Didn’t they migrate to Fluent UI style or am I mistaking them for someone else?

You are right. The Qt backend is optional.

The only issue with declarative is when declarative is a prison instead of a fantastic and reasonable guideline. One of the very nice things about react is that you can escape pure declarative syntax to use actual javascript/typescript. Every declarative DSL/language/format that I've used has approximations like QML's [`Repeater`](https://doc.qt.io/qt-6/qml-qtquick-repeater.html), but eventually you will want and need some weird loop or logic that is most easily and succinctly expressed in a proper programming language -- at that point, you'll need to do some angry hack that unrolls one data structure into another so that you can iterate over that one with the limited logic in the declarative format. And then you'll have to keep the two models in sync.

All doable, just a pain.

Can you compare it with GTK bindings for Rust?

I'm a big fan of QML, but I've avoided Qt on Rust for some time due to poor experiences with earlier bindings a while ago.

At the time, using GTK, imgui, etc were a bit friendlier on Rust than Qt. Hoping this has changed.

Sorry, no experience there but it's possible that just for big screens, GTK might beat Qt ... (I think KDE also supports the "legacy" Qt + Rust option in some way ...)

But my point was mainly about the (almost) impossibility of building a well functioning cross platform UI kit. I honestly believe that effort should not be spent in that direction when a reasonably open source and well functioning option already exists.

I find QML satisfactory for big screens. Made an app back in Qt5 and my main dev machine was a 4K, 43 inch LCD TV -- it did fine on the big screen. No limitations in that regard that I could see.

Do you mean it’s no point in writing a GUI toolkit in Rust?

You'd never be able to compete with qt anyway.

You could - if you have several hundred full time developers working on it for years. This probably means you pay them, but the count of full time developers is the important part.

That cant be true. Why does QT need hundred of developers when the core product can be done by a single person? (see Sciter)

Details are hard. The core might be doable in a basic form by one person, but there is a lot more than the core that needs to be done. All those little details add up - they are only a small improvement, but all those small improvements adds to polish.

It would make sense to have a library that can do basic Svg/Canvas things, in Rust. From there, people can write all sorts of GUI libraries.

Yeah but Qt does a lot more, to match Qt you would need a similar effort. I remember some time ago was a popular article shared here on how hard it is to render text when you need to consider all the languages and all the font types and all the options. So it wold be easy to paint some shapes and some english text in the happy case and it would probably be enough for video games but then you need Widgets that will work with different user preferences, different languages, different color schemes, different DPIs, different platform conventions. Then you want to access the clipboard, the App settings folder, the notification system, maybe embed a webview to show soem html content ... Qt does a lot of things if your job is to make a professional complex Desktop application starting from basic building blocks and wasting your time on the Widgets and platform stuff then on business logic is not a good investment. If you are a hobist and writing Rust makes you super happy then I invite yout o continue.

The point is if you start with a good foundational layer, then a community can build greater things on top of it.

Of course, it will take time and if you're looking for a great library that can do everything out of the box, now, then you should pick Qt, there's no doubt about that.

Communities forming around a project is one of those things people think happens a lot but doesn't.

Even with effort, meaningful communities are the exception (let's say 1 in 1000 projects) rather than the rule.

There is also a significant random luck/etc aspect that people like to pretend doesn't exist (ie people like to pretend that if you do all the right things you will just end up magically with a community around your project 100% of the time)

But who'd contribute when qt is already there?

Getting contributions is nearly impossible. Getting them for a not so useful vanity project is probably impossible.

> But who'd contribute when qt is already there?

Because it will be written in pure Rust (with all the memory-safety advantages that come with it).

>Because it will be written in pure Rust (with all the memory-safety advantages that come with it).

I do not think that Rust enthusiasts will waste their free time reimplementing complex, boring stuff in Rust, only if they are paid, otherwise they will work on a new Rust game engine, or TODO app, or AI, WASM or something cool. Something as big and as high quality as Qt can't be implemented by 3 guys in weekends, maybe if they get Patreon support os they can work full time they can get the easy part done.

I do not think Qt suffers from memory issues so nobody would pay to rewrite it, but maybe we will have some super simple GUI framework you could use for GUI in video games or some simple English only , zero customization , simple apps.

You need a big community that can build a Qt alternative, we have Linux as an example of a community project but the reality is there was a lot of money behind it, so you need a Rust community with a lot of money behind it so developers will be paid to work on the non-cool stuff.

the good foundation layer needs to be designed correctly. Otherwise you have SVGs and English, but you have to tear the whole thing up when someone asks for translations. Then someone asked for the next feature and you have to tear it all up again. This is a hard problem.

> even if I can write some GUI in a "rusty" way, it won't suddenly speed up things because GUI is almost never a bottleneck.

Nor are any of the other things people use Rust for, but that doesn't seem to reduce the enthusiasm any.

Rust does not make your rocket fly faster, but it lowers the chance that it would explode mid-flight.

Rust can also leak memory (memory leaks are memory safe in Rust).

If that's your reason for using Rust then safety is as useful in a GUI toolkit as anywhere else (indeed I'd say more so - GUI toolkits tend to involve lots of hierarchies and callbacks that make it easy to get confused about ownership, or get into unexpected states).