[Qgis-developer] Abstract GUI base class

[Matthias Kuhn]

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
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer