Add GUI specific classes for browser interaction #8352
Conversation
nyalldawson
added
the
API
|
@elpaso @wonder-sk Very keen for your feedback here! |
|
Wonderful! I'll check it out ASAP. |
|
Here's a rough Todo list:
|
|
QGIS 3.4 isn't even out yet and you are right into the next one :)
…On Sat, Oct 27, 2018 at 5:04 PM Nyall Dawson ***@***.***> wrote:
Here's a rough Todo list:
- move all actions out of core and to providers
- move hard coded actions out of the dock widget code
- move geonode specific actions to their own provider
- add handledrop method to gui providers
- move browser item widget handling to gui providers
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8352 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXS3EIiIAfw0FUXfcD1tOANXFEHHcGpks5upAWJgaJpZM4X9K4O>
.
|
nyalldawson
force-pushed
the
data_item_gui
branch
from
6e3451a
to
8e78833
Compare
|
@wonder-sk can I get your opinion here too please? |
nyalldawson
force-pushed
the
data_item_gui
branch
from
8e78833
to
c1e6421
Compare
|
Looking good - nice cleanup! Few thoughts:
|
I've thought about this, but I think they should be left to make the api easier for PyQGIS based items, where the mix of core/gui concepts is less harmful.
I think we should. At the moment QgsBrowserTreeView is a very basic class, only adding the persistence of expanded/collapsed state to QTreeView, and there's definetly potential to start moving the valuable stuff from the dock to the view. This would also benefit @elpaso's recent browser based dialog. I'll defer this to follow up PRs.
Totally theoretical. They "could"... whether they "should" is another question. But it is kind of nice for plugins have the potential to hook in here and mangle these menus however they see fit. With great power comes yadayadayada.
Yep. I considered adding a "priority" method to the API, but I'll leave that until we really need it. I can potentially see us wanting this when we want to ensure a logical ordering of menu items, and e.g. require some provider to be able to insert its items in between the items added by another provider. For now, it's probably enough to just do what's done here and process them in the order added. |
These providers will be used to control how the browser data items behave within GUI, and to allow separation of GUI related properties of browser items from the core code. A new registry QgsDataItemGuiProviderRegistry has been created (modeled off QgsDataItemProviderRegistry), with an application wide instance available from QgsGui::instance()->dataItemGuiProviderRegistry()
so that actions can operate on ALL selected items E.g. delete multiple layers from a geopackage at once
...by implementing dataItemGuiProviders()
And remove more QWidget imports from core library
With option to create a new geopackage or shapefile in the clicked directory
…ider And move handling of layer/project file double clicks in browser dock from gui->app
in browser With options to - load project - open project file properties (operating system file properties dialog that is, on supported platforms only)
No longer required, and of limited value anyway
nyalldawson
force-pushed
the
data_item_gui
branch
from
c1e6421
to
e936f4c
Compare
|
This all sounds good :-) |
This PR introduces a new method for populating the browser dock widget context menu, by adding a registry of QgsDataItemGuiProviders which can be used to populate and modify the right click context menu for items.
Currently, browser context menu population is an ugly mix of gui specific code sitting incorrectly within the core library (with the limitations associated with that, e.g. no access to QGIS gui widgets, message bar, etc), or specifically hard coded into the browser dock widget (not extensible, accessible by plugins, etc. Also no access to application library or provider libraries here because it's all done from the gui library).
This also addresses some shortcomings in the current API, by:
passing a context to the providers during menu creation, allowing actions to access properties like the message bar
passing a full list of selected items, allowing actions which operate on the complete selection (e.g. delete selected layers from geopackage)