5

Will these plugins no longer be available in QGIS 2.0.1?

7

All plugins have to be rewritten to work with the new API.

If the authors did not do that yet, the plugins do not appear in the current plugin list. Some authors have added plugins and don't care about them anymore, or didn't get the message about the necessary update.

A kind request to the authors might help to get them back to the list.

  • 6
    ESRI has repeatedly, over many decades, made the same mistake: When you change your platform enough that all add-ins have to be rewritten, you ruin the good work of all users who contributed them. After you do that enough times (once is usually enough), smart users will learn that it is unproductive to write add-ins at all and you are left mainly with code contributed by unwitting neophytes. Do not underestimate the long-term value of a stable platform and reverse compatibility! – whuber Sep 18 '13 at 14:37
  • 4
    Well, ESRI has survived that mistake for decades, while QGIS is still quite young and growing fast ;-) – AndreJ Sep 18 '13 at 14:40
  • 3
    'Mistake' and 'strategic error'? More like 'Catch-22.' In many instances, the plugin code can be reduced. Changes in the PyQt4 handling of strings and QVariants are very convenient to plugin writers, and were necessary to keep updated with changes in PyQt. The API for accessing features were significantly updated, allowing for much simpler access to feature attribute fields. These changes were not taken lightly by the QGIS developers; and, the 2.0 release was delayed since both API changes would prompt plugin code updates. – dakcarto Sep 18 '13 at 20:27
  • 3
    @whuber consider it a forced hand. We will be updating to Python 3 at some stage during the life of QGIS and PtQt4 would force switch to version 2 which would break even more plugins. The API change was also needed for multithreading. We decided to do it now when there isn't so many plugins in order to reduce that pain. I very much doubt this kind of thing will happen again as there is no version 3 PyQt or anything that would require massive code changes. See nathanw.net/2013/06/13/new-qgis-20-api for more details. – Nathan W Sep 18 '13 at 21:10
  • 3
    I took the lead on that change and pushed the final commit to switch. Trust me I spent about a week looking for a way to be backwards compatible. In the end there was just no good and clean way to do it and I feel that would have hurt more then switching to a better API. The other thing to note here is all QGIS plugins are GPL. The licence removes the higher risk of something just getting left to die because if you want/need it bad enough it can be fixed yourself or a by a dev and pushed back up I have already done this with other peoples plugins when we changed the API. – Nathan W Sep 18 '13 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.