Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Model/View and Dock Widgets: a menu conundrum
I want to use dock widgets to manage model/view documents, one document per dock. I am looking for the best practice for placement of document-related menu items, i.e. "new/open/close/save/save as". In my
QMainWindowFile menu I can easily add the "new/open" menu items and create empty or populated dock widgets, as needed. The issue is the "close/save/save as" menu items. Am I forced to use context menus within the dock widget itself? By this I mean there is no analog to
QMDIArea::subWindowActivated, a convenient hook on which to update the main menu when using MDI. Managing documents within dock widgets, requires a different approach. What is the best practice here? Context menus?
No you are not. You can manage them with the "current active document" paradigm. The menu slots shall act on the currently active area/widget/etc.
@SGaist I recognize that I have to code something here -- on what dock event would I alter the current document? A dock widget raise event?
What kind of document do you have ?
Phil K last edited by Phil K
I will probably save the model data to a json format, but that is tangential to the UI question. If, for example, I have 5 dock widgets open, 2 are tabbed, 2 are floating and 1 is invisible, what is the "current document" in that context? I guess I could reimplement QDockWidget's
changeEventand look for an activation change event or something similar.
So you have one active dock at a time. Rather than focusing on the dock itself, it should rather be its widget that notifies that is has been modified as well as become the target of your menus/actions.
OK, so I just connected
QApplication::focusChangeto a slot in the main window where I ask the question "is the widget that now has focus a view of the type I am interested in?" If yes, I change the related menus accordingly. The "Ah Ha!" moment for me indeed was to think about the views, not the docks. I first tried installing an event filter on the views to look for
FocusInevents, which works, but even that is unnecessary given the
focusChangeapi available from the QApplication.