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