Hi Javier, The wiki is 'just' a github wiki. Can you try to edit it with your github credentials? Or create a github account for it?
If that fails, I'll try to copy your info in it. Regards, Richard Duivenvoorde On 11-01-18 09:44, Javier Becerra Elcinto wrote: > Hi Paolo, > > Thanks for the effort of setting up the wiki page, we have started > migrating some plugins and missed some kind of "standard" > guidelines/best practices. > > I was not able to find a way to contribute to the wiki, and could not > find an issue/forum associated with it - I do not know much about QGis' > team development workflow, so that there may be resources I am not aware > of (in that case, it might be a good idea to link them from the wiki?). > > So I guess this list is the way to go at the moment, I will share my two > cents based on our experience migrating to QGis3 (we have recently made > a pull request to complete the migration of profiletool plugin to QGis3 > https://github.com/PANOimagen/profiletool/commit/2631bc4600938d7beeaf6281bcb8de16a6de912c > and are working on other internal plugins): > > -We iniatially thought on creating a compatibility layer to allow Qgis2 > plugins to run (mostly?) unmodified on QGis3; however that seems like a > bad idea in the long term, and followed the monkey-patching strategy set > forth by opengis.ch in their qgis2compat plugin > (https://github.com/opengisch/qgis2compat). This means, we make all the > code qgis3 compatible, and patch QGis2 on runtime to provide Qgis3 api > compatibility. In the long term, dropping support for QGis2 should be as > simple as removing the apicompat module, the plugin's code would remain > unmodified to keep on running on QGis3. > > -Unfortunately qgis2compat has not been updated in the last 10 months, > and we do not want to add an additional dependency to the plugins, so > that we have included their apicompat files as needed and completed the > missing bits we found (e.g. QgsPointXY). We can contribute our additions > to Qgis2compat if someone is interested. > > -There are however some modifications that we have not been able to > manage with monkeypatching, for instance > PyQt4.QFileDialog.getOpenFilenames returns a list of files and > PyQt5.QFileDialog.getOpenFilenames returns a tuple with the list of > files and the extensions (i.e. PyQt5.QFileDialog.getOpenFilenames == > PyQt4.QFileDialog.getOpenFilenamesAndFilter); modifying PyQt4's > behaviour can lead to other plugins, who expect the proper PyQt4 api, to > stop working. We prefer not to introduce 'new' functions (i.e. > PyQtx.QFileDialog.getOpenFilenames5) that would not be neither PyQt4 nor > PyQt5, and the best option we have found is to check PyQt version or use > a try/except to manage compatibility. We do not like it, but it is the > least ugly solution we could find. If someone has a nicer/more > elegant/more pythonic solution we are willing to hear from you :) > > Regards, > > Javier > > > > El 09/01/2018 a las 11:17, Paolo Cavallini escribió: >> Il 09/01/2018 11:13, Werner Macho ha scritto: >>> Hi Paolo, >>> Good initiative! >>> I will contribute if I find anything important to say. ;) >> Thank you Werner. Any help will be useful, both in writing the guide and >> in testing and streamlining it. >> All the best. > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
