Question about GUI development

[ubrhn]

Hi,

I'm the author of the open-source software LibrePCB which is also based on Qt. I'm currently evaluating how to improve our UI/UX, and an important part of that is to move to a more modern, responsive and consistent look. Since I'm very impressed by the neat GUI of OBS Studio, I'd like to understand a bit more about how it is developed. I don't want to waste your time too much, just some hints about the general design concepts would be great :)

As far as I can see, the GUI is entirely made with QtWidgets, with heavy usage of stylesheets (*.qss files) and SVG icon sets. And for layouting therefore I suspect the QLayout classes are used. Please correct me if I'm wrong.

As a concrete starting point, these are the main questions in my mind:

• Are you generally happy with QtWidgets+QLayout+Stylesheets, does it work nicely even on all the different platforms (i.e. is the look not corrupted by platform-specific Qt behavior)?
• Are the themes compatible with a wide range of Qt versions, or do different Qt versions cause troubles with the compatibility of (non-versioned) themes?
• Are/were there any intentions or experience with QtQuick/QML? Or concrete reasons for not using it?
• Any recommendations for learning material in addition to Qt's documentation Styles and Style Aware Widgets?

Thanks in advance for any hints.
Urban

 

[Lain]

Hi Urban, nice to meet you.

> Are you generally happy with QtWidgets+QLayout+Stylesheets?
Although I'm pretty proud of what we've accomplished with our user interface (especially considering the limitations of QtWidgets), it does have its downsides and limitations. QSS files are pretty hard to work with; they're janky and aren't really heavily maintained Qt-side. Another thing is that the UI code is all C++, so of course you can't really do much without C++, which makes it not very accessible to average UI developers who are familiar with web technologies. QML on the other hand is more understandable for web developers and much easier for them to work with.

> does it work nicely even on all the different platforms?
For our custom themes, mostly yes, we're able to make the differing themes consistent across operating systems and window managers. Funny enough the system theme tends to have more issues than the custom themes when used across operating systems/etc.

> Are the themes compatible with a wide range of Qt versions, or do different Qt versions cause troubles with the compatibility of (non-versioned) themes
We don't *usually* have problems across Qt versions for our heavily customized QSS themes. I think it's because QSS isn't really very actively maintained on Qt's end, but again, generally no problems with our themes across Qt versions. At least as far as I can remember.

> Are/were there any intentions or experience with QtQuick/QML? Or concrete reasons for not using it?
Native widgets so we can use our graphics subsystem to draw on the window, and those aren't available in QtQuick/QML. I tried implementing some texture sharing between QtQuick/QML but it was too painful to do and QtWidgets are good enough for now. It would probably be more ideal if we did have the ability to use QtQuick/QML.

If you don't need native widgets and don't have your own custom graphics subsystem like we do, I'd say go with QtQuick/QML but that's just me. Only downside is that QtQuick/QML just does not feel native at times.

Also, packaging your program with QtQuick/QML is a pain. So many extra files you have to include over QtWidgets.

> Any recommendations for learning material in addition to Qt's documentation
There's generally not too much to it and QtWidgets are fairly easy to use. Usually. I'd recommend just following the official Qt documentation/guides. I'm pretty sure there's plenty of resources related to Qt out there on the internet as well.

Generally I'd just say if you want to learn it, just play around with it. Worst case scenario just look around on the net for more examples, that's what I originally did a long time ago.

Anway, hope you have a nice week!

 

[ubrhn]

Hi Lain,
Thanks a lot for taking the time sharing your thoughts. The limitations of QtWidgets is actually the main reason why I'm looking for alternatives, our UI is now so complex (tons of windows/dialogs/widgets) that we're constantly hitting the limitations of widgets, preventing us to create really clear & nice UIs. But it sounds that you still hit these limitations even with heavy usage of stylesheets.

We also have the problem that our graphics subsystem (based on QGraphicsView/Scene) is not supported by QtQuick and thus needs to be rewritten from scratch.

Although the flexibility of QtQuick is great, it also has lots of downsides which I experienced during my first experiments. One thing giving me headaches is QtQuick Controls. Version 1.x seems to be well supported on desktop systems but it's obsolete and still misses some important controls. Version 2.x (which is completely different) provides more controls, but many of them without desktop support and/or requiring very latest Qt versions, which I don't like to depend on for portability reasons. So also lots of problems, just different problems compared to QtWidgets :-/ Thus at a first glance your approach of using stylesheets looked interesting (neat UI without requiring QtQuick).

Anyway, thanks again for your help and wish you good success with your awesome project!

 

[AaronD]

The perfect graphics environment doesn't exist. I started with Microsoft's .NET when it was still Windows-only, just because that's what my university used. Then I switched to Qt because it was cross-platform. Then I switched again to wxWidgets because of Qt's poorly-documented (even from experts on the forums) reliance on CSS, and because of the license. So far, I'm still on wxWidgets, but it hasn't really been very long yet.

 

[ubrhn]

The perfect graphics environment doesn't exist.

How true :-/

and because of the license

Yep, another difficult topic of Qt. I wish we could switch to something "less commercial" but our whole code base (not just the GUI) depends on it so that's basically impossible (~200k lines of code)...

 

[Lain]

our UI is now so complex (tons of windows/dialogs/widgets) that we're constantly hitting the limitations of widgets, preventing us to create really clear & nice UIs

Yea, that's happening to us as well. We had to implement lazy widget loading of certain situations. For example, our entire hotkeys section of our settings window only loads when you click on "Hotkeys" in our most recent versions to prevent having to create a million widgets. (That's partly our fault because we opted to create multiple widgets per hotkey per scene/source for our UI, which was a rather serious mistake in hindsight and not one we can easily redo any time soon)

Thus at a first glance your approach of using stylesheets looked interesting (neat UI without requiring QtQuick).

Yea, it's been a lot of work getting it the way we want, but don't get me wrong, QSS is still very nice and allows a lot of flexible customization. If your program is GPL2+, I'd say just yoink our stylesheets and adapt them to your preferences. just make sure to leave credit where credit is due of course and pay it forward if needed, and do tricks like lazy loading of widget panes to reduce window load times if you have a heckton of widgets in certain situations.

Another solution is to write all custom widgets and custom painting, but that's more involved and a whole heckton of work.

But if you find a more ideal solution, please share with us as well, because although we've made great strides with our UI, we would love to revamp our UI as well. However like you we're limited because we have our own custom graphics subsystem. And if we ever come up with a more ideal solution, I'll try my best to remember this post and post back letting you know.

But for the time being, QtWidgets still works well in spite of all its limitations. I'd recommend just sticking with it, customizing it best you can with custom widgets and QSS. Again, if you're GPL2+ compatible I'd say just yoink and adapt from us (with adequate attribution).

 

[ubrhn]

If your program is GPL2+, I'd say just yoink our stylesheets and adapt them to your preferences. just make sure to leave credit where credit is due of course and pay it forward if needed

Thanks, great to hear you'd be fine with that! :) Our software is GPLv3+ so that should be fine.

And if we ever come up with a more ideal solution, I'll try my best to remember this post and post back letting you know.

Cool, I'll try to remember as well!

So I think I'll still make some more experiments with QtQuick first, and giving a try to rewrite our graphics frameworks to plain OpenGL instead of using Qt for it (our software already contains some plain OpenGL drawing and actually it works quite good). Integrating plain OpenGL drawing into QtQuick should theoretically be possible so that might be a viable solution (but for sure requires a huge effort). I just hope the issues with QtQuick Controls 1.x/2.x can somehow be worked around...