Dockable widget gone AWOL
-
I sometimes get reports from users that they undocked one of the dockable widgets in my application and somehow it went missing (maybe the next time they started the application).
Are there any known issues around this or ways to get the widget back on screen or in its dock location?
The last person who reported the problem got back to me and said:
If you undock the sidebar you can close it with Alt+F4. Then it is gone and will not open again.
Thanks, David
-
Hi,
One thing you can do is have a menu with the toggle view action of each dock widget. That way they can hide and show them at will.
-
Your reported issue is normal behavior. Once you close (X or Alt F4) a dockwidget, it is hidden and by default you have no possibility to show it again using the GUI. This has to be done by code or with the help of the dockWidget's toggles.
The
DockWidgets Example
has this implemented as @SGaist described. -
@Perdrix I can confirm that on Windows at least, the following does not prevent the dock widget from being closed:
setFeatures(features() & ~QDockWidget::DockWidgetClosable);
To prevent it being closed it appears that you need to do this:
// // The user may not close the undocked window // void ExplorerBar::closeEvent(QCloseEvent* event) { event->ignore(); }
-
@Pl45m4 said:
Once you close (X or Alt F4) a dockwidget, it is hidden and by default you have no possibility to show it again using the GUI
That's not entirely true. If your main window has either a menu bar, tool bar or any other docks you can right click on any of them and a list of all dock windows will pop up. You can show the hidden docks from there.
I'd say don't block closing of the docks. That's working against user experience because you don't want to deal with it. Not a good thing. A proper way to handle this is make the reopening feature more discoverable. A usual way of dealing with it is providing a "Windows" menu with all the dock actions that let you toggle their visibility. That's what I would suggest. A dock already provides the actions and all the handling. All you have to do is put them in a menu.
-
@Chris-Kawa That sort of works for an application with a regular menu but for an application that doesn't have one:
then blocking the close action seems to make sense (at least for me):
-
@Perdrix Blocking close event means providing a button in UI that, from user's perspective, does nothing. No, that's not better. That's bad UX. Providing a way to restore the dock is the right thing to do.
-
@Chris-Kawa There's no close button on my dockable widgets so no possible confusion there.!
-
@Perdrix Note that your user complained that they can't restore the dock. Not that they can close it. The next issue reported by users will probably be that they can't close the dock now.
Anyway, no point in arguing. I think blocking the close is the wrong thing to do, but it's obviously your app, so it's up to you. You know the options.
-
@Chris-Kawa No actually, that is not the case.
The initial user complaint was that the left dockable window wasn't displayed and the user had no idea how it had "gone away". After quite a bit of experimentation, he discovered that Alt-F4 was the culprit and that line I quoted was from his email reporting that it was Alt-F4 that caused the problem. I have so far had this reported at least 5 times.
Once the widgets are undocked you can right click on their title bar until you are blue in the face and no menu to show/hide the dockable widgets is displayed. That only shows up (AFAICT) when the widgets are docked - I wasn't even aware that menu existed until now.
-
@Perdrix Really no point in arguing over this. It's a matter of opinion. If an app gave me a floating window I couldn't close, the next thing I would probably do is close it, uninstall and never look back. But that's me. Your app and your design - up to you.
-
@Chris-Kawa
How can I programmatically display that menu for app windows?Found it QMainWindow::createPopupMenu()