Bug report #14953
Properties dialogue box/window has no taskbar instance, causes problems
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | GUI | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Linux | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | up/downstream |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 22902 |
Description
When you open the layer properties, a dialogue box / window opens, initially not maximised. With most OS settings this will have its own titlebar and titlebar buttons - minimise, maximise etc. HOWEVER: this box does not generate its own taskbar instance, as if it were a full program. In my experience, that's the default & intuitive behaviour, even if the box is very minimal e.g. in window some boxes simply say "OK" and the only way you can interface with them other than clicking OK is to click elsewhere so they lose focus. They still generate a taskbar instance.
Because the properties box (and maybe other boxes) doesn't generate a taskbar instance, if one has set up their window manager to hide programs' frames & titles when maximised, if maximised the properties box cannot be interacted with via the taskbar (closed, right-click-unmaximised, etc) so the only way to interact with it is to close it. Furthermore, it seems possible - maybe by switching from a small laptop screen to a larger external monitor - for that box to be very small but still consider itself maximised, and thus be problematically small AND have no titlebar so be uninteractable by the user.
See attached picture: properties box is maximised and window manager tweaks of "hide maximised frames" and also "hide maximised titles" are both selected. These is no instance of the properties box in the taskbar, only Qgis main program. One is thus unable to resize the properties box to see the effects of any changes on the underlying maps in the main Qgis instance.
I believe this is a bug or at best improper behaviour, which would be solved if dialogue boxes spawned taskbar instances.
Thanks.
History
#1
Updated by Simon Dedman about 8 years ago
edit: manage plugins box is the same.
#2
Updated by Nyall Dawson about 8 years ago
- Resolution set to up/downstream
- Status changed from Open to Closed
This is an issue with qt dialogs and your desktop environment - it's nothing we can fix in QGIS itself.
#3
Updated by Simon Dedman about 8 years ago
- Status changed from Closed to Reopened
Hi Nyall, thanks for the response. Reopening for discussion.
Given that the properties/plugins/other dialog are anticipated to be more persistent than a simple click & close usage case, could it be that this type of dialog is perhaps a suboptimal choice?
There may be a simple enough solution, however. Reading from https://doc.qt.io/qt-4.8/qdialog.html:
"QDialog (and any other widget that has type Qt::Dialog) uses the parent widget slightly differently from other classes in Qt. A dialog is always a top-level widget, but if it has a parent, its default location is centered on top of the parent's top-level widget (if it is not top-level itself). It will also share the parent's taskbar entry.
Use the overload of the QWidget::setParent() function to change the ownership of a QDialog widget. This function allows you to explicitly set the window flags of the reparented widget; using the overloaded function will clear the window flags specifying the window-system properties for the widget (in particular it will reset the Qt::Dialog flag)."
I'm rather out of my depth here but this suggests it might be a relatively simple job to tweak these dialogs so that they spawn their own taskbar entry rather than sharing their parent's. I'm assuming that Qgis contains the code which specifies these are QDialog boxes and so forth? That info was also from qt4.8 which looks like it might be an old version - again, you guys know wildly more than me about this stuff!
Thanks again.
#4
Updated by Nyall Dawson about 8 years ago
It's not actually that simple - those dialogs are all designed to be modal, ie you CANNOT interact with other QGIS windows while they are open. You have to first close the dialog.
There's some progress towards moving parts of these dialogs to dock widgets (in 2.16 you can style maps using non-modal dock widgets), but other parts of those dialogs will always be modal by design.
#5
Updated by Simon Dedman about 8 years ago
Interesting - thanks for the reply. I wonder if this (always be modal by design) is something worth considering given the problematic issues it can cause/is causing. I may be a semi-exceptional usage case, but OTOH one never knows how many users get affected by the same issue and never find their way to the correct bug report.
- (In my opinion) The properties dialog intuitively lends itself to changing style elements, applying the changes and assessing the quality of the outputs in the background without closing the box. Being able to alt+tab back & forth between qgis main & dialog box would be an asset.
- The plugins dialog is less likely to be kept open, but both suffer the same problem when one manually sizes the box to a large size on a large external monitor then closes it, hence saving that size as the user-set window size, then later spawns a dialog on a smaller-screened laptop with external monitor disconnected: the box is bigger than the window and its size can't be edited because of the lack of taskbar entry.
- Similarly, one could maximise a dialog on a laptop screen, close it with the "ok" button, then spawn it again on an external monitor and the box will be tiny, unresizable, but ostensibly maximised so with no taskbar entry. This may be a separate bug but I assume it's related, and it would be fixed with this bugfix in any case. I did a full uninstall and this & the above problem was present when I got QGis up & running again.
It would be great if this could be addressed in some way. Possibly by giving the dialogs taskbar entries but having qgis-main generate an error sound and do nothing else if anything is clicked while the dialog is still open - much in the way that various windows programs used to / still do. Thanks again for you time.
#6
Updated by Matthias Kuhn about 8 years ago
- Status changed from Reopened to Closed
The style dock in 2.16 solves this problem with a dock widget. There are good reasons to use a modal dialog for some options and good reasons not to use a modal dialog for others.
Since the main issue seems to be resolved, I think this issue can be closed.
If there are other modal dialogs which should not be modal, please open specific issues mentioning which dialog and the reason why a modal dialog is not suitable (like you have done for the repeated configuration of styles).
Please also help to test the new style dock (Press F7 in a nightly build) and report if you find issues with it, so they can be fixed before the release.