[Qgis-developer] plugin for QGIS3 test

Matthias Kuhn matthias at opengis.ch
Tue Nov 1 00:17:54 PDT 2016


Hi Richard,

Thanks for the feedback, very interesting.

We have been working on a plugin qgis2compat [1] that aims at being a
legacy layer, so you have to maintain only a single plugin.

1. Migrate to QGIS 3
2. Add some code to load the compatibility layer
3. Add missing compatibility fixes in the qgis2compat plugin

This way one has to manage only a single - QGIS 3 compatible - plugin
and incompatible calls are routed transparently to the appropriate QGIS
2 API. Without any if-version-branches inside your plugin code, so once
the day comes you can just drop the qgis2compat plugin.

Main advantage:
 * maintain a single codebase (!!)
 * the code is clean and targetted at QGIS 3
 * the load for writing versioned calls can be mutualized between
   plugin developers

https://github.com/opengisch/qgis2compat

Cheers
Matthias

On 11/01/2016 08:03 AM, Richard Duivenvoorde wrote:
> On 31-10-16 23:15, Nyall Dawson wrote:
>> Given that you're probably the first to go through this process, I'm
>> very keen to hear any further feedback you have on the porting
>> process. What did you find hardest? Is the available api break
>> documentation useful? Could we make it better? Do you have any
>> suggestions on how we can make this process easier for plugin
>> developers?
> 
> One thing I learned:
> 
> - IF you make use of a plugin Makefile (if you created a plugin using
> the plugin builder), is to FIRST fix your make file (that is:
> - point to .qgis3 directory instead of .qgis2
> - change pyrcc4 an pyuic4 to pyrcc5 and pyuic5 in your makefile
> - make clean (to get rid of the Qt4-versions of your gui-py files and
> resources
> - run make again to have Qt5 versions of your gui-py's and resources
> - and THEN run [QGIS-repo]/scripts/2to3 <yourplugin sources>
> 
> Else you end up wondering why just half of your python files are 'fixed'
> by the script :-)
> 
> Other point to make:
> - as a lot of deprecated QGIS code is removed: remove all the switches
> you had for < 2.0 (if you have an old plugin :-) ), <2.6 etc etc
> versions of QGIS, as this cleans up nicely
> 
> - FIX all signal slot stuff to use the 'connect'/new way
> 
> - I only had a couple of QGIS-api changes. But that is maybe still coming...
> 
> - Often you can clean __init_.py (as that was used for the 'old'
> waymetadata (which is now in metadata.txt), and I had to keep that for
> very old QGIS version (my plugin should work from 1.8 onwards....)
> 
> - maybe some notes about the Qt-wrappers and the future script?
> 
> Some links to add: http://qgis.org/api/api_break.html
> And please add other api change links... I think we should put these on
> the frontpage of qgis.org.. I could not google them easy
> 
>> I'd also like to echo your disclaimer that it's premature for general
>> plugin developers to start porting their plugins yet (unless they
>> enjoy redoing changes!). There's still many more changes planned
>> before 3.0 is finalised.
> 
> hear hear
> 
> Regards,
> 
> Richard
> _______________________________________________
> 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
> 


More information about the Qgis-developer mailing list