Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
GUI design opinion
agarny last edited by
Hi, I am currently trying to come up with a GUI solution for my application. Basically, my application can open one or several files. My application works in three different modes and then, within each mode, I can have one or several ways of interacting with a particular file (I call those ways: views).
So, the way I am currently thinking of it is by having a QGridLayout with has two rows and two columns:
- r0c0: a QTabWidget used to select the mode in which I want to operate;
- r0c1: a QTabWidget which is used to display different files depending on the mode and view selected;
- r1c0: nothing; and
- r1c1: a QTabWidget which tabs depend on the selected mode (see row 1, column 1), and which is used to select a particular view for the file.
Though I am happy with the overall GUI design (opinions on it are still welcome though!), I have two issues related to the use of a QTabWidget object in r0c0 and r1c1. Indeed, what is of interest to me in those QTabWidget objects are the tabs themselves, not the contents. This is why the size policy of those two objects is set to Minimum so that we 'only' see the tabs and nothing more. However, this doesn't quite work as I would like. I mean that if you look at the first attachment:
You will see that the two QTabWidget objects render a 'bar' to the right / above the tabs. Also, there is a gap between r0c0 and r0c1, and r1c1 and r0c1. Ideally, both of those bars and the gap wouldn't be there... i.e. something similar to the second attachment (after manually editing the first attachment):
So, my question is how would you personally go about doing what I am after?...
andre last edited by
First of all, I think you were looking for the QTabBar widget, not the QTabWidget. That widget just displays the bar of tabs itself, without bothering with any contents.
Then, I think your design is overly complex. The sheer number of tabs that do different things is going to be overwhelming for a user. Perhaps you can look at Qt Creator for inspiration on other ways you can get rid of that. What you might do, is something like:
- Have a number of buttons on the left like you have in Creator. These could represent the modes of your application. Because there are only three, it could just be three buttons next to each other in the top left.
- Under (or, if you follow Qt Creator, next to) those mode buttons, you create a list of open files. This will allow your user to switch files, and the UI will allow for more open files than using tabs (which don't work well for scenario's where you might need many of them).
- Then, the main area is reserved for a view area with tabs for each of the views, but all related to the current file.
In such a design, there is only one row of tabs visible, and there can be no confusion what they do. The list of open files is a method that is used more often, and will thus be familiar to your users. The mode buttons may need some explaining or some subtle hint somewhere else to communicate clearly to your users.
agarny last edited by
Thanks, I didn't know about QTabBar. That's one of the problems that I have with Qt Creator which is that the Design mode doesn't give access to some widgets and QTabBar is one of them...
Regarding the design itself, having mentioned Qt Creator above, I am obviously familiar with it. I don't, however, fancy buttons for the modes or, rather, not in the way it has been done in Qt Creator. They take too much space (and the more space I have the better), hence I thought of using some sideways text. Should that sideways text be a button, a tab or whatever doesn't really matter to me, as long as it takes as little space as possible.
As for the list open files, the issue I have with this is that once again it does take a lot of GUI space, especially if you have only a handful of files open (which tends to be the norm for the kind of application I am working on). In fact, another similar application I was working did it that way and people complained about it for the reason I just gave. Hence, it was thought best to have a QTabWidget in r0c1.
Anyway, I am still testing things, so will see how it goes...