I wouldn't be too fast to recommend this. I have quite a lot of experience with Qt[1], and I manged to get a good look and feel across different operating systems. Yes, you'll need to customize Qt Quick components yourself. But that's easy. Also, Qt is improving its support for native components, they now support native dialogs and file pickers in Qt Quick[2]. Another important thing, is that you can always extend your app using open source libraries - for example - qwindowkit allows you to create native frameless windows.[3]
I highly recommend Qt. And related to this post, you can write some extremely responsive and fast applications with it.
[1] https://www.get-plume.com/
Also, if I remember correctly there was a time when Spotify was written in Qt.
Lets say I want to control pan/tilt/zoom/focus/aperture/etc of a remote camera. If I ask lets say an expert in UI framework Z to do it, it will take them 10x longer to create a very painful experience using standard elements with poor input latency, so someone actually trying to setup a camera over/under shoots everything, but it technically "ticks every box". The path to create a better experience just isn't really there and it is difficult to undo/change all the boilerplate/structure, so version 1 isn't improved for years because it took so long to create the first iteration.
Maybe your definition of "fast" for a large text file is War and Peace, and mine is multiple 1/10/100 GB text files that you want to search/interact with in realtime at a keystroke level.
I've probably written 100+ completely different "very specific examples" in very different industries, because that's where you can create much better experiences.
Generally your expectations are based around what you get as standard from the library, but if you want to get a much better experience then it immediately becomes a lot more difficult.
At the end of the day, Qt can also be just a wrapper for your highly optimized engine - for example, NotepadNext[1] is using the very performant Scintilla engine while its UI is written in Qt. From my (unscientific) tests, it's even vastly faster than Sublime Text.
BTW, I'm not saying that rendering and creating your own UI is always a bad idea. Many people do it because it's fun and challenging, or to push the boundaries. That's what Vjekoslav Krajačić is doing with Disk Voyager - writing a file explorer in C from scratch[2][3]. But for many people, that's too much. I believe Qt C++ with QML is the best combo for most people, for most applications.
[1] https://github.com/dail8859/NotepadNext
[3]https://www.reddit.com/r/SideProject/comments/103b9fy/disk_v...
The reality is QT/whatever program/framework is doing 100 things you don't care about when loading/rendering a file. If we only care about 1 thing we can do that much better because we don't care about the 100 other things our naïve code we wrote in 5 minutes outperforms the standard element by a factor of 1,000.
Windows is the primary target for these tools, but I'd really like them to be also available on Linux to lessen our Windows dependency. I've used Qt in the past, before they introduced Qt Quick. I also heard about complicated licensing changes when they moved to Qt6, which made a lot of KDE devs worry. And stuff like not being able to download Qt without an account; or the framework coming with everything and the kitchen think nowadays, where I am only interested in desktop UI; no networking, no JavaScript-like scripting language, etc.
I don't want to build a complete UI system from the ground up, but there are certain points where I'd like to be able to customize things, like adding new widgets and having some way to render 2D things without needing a graphics API surface -- think HTML canvas. I feel like ImGui does a pretty good job here, giving you drawing primitives.
For state management I am mostly concerned with the life-time, ownership, and connections between objects. Where other languages, like C#, don't really have to worry about this due to garbage collection, in C++ you typically want things to be more strictly organized. I'd prefer a UI framework to facility object life-time management in a streamlined manner. Like, if it opts to use shared_ptr for everything, that's fine, but it also needs to prevent me from accidentally building cycles and provide a way to dump the dependence graph so I can see directly why a certain object is retained (and by whom).
To clarify the difference between C# and C++ here, think about how the implementation of an observer pattern is vastly more complicated in C++ to be safe as object life-time is not managed automatically for you. Copy & move semantics only adds to this in terms of complexity.
State management and user interaction are closely related here, as almost all user interaction results in state modification. Looking at HTML/JS frameworks, some leverage a 2-way data binding approach, where others bind data only 1-way and use events for the other way. In immediate mode GUIs I am updating the underlying state directly -- practically having the view and model tightly coupled. Here I'd like for a framework to be explicit about what is happening, without being too cumbersome to extend a UI with new functionality. E.g. I don't like signals that can be used across the whole code-base, where suddenly a function executes and you have no idea what originally triggered it. On the other hand, having to handle and forward every basic event from one component to its parent isn't an option either. If that makes any sense.
[1] https://github.com/ph3at/image_tool [2] https://flaxengine.com/features/editor/
Yes, Qt may not be super friendly with this. However, it is perfectly possible. Qt lets you integrate an "external canvas" that you can render with your favourite graphics API (e.g. OpenGL) and integrate it in the Qt Quick scene (or widgets if you prefer). For example, I did this with my notetataking application, Scrivano [1], for handwriting, where the main canvas is a separate OpenGL view that renders content using Skia, while the rest of the UI is standard Qt Quick.
Not to mention, the exact same paradigm translates to the other Microsoft desktop/mobile/x-platform frameworks, so if you insist that WPF is "old" or out of date, everything you build can be ported/refactored quite easily to the newest framework(s).
I have built non-trivial desktop apps in every framework except QT, and you would have to pry WPF from my cold dead hands.
1. What is your goal? Do you need to run on Windows and Linux? QT isn't bad, although I personally think the UI looks a little weird. It is definitely highly opinionated and parts of it are quite strange IMHO. There's probably lots of jobs writing with QT, which might be a nice side bonus from learning the framework.
2. Do you need a totally custom UI? If so, I would stay with ImGui. You might find Windows UI development extremely frustrating, especially that you have to owner draw a lot of stuff to get a really custom UI. That can be an extremely difficult and terrible experience, and I don't recommend it to anyone who isn't already an expert at it.
3. State management? You mean like the state of the UI? Is a button pressed? Could you be more specific?
4. User interaction? This is such a broad area. Could you be more specific? Like filtering mouse and keyboard messages? Windows has several APIs for this.
EDITED TO ADD: In my experience, which is significant, either use a GUI framework and operate within its capabilities, or draw everything yourself. In Windows, your life will become exceedingly difficult if you use a framework when you want to do a lot of custom components, or if you want a lot of custom look/feel. If it were me, I would draw everything myself. People don't need the consistency of the Windows UI anymore, provided you stick with common and well-known metaphors like text boxes and property editors, etc.