<div dir="ltr">Hi Peter,<div><br></div><div>Indeed the QgsQuick library is mostly an externalized library for input at the moment and I can understand the reasons for coming forward with this proposal.<br></div><div><br></div><div>One of the reasons for not picking it up completely in QField was that some of the included components have been under heavy development on QField side too, sometimes with app specific changes.</div><div><br></div><div>However there are some core parts which can be well mutualized and a collaboration was envisioned on QField side too.</div><div>They are kept in a dedicated folder in the QField repository <a href="https://github.com/opengisch/QField/tree/master/src/core/qgsquick">https://github.com/opengisch/QField/tree/master/src/core/qgsquick</a></div><div><br></div><div>I think keeping these in place would be good, this way we can preserve a nucleus of a generic library. If you are ok with that, we'll make sure to integrate the latest changes from the QField repository soon.</div><div><br></div><div>Thank you</div><div>Matthias</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 9:51 AM Peter Petrik <<a href="mailto:peter.petrik@lutraconsulting.co.uk">peter.petrik@lutraconsulting.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi devs, <div><br></div><div>I will be removing QgsQuick library related pieces from the qgis/QGIS repository if there are no strong objections. </div><div><br></div><div>The reasons are:</div><div>- the release cycle for QgsQuick is different than QGIS core, more based on the InputApp releases</div><div>- QgsQuick is not used by other projects but InputApp despite being on master for few years (as far as I know)</div><div>- In case we would like to use Qt QML in QGIS desktop, we will probably need different QML classes than for mobile devices (e.g. on mobile devices you do not edit form config, etc) anyways</div><div>- QgsQuick library is not shipped with the regular QGIS packaging system, not build/tested in the CI mostly (e.g. the tests on master are coredumping ATM), so it doesn't really matured to the common QML library</div><div>- There is an extra maintenance of the QgsQuick (pull requests in qgis/QGIS, CI setup, code maintenance, test runs) for the QGIS developers and to the QGIS infrastructure as such.<br></div><div>- There is quite a maintenance cost of Lutra Team to backport the changes from Input back to qgis/QGIS, keep the code in sync, test and in general use a library+application split when not necessary.</div><div><br></div><div>Therefore we do not see the reasons why to spend extra time on the community and us to maintain this bit. The code will be still present in the <a href="https://github.com/lutraconsulting/input" target="_blank">https://github.com/lutraconsulting/input</a> open-source project, so in case other Qt/QGIS related mobile projects would like to build something on top of it, we would be happy to cooperate. </div><div><br></div><div>Cheers,</div><div>Peter</div></div></div>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>