Model/View and Dock Widgets: a menu conundrum

[Phil K]

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 QMainWindow File 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?

[SGaist]

Hi,

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.

[Phil K]

@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?

[SGaist]

What kind of document do you have ?

[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 changeEvent and look for an activation change event or something similar.

[SGaist]

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.

[Phil K]

OK, so I just connected QApplication::focusChange to 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 FocusIn events, which works, but even that is unnecessary given the focusChange api available from the QApplication.