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.

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.

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 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.

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.

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?

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.

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.

very sad state of affairs indeed

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?