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.