[Qgis-developer] Abstract GUI base class

[Sandro Mani]

Hi Matthias

Personally I think it's okay to force custom apps to adapt to the app 
library changes, the effort of doing so is way smaller than having to 
port the app abstraction from release to release.

As for where the line is drawn: this proposal would mean one can go as 
far as swap the main QMainWindow with a custom implementation. I don't 
know if it makes sense drawing the line at another level?

As for QQgisInterface re-implementation: I'm not sure I see how one 
could swap out the main window with that approach, besides hiding the 
"classic" app main window constructed in main.cpp and killing of any 
signals that may interact with it - am I missing something?

Best
Sandro



On 06.10.2016 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
>> 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
> _______________________________________________
> 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