[Qgis-developer] Abstract GUI base class

[Richard Duivenvoorde]

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