Dockable widget gone AWOL
-
@Pl45m4 Is there any to prevent an undocked widget from being closed? Is it just a case of calling event->ignore() in the closeEvent() handler?
-
@Pl45m4 I thought that was just to prevent the X to close the widget from being displayed. I want to stop alt-F4 from closing it/
@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(); } -
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 Examplehas this implemented as @SGaist described.@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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()
