Those are all great points. I’m thinking back on all the stuff I’ve written with Qt (and other similar frameworks) for applications where I have had to deal with what you describe. So you are telling me that there are user interface framework designs out there that do multiple interface event loops for different areas of a screen?
Regarding the interface stalls, I’ve had to deal with that in many apps over my career. It’s just part of the job. You have to learn to break the big things into smaller pieces or risk spinning cursors of death.
For example, I had to develop an in-cockpit display for a company reading utility meters from the air. I would load up a list of thousands of meters (using QMap) with the lat/long of each and display those over a realtime map following the ground track of the airplane. I did run into stall problems if the user wanted to display a very wide view map of the entire service region with thousands of meters plotted. But, if the user zoomed in to a more reasonable map area during real flight, the response of the app was quite snappy with excellent details in the maps (down to street level with structure outlines). While it would be great if the stall wasn’t an issue with the wide area view, the problem is showing thousands of meter locations on a small screen map of a wide area was of no real use anyway. It would be just be a solid mass of points over a very high level map with maybe only the major routes shown and labeled. You cannot see any detail at that scale.
I would argue the same for some of the things you describe. Anyone who thinks you can load a million rows into a widget table and have it be of any real use to a customer is a fool. There is an art to user interface design. I have had to deal with many engineers who have no concept of how to build an interface that is both useful and can easily be digested by the customer. Simply throwing up the largest amount of data you can usually results in a terrible interface experience.
Another example that is currently in use is a heat treatment app in my present company. I wrote the managing app in Qt. There is a problem when the user wants to see data recorded every 30 seconds in a plot over a 6 week heat treatment schedule. Again, doing this as a user is dubious because unless you are looking for long-term trends, you can’t see any detail in so much data crammed into such a small screen space. But the interface will happily do it and it will stall everything while it does so. That means you cannot close the vacuum valve using the button on screen while the interface is stalled drawing your crazy plot. Yes, I’d love to fix that but I can’t throw away the 95% usefulness of the app because of this one problem. It’s been in use now for years and a lot of stuff has successfully shipped using it.
Also, there is the issue of manpower. With the meter reading app I describe above, I was one developer in a startup with 3-6 months available to “get something done we can use”. I didn’t have time to reinvent the entire wheel – I have to be able to leverage a framework to be productive in that situation. I would say Qt helped me develop something that worked well enough to get the job done in the time I was allotted. If the company reading meters had grown to a huge enterprise (the company ultimately failed because of marketing, not technical issues), then perhaps the resources would have been there to take a different approach and work on getting rid of all those possible stall points in the interface – even the crazy wide-area view of hundreds of thousands of meter locations.
I see your point with medical applications. Unfortunately a life is on the line and you don’t have the luxury of saying “this is the best I can do with the tools at my disposal in the time you have allotted.” Ultimately whatever can solve the issue for medical apps can make life safer for all of us for other applications.
Is the only answer developing multiple applications to service different interface categories on a common screen? Or did I miss your point again? Here it seems you are relying on the operating system to slice up the responsiveness of the overall interface for you. I know have run into problems in the past where even the operating system’s screen rendering engine is single-threaded. MacOS, for example, will stall the update of an app in the background if its interface is not visible on the screen! I’ve used a utility that stacks Windows 10/11 applications in a tab layout and the execution of the background tabs will stall!
So, again, can you show me an application framework for user interface design that doesn’t suffer from these kinds of issues that doesn’t cost a small fortune and gives me comparable productivity for 95% of the things I need to do as a single developer? As I single developer I simply cannot reinvent the wheel from first principles for every task. I hear a lot about QNX but I confess I’ve not researched it enough to even have an opinion.
Many thanks for you insights.