On Tue, 8 Mar 2022 at 07:23, Schmetzer, Tobias <tobias.schmet...@zae-bayern.de> wrote: > > > Again, none of the core classes are allowed any GUI component, and the > > correct approach to handle this particular situation is to move that code > > from the provider level up to app level, specifically via the > > QgsDataItemGuiProvider class. > > > I had a look into it. If I understood it correctly the class provides a > framework for functions to be registered and called by other functions placed > in the gui. > > But what to do when a progress dialog needs to be raised or an application > state needs to be read? (see description below) > > > > So my question would be: why do you need to raise a user-facing message > > from QgsOgrProvider::extent? > > > - One idea was is to inform the user via a simple progress dialog in cases of > very time-consuming extent calculations for large layers (I observed calc > time ranges from 10 min to hours) of what's going on and that QGIS hasn't > crashed yet. The design would practically allow this to be implemented in the > provider . If that's also not how it is intended to be then I'd appreciate a > quick hint of how it is intended to be.
Offhand, there's a couple of ways to approach something like this: 1. You add appropriate signals in the core classes which are emitted at useful stages, e.g. "aboutToCalculateExtent", "extentCalculationProgressChanged", "extentCalculationComplete". And then the app/gui classes can listen out for these signals and respond to them appropriately, i.e. by showing a progress bar somewhere. 2. You could add a QgsFeedback* argument to the costly method, and use that to report progress and support early cancellation. (2 is a more flexible, "better" approach, but depending on the method you may not be able to add this to an existing method without breaking stable API. > and I also saw the use of QProgressDialog in other parts of the core > components code That's likely just outdated code which hasn't been removed yet. > > > - The second idea was to display an additional message dependant on the > current QGIS instance's project state (whether it's > loading/loaded/saving/closed) for which I had planned to introduce an enum > QgisApp::ProjectState alongside with a private variable mProjectState and a > public function QgisApp::getProjectState(). So would I make this accessible > to the provider? That property sounds potentially useful! (Just a note that QGIS code convention is to name a getter "projectState()", not "getProjectState(). We follow Qt conventions for naming as much as possible). But... (there's always a catch!) You can't (well, shouldn't) access QgsProject from a data provider*. So you'd need to change the behaviour at a higher level based on the project state instead. (e.g. by not calling some expensive method which can be deferred from the app level code) Nyall * the virtual data provider does this, but it's special, and really shouldn't anyway. > > > Best regards > > Tobias > > -- > > ZAE Bayern > Dipl.-Ing. Tobias Schmetzer > Systementwicklung | Systems Engineering > Bereich Energiespeicherung | Division Energy Storage > Walther-Meißner-Straße 6 > 85748 Garching > > Tel.: +49 89 329442-65 > Fax: +49 89 329442-12 > Mobil | Cell: +49 151 56964756 > tobias.schmet...@zae-bayern.de > https://www.zae-bayern.de > > ZAE Bayern > Bayerisches Zentrum für Angewandte Energieforschung e. V. | Bavarian Center > for Applied Energy Research > Vorstand | Board: Dr. Andreas Hauer (Vorsitzender | Chairman), Dr. Hans-Peter > Ebert > Sitz | Registered Office: Würzburg > Registergericht | Register Court: Amtsgericht Würzburg > Registernummer | Register Number: VR 1386 > > Hinweise zum Datenschutz unter https://www.zae-bayern.de/datenschutz > > > > ________________________________ > Von: Nyall Dawson <nyall.daw...@gmail.com> > Gesendet: Montag, 7. März 2022 00:03 > An: Schmetzer, Tobias > Cc: qgis-developer@lists.osgeo.org > Betreff: Re: [QGIS-Developer] How to access QgisApp::instance() from a core > class > > On Sun, 6 Mar 2022 at 00:16, Schmetzer, Tobias via QGIS-Developer > <qgis-developer@lists.osgeo.org> wrote: > > > > Hello everyone, > > > > > > I would like to access QgisApp::instance() (src/app/qgisapp.cpp) from a > > provider like QgsOgrProvider::extent() > > (src/core/providers/ogr/qgsogrprovider.cpp. > > You can't, by design. > > CORE classes must be completely non-gui, so that they work without > issue on non-gui platforms like QGIS server (also for clients which > have their own GUI, such as QFIeld/Input). > > Just to be super-blunt: There is 100% no way this will EVER change! ;) > > > > When looking for this information I found some inactivating preprocessor > > code block comments like this one (qgswfsdataitems.cpp): > > > > #if 0 > > > > // TODO: how to emit message from provider (which does not know about > > QgisApp) > > QgisApp::instance()->messageBar()->pushMessage( tr( "Cannot copy style" > > ), > > errorMsg, > > Qgis::MessageLevel::Critical, messageTimeout() ); > > #endif > > This is very old code (hence why it's disabled). Again, none of the > core classes are allowed any GUI component, and the correct approach > to handle this particular situation is to move that code from the > provider level up to app level, specifically via the > QgsDataItemGuiProvider class. > > So my question would be: why do you need to raise a user-facing > message from QgsOgrProvider::extent? > > Nyall _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
