Hi Gents, I cannot comment on the technical finesses of this discussion, but is it related to: https://hub.qgis.org/issues/13494#note-19 ?
Because I also bumped on some initialization problems during recent pyqgis experiments. My feeling was that those are related to the initialisation of the auth system (and QGIS in general) So I would applaud any energy put into this, now we can :-) Regards, Richard On 06-10-16 16:02, Matthias Kuhn wrote: > Hi Sandro, > > This sounds interesting. > What I wonder mostly is how much of the design and concept should be > imposed on customized apps. This forces either > > * custom apps to adjust to api changes in the app libarary > * the app library to guarantee api stability > > Not having to care for api stability in the app library currently allows > for much flexibility and speed in development. > > Something else is where the line between "custom" and "generic" is > drawn. QField (or roam which I don't know very well) are also custom > interfaces. I guess each one of these will draw their line at a > different level. For QField for example, anything that involves things > from the QtWidgets library is out of scope. > > Another approach would be to reimplement the QgisInterface instead of > the app. This specifically documents to be meant for 3rd party apps to > be reimplemented. > https://github.com/sourcepole/kadas-albireo/blob/master/src/gui/qgisinterface.h#L58-L62 > > Could you potentially split this up into multiple levels of > abstractions? Telling plugin developers that they can only use > functionality from the QgisTinyInterface if they want to be compatible > with everyone or use the QgisFullBlastInterface if it should be > fine-tuned for the QGIS classic app? > > If it helps to improve the channel from your developments back to > upstream, that will be much appreciated. > > All the best > Matthias > > On 10/06/2016 02:50 PM, Sandro Mani wrote: >> Hi >> >> We are considering porting our abstract GUI class from KADAS Albireo to >> QGIS 3.0, basically what was done here [1][2]. Summary is that qgisapp >> contains all functionalities which are gui-logic independent and >> qgsclassicapp contains the logic tying functionalities to the gui >> implementation. >> >> The advantages of this are, besides better code separation (which IMO >> qgisapp could benefit from since it's become a bit of a dumping ground), >> that it easier for people to write custom guis for QGIS (i.e. very >> application specific GUIs exposing only certain functionalities etc) >> while sharing the codebase with upstream. >> >> QGIS 3.0 would be a good moment to perform such refactoring. So I'd like >> to hear a short feedback whether people would welcome such a change in >> principle before moving on to drafting a QEP. >> >> Thanks >> Sandro >> >> [1] >> https://github.com/sourcepole/kadas-albireo/blob/master/src/app/qgisapp.h >> [2] >> https://github.com/sourcepole/kadas-albireo/blob/master/src/app/qgsclassicapp.h _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
