One “add” button to rule them all
Reducing the number of “Add layer” buttons in the QGIS GUI is a commonly voiced wish. Multiple approaches have been discussed but no decision has been made so far. One idea is to use the existing browser functionality to replace the “Add layer” dialogs. Others are envisioning completely novel approaches.
Since the topic came up again today on Twitter, I decided to implement a quick & dirty version of a unified Add layer button. This way, I can comfortably reduce my Layer toolbar to three buttons using Settings | Customization …
I pretty much just kept the “Create new layer” button and the “Add delimited text layer” button because, as far as I know, there is no way to call the dialog from the browser. (Instead, CSVs are opened with OGR, which doesn’t have nearly as many nice features.)
And here it is in action:
(I recommend to undock the Browser panel to get the dialog-like behavior that you see in the video.)
To install the plugin: download it and unzip it into your QGIS plugin folder, then activate it in the plugin manager.
I would love to hear what you think about this UX experiment.
Nice, the browser really is a very quick unified add layer interface which is already available out of the box.
Do you already have ideas how to integrate advanced options which are currently available from the add layer dialogs?
An alternative would also be to open up a single dialog with a combobox to chose the provider type and depending on this choice specific settings. Have you thought about this too?
One could open advanced dialogs from the file/table context menu in browser.
Combobox with providers sounds much more complicated – “wtf is a provider” 😉 – and adds extra steps to the process of adding layers.
There are probably a few more things to keep in mind (which already may be solved and I just didn’t notice).
Additional view options.
E.g. How to show/hide non-spatial postgres tables in the tree view in an intuitive, non-intrusive way?
E.g. the postgres option “Select at id”, no reason for most users to bother with it but experts may want to set it. This options could always pop up when adding layers, be hidden in a context menu “advanced add”, be all moved to the layer properties so they can be set later on.
Some of them can be overridden later on (e.g. CRS), so no big deal.
Setting a primary key for a postgres view is required. So some kind of dialog needs to popup and ask for this information (or is that already done now?)
One more thing is “batch adding”. When you add 30 layers from the same DB with some optional options, the table view which is on the add layer page is really handy.
You are also dealing with providers now in the layer tree, I don’t think there is much difference in clicks and in notion between the toplevel layer tree provider groups and the same in a combobox, is there? But it’s just another option, I do like the browser idea.
Very good points! Some of them could be covered by keeping the current dialog as an advanced option.
(The PG view keys/ids have been bugging me for a while.)
These issues – and probably some more – are the reason why this change is not ready for core. We’ll probably realize more shortcomings while trying to work with this plugin implementation. For now, there is always the fallback solution using the old dialogs from the layer menu.
I wonder which solution we will end up with for 3.0.
This is a great idea, thanks a lot! Actually it is quite similar to the open dialog in ArcMap where you can access all data sources using one button. It could be interesting to add a similar dialog for saving layers/tables.
It would be even better with an improved browser where users could directly see the content of geopackages, geodatabases, etc. It would be nice to be able to add QLR files, too.
Thank you Jerome! Could you elaborate on what you think is needed for saving?
I was thinking about adding a similar browser dialog for “Save vector layer as” (or for any tool producing a new layer/table, for example Processing outputs). This would allow people to easily save layers using other providers (e.g., GeoPackage layer saved as a PostGIS table).
But this would surely requires deeper changes in QGIS…