[QGIS-Developer] discuss: What's our development gameplan for 3.0 and above?

[Luigi Pirelli]

super +1, I follow the same rule.
We should add rule for that methods that require pyqt bindings... e.g.
any API should use and return QT containers (just to simplify type
mapping)
Luigi Pirelli

**************************************************************************************************
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**************************************************************************************************


On 9 November 2017 at 22:29, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> Hi all,
>
> I started a discussion at
> https://github.com/qgis/QGIS/pull/5559#issuecomment-342974170 but I'd
> like greater exposure for this discussion and more feedback, so that
> together we can determine what our preferred development approach is
> for 3.0 and up.
>
> The question is:
>
> ****
> Is it our preference to use Qt classes and methods wherever available,
> or should we use std algorithms or raw library methods instead?
> ****
>
> The question in that PR results from a choice of either using
> QSqlDatabase methods for accessing a sqlite database OR using some
> basic c++11 wrappers around the raw sqlite3 api.
>
>
> In general my current preference goes something like:
>
> 1. use std implementations
> 2. use qt classes only when they save us work or there's no alternative
>
> Personally I'm just slightly dubious of qt upstream's current ability
> to maintain the qt core and gui libraries, and would prefer to lessen
> our dependence on them (where it makes sense.. i.e. isn't causing us
> more work!)
>
> But I'd like to know everyone's thoughts here, so that we're all
> coordinated with our approaches. I'm happy to go with the consensus
> view here, and would prefer a common approach than a mix of approaches
> across the codebase.
>
> So what's your thoughts?
>
> Nyall
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer