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
[email protected]
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
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
_______________________________________________
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
