Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Hi Nyall On Wed, Jan 21, 2015 at 4:44 AM, Nyall Dawson nyall.daw...@gmail.com wrote: On 20 January 2015 at 09:22, Tim Sutton t...@kartoza.com wrote: Hi All @nyall - just referring back to your original part of this thread - could you please describe for us your preferred scenario with regards to Composer - Layout refactor and how it would relate to a LTR? For example would you rather see it in the LTR or happen after the LTR etc? I've come to the conclusion that the way to proceed is: If either 2.10 or 2.12 become QGIS 3.0, then target the layout engine work for 3.0. This includes removal of all existing composer API. If QGIS 3.0 is scheduled for 2.12, then the layout engine will land in parallel to the existing composer implementation. Composer will be deprecated but untouched, and users can manually switch from composer - layout engine via a combo box in QGIS settings. Default will be to use composer engine to avoid breaks. Obviously, if they choose to make the switch then existing plugins will break for them! When QGIS 3.0 lands the composer classes will all be removed. Thanks for your input! We will discuss 3.0 scheduling in the next PSC. For me it makes logical sense to do the LTR and then immediately move over to 3.0, but lets see how others feel at the meeting. I really hope we can avoid parallel implementations. Regards Tim Hope that helps clarify the situation! Nyall -- -- Tim Sutton Visit http://kartoza.com to find out about open source: * Desktop GIS programming services * Geospatial web development * GIS Training * Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net Tim is a member of the QGIS Project Steering Committee --- Kartoza is a merger between Linfiniti and Afrispatial ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
On 20 January 2015 at 09:22, Tim Sutton t...@kartoza.com wrote: Hi All @nyall - just referring back to your original part of this thread - could you please describe for us your preferred scenario with regards to Composer - Layout refactor and how it would relate to a LTR? For example would you rather see it in the LTR or happen after the LTR etc? I've come to the conclusion that the way to proceed is: If either 2.10 or 2.12 become QGIS 3.0, then target the layout engine work for 3.0. This includes removal of all existing composer API. If QGIS 3.0 is scheduled for 2.12, then the layout engine will land in parallel to the existing composer implementation. Composer will be deprecated but untouched, and users can manually switch from composer - layout engine via a combo box in QGIS settings. Default will be to use composer engine to avoid breaks. Obviously, if they choose to make the switch then existing plugins will break for them! When QGIS 3.0 lands the composer classes will all be removed. Hope that helps clarify the situation! Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Hi All @nyall - just referring back to your original part of this thread - could you please describe for us your preferred scenario with regards to Composer - Layout refactor and how it would relate to a LTR? For example would you rather see it in the LTR or happen after the LTR etc? Thanks Tim On Mon, Jan 19, 2015 at 11:23 PM, Matthias Kuhn matth...@opengis.ch wrote: On 01/18/2015 03:26 AM, Martin Dobias wrote: On Sun, Jan 18, 2015 at 3:59 AM, Nathan Woodrow madman...@gmail.com wrote: We have a import hook in place so it would be possible to have just import PyQt and handle which version is imported on our side however this is a bit magic and I'm not sure many people would like it. Stuff like this also breaks tooling because there is no PyQt module so most auto complete will not work. (I have tried this trick before to strip Qgs from the front of all classes on the fly) Agreed that adding magic to import PyQt4 or PyQt5 would not make things better. Plugin developers still would need to be aware of that and couldn't use new functionality from Qt5 anyway. QGIS 3 will supposedly introduce API cleanup, so the plugins will need to be adjusted anyway (some more, some less). That would not prevent devs from importing PyQt4 or PyQt5. It will only offer the possibility to write portable code. If somebody does not want this he can go ahead and directly import PyQt5 and use all the new features. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- -- Tim Sutton Visit http://kartoza.com to find out about open source: * Desktop GIS programming services * Geospatial web development * GIS Training * Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net Tim is a member of the QGIS Project Steering Committee --- Kartoza is a merger between Linfiniti and Afrispatial ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
On 01/18/2015 03:26 AM, Martin Dobias wrote: On Sun, Jan 18, 2015 at 3:59 AM, Nathan Woodrow madman...@gmail.com mailto:madman...@gmail.com wrote: We have a import hook in place so it would be possible to have just import PyQt and handle which version is imported on our side however this is a bit magic and I'm not sure many people would like it. Stuff like this also breaks tooling because there is no PyQt module so most auto complete will not work. (I have tried this trick before to strip Qgs from the front of all classes on the fly) Agreed that adding magic to import PyQt4 or PyQt5 would not make things better. Plugin developers still would need to be aware of that and couldn't use new functionality from Qt5 anyway. QGIS 3 will supposedly introduce API cleanup, so the plugins will need to be adjusted anyway (some more, some less). That would not prevent devs from importing PyQt4 or PyQt5. It will only offer the possibility to write portable code. If somebody does not want this he can go ahead and directly import PyQt5 and use all the new features. signature.asc Description: OpenPGP digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Hi, On Sat, Jan 17, 2015 at 11:19 AM, Richard Duivenvoorde rdmaili...@duif.net wrote: - no descision on 3.0 version taken yet - I think(!) that slight api changes for composer-code is allowed as somebody mentioned that that api is not so much used by plugins... As mentioned yesterday, I would rather not see soft api breaks between minor releases because I think it's confusing and messy when there could be clear rules that no api breaks are allowed between minor releases. It's a question of how safe devs and users feel to invest into developing tools for QGIS. if you ask me personally I would not make 2.10 a 3.0 version as to me it looks better to have another 2.x version after a LTR as backporting fixes will be much harder when we start breaking api immediately after a LTR. I agree and think that 2.12 could become 3.0 since there seems to be some level of agreement that the February release should be the LTR and conservative users might prefer a 3.2 LTR. I assume this should be discussed and decided on 26th. Best wishes, Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
If we are planning on doing a 3.0 I think it really needs to come with Python 3 and Qt5 on all platforms (We can't have Python 2.7 and Python 3, that is just going to lead to more pain I think). This is going to break all the plugins again, are we sure we can do that at this time? If so we need to be really prepared for it. - Nathan On Sat, Jan 17, 2015 at 8:42 PM, Anita Graser anitagra...@gmx.at wrote: Hi, On Sat, Jan 17, 2015 at 11:19 AM, Richard Duivenvoorde rdmaili...@duif.net wrote: - no descision on 3.0 version taken yet - I think(!) that slight api changes for composer-code is allowed as somebody mentioned that that api is not so much used by plugins... As mentioned yesterday, I would rather not see soft api breaks between minor releases because I think it's confusing and messy when there could be clear rules that no api breaks are allowed between minor releases. It's a question of how safe devs and users feel to invest into developing tools for QGIS. if you ask me personally I would not make 2.10 a 3.0 version as to me it looks better to have another 2.x version after a LTR as backporting fixes will be much harder when we start breaking api immediately after a LTR. I agree and think that 2.12 could become 3.0 since there seems to be some level of agreement that the February release should be the LTR and conservative users might prefer a 3.2 LTR. I assume this should be discussed and decided on 26th. Best wishes, Anita ___ Qgis-psc mailing list qgis-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-psc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
On Sat, Jan 17, 2015 at 12:36 PM, Alexander Bruy alexander.b...@gmail.com wrote: Agreed with Nathan, 3.0 should come with Pytrhon 3 and Qt5, or we will have QGIS 4 very soon after QGIS 3 Can you estimate a realistic time plan for these switches to new Python and Qt? Best wishes, Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
If I'm not wrong, support for Qt5 already added by Matthias. Regarding Python 3, I'm not sure about time plan, as in this case we depends on OSGeo4W update for Windows platform. 2015-01-17 16:27 GMT+02:00 Anita Graser anitagra...@gmx.at: On Sat, Jan 17, 2015 at 12:36 PM, Alexander Bruy alexander.b...@gmail.com wrote: Agreed with Nathan, 3.0 should come with Pytrhon 3 and Qt5, or we will have QGIS 4 very soon after QGIS 3 Can you estimate a realistic time plan for these switches to new Python and Qt? Best wishes, Anita -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Hi! Depending on the plugin there will surely be a lot of which will not operate after an update to python3. And depending on the developer they will be updated or abandoned. Some will be easy to update - some will be harder to update. But you are right - if the plugin will NOT be updated we would loose it for python3. regards Werner On Sat, Jan 17, 2015 at 5:28 PM, Anita Graser anitagra...@gmx.at wrote: Would the switch to Python 3 mean that we would loose access to all the useful Python modules which don't update? Thanks for taking the time to try clarify the situation! Best wishes Anita On Sat, Jan 17, 2015 at 4:16 PM, Alexander Bruy alexander.b...@gmail.com wrote: If I'm not wrong, support for Qt5 already added by Matthias. Regarding Python 3, I'm not sure about time plan, as in this case we depends on OSGeo4W update for Windows platform. 2015-01-17 16:27 GMT+02:00 Anita Graser anitagra...@gmx.at: On Sat, Jan 17, 2015 at 12:36 PM, Alexander Bruy alexander.b...@gmail.com wrote: Agreed with Nathan, 3.0 should come with Pytrhon 3 and Qt5, or we will have QGIS 4 very soon after QGIS 3 Can you estimate a realistic time plan for these switches to new Python and Qt? Best wishes, Anita -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Thanks Werner, I was actually thinking of dependencies such as Numpy, Matplotlib, and other Python packages and whether they will be available for Python 3. Best wishes, Anita On Sat, Jan 17, 2015 at 6:02 PM, Werner Macho werner.ma...@gmail.com wrote: Hi! Depending on the plugin there will surely be a lot of which will not operate after an update to python3. And depending on the developer they will be updated or abandoned. Some will be easy to update - some will be harder to update. But you are right - if the plugin will NOT be updated we would loose it for python3. regards Werner On Sat, Jan 17, 2015 at 5:28 PM, Anita Graser anitagra...@gmx.at wrote: Would the switch to Python 3 mean that we would loose access to all the useful Python modules which don't update? Thanks for taking the time to try clarify the situation! Best wishes Anita On Sat, Jan 17, 2015 at 4:16 PM, Alexander Bruy alexander.b...@gmail.com wrote: If I'm not wrong, support for Qt5 already added by Matthias. Regarding Python 3, I'm not sure about time plan, as in this case we depends on OSGeo4W update for Windows platform. 2015-01-17 16:27 GMT+02:00 Anita Graser anitagra...@gmx.at: On Sat, Jan 17, 2015 at 12:36 PM, Alexander Bruy alexander.b...@gmail.com wrote: Agreed with Nathan, 3.0 should come with Pytrhon 3 and Qt5, or we will have QGIS 4 very soon after QGIS 3 Can you estimate a realistic time plan for these switches to new Python and Qt? Best wishes, Anita -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Oh - sorry - I did not think of that but: Numpy Scipy http://www.scipy.org/scipylib/faq.html#do-numpy-and-scipy-support-python-3-x matplotlib http://matplotlib.org/users/whats_new.html I guess unless you use a _very_ specific module you are safe. At least I could not find any module I use which is not available in python3 regards Werner On Sat, Jan 17, 2015 at 7:06 PM, Anita Graser anitagra...@gmx.at wrote: Thanks Werner, I was actually thinking of dependencies such as Numpy, Matplotlib, and other Python packages and whether they will be available for Python 3. Best wishes, Anita On Sat, Jan 17, 2015 at 6:02 PM, Werner Macho werner.ma...@gmail.com wrote: Hi! Depending on the plugin there will surely be a lot of which will not operate after an update to python3. And depending on the developer they will be updated or abandoned. Some will be easy to update - some will be harder to update. But you are right - if the plugin will NOT be updated we would loose it for python3. regards Werner On Sat, Jan 17, 2015 at 5:28 PM, Anita Graser anitagra...@gmx.at wrote: Would the switch to Python 3 mean that we would loose access to all the useful Python modules which don't update? Thanks for taking the time to try clarify the situation! Best wishes Anita On Sat, Jan 17, 2015 at 4:16 PM, Alexander Bruy alexander.b...@gmail.com wrote: If I'm not wrong, support for Qt5 already added by Matthias. Regarding Python 3, I'm not sure about time plan, as in this case we depends on OSGeo4W update for Windows platform. 2015-01-17 16:27 GMT+02:00 Anita Graser anitagra...@gmx.at: On Sat, Jan 17, 2015 at 12:36 PM, Alexander Bruy alexander.b...@gmail.com wrote: Agreed with Nathan, 3.0 should come with Pytrhon 3 and Qt5, or we will have QGIS 4 very soon after QGIS 3 Can you estimate a realistic time plan for these switches to new Python and Qt? Best wishes, Anita -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Hi all, Sorry for the long mail but I think it is an important topic. Increasing the major version number is a rather big step and should be considered carefully. So before going into too many technical details (no worries, you find them below) I think it is important to have a clear idea why we would want that and what we expect from this move. In order to avoid another troublesome major version change (QGIS 4) for as long as possible. Qt 5 and Python 3 are IMO mandatory changes when QGIS 3 comes but they should not be the cause for it but rather dependencies of it. I thought that it would be a good idea to use the QEP process to handle this. We could create a label QGIS3 there which we could apply to QEPs that will require QGIS3. And another QEP specifically for QGIS 3, that lists other things to do (cleanup of deprecated API, Qt 5, Python 3...). Some ideas what could be labelled with QGIS3: * Composer - Layout * Database aware datasources (Make QGIS aware of datasources(providers/tables) on the same database. That would allow to better handle database dependent properties like foreign keys (which involve multiple tables). * Abstraction of the .qgs file structure. Now it depends on XML. A new project format including portable layers (memory saver) may use something different. Or stick to XML. * Geometry redesign (It's a rather big rework, I guess there will be some implications on the API leading to different behavior. I don't know it in detail and the roadmap) * [Your idea goes here] And now to the technical notes: I think that both Qt 5 and Python 3 are ready to be used. They are available for almost any platform and are can be considered stable. If we switch the major version number in QGIS to 3, they should be made a highly recommended dependency and developers should treat them as the main target. At least for Qt5 I can say that it is compatible to Qt4 to a very high degree. I think also for python it is possible to write code that works with python 2.7 and 3.x (The pandas module which is quite complex is compatible with both). That means, it should be possible to make plugins work independent of these versions. There is one thing however that causes me some headaches which is PyQt5. This must not be set equal with Qt5. It is possible to combine Qt5 with PyQt4 (Read that again!) [1]. With this combination all the above compatibility notes (should) apply. Upgrading to PyQt5 however comes with some caveats. PyQt5 removes all the deprecated things from Qt. That may affect some plugins. Even worse, it forces python plugins to change their imports. Instead of import PyQt4 one will have to write import PyQt5. Basically rendering all plugins incompatible. So we could consider to switch to Qt5 and keep PyQt4 and have an easy transition. However, I hardly doubt that every platform will offer this combination. Most distributions will probably do the obvious and bundle PyQt4 linked against Qt4 and PyQt5 linked against Qt5. This leaves us with the options: 1. Include PyQt4 in our sources (you may deduce my stance to this from the discussion here [2]) 2. Switch to PyQt5 and force all plugins to update Version 2 would render all plugins subsequently incompatible with QGIS 2 what would probably disappoint many. So I thought that python may be flexible enough to offer aliases for modules (is it, python experts?). So would it be possible to alias both - PyQt4 and PyQt5 - with PyQt? That way plugins could be updated with an easy search-and-replace to just import PyQt (and check for PyQt.version if required) and still have them work with QGIS 2 and QGIS 3. Regards, Matthias [1] http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html [2] https://github.com/qgis/QGIS/pull/1726 signature.asc Description: OpenPGP digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
We have a import hook in place so it would be possible to have just import PyQt and handle which version is imported on our side however this is a bit magic and I'm not sure many people would like it. Stuff like this also breaks tooling because there is no PyQt module so most auto complete will not work. (I have tried this trick before to strip Qgs from the front of all classes on the fly) I'm not sure there is a really good solution to this without breaking something or hacks. IMO using PyQt4 with Qt5 will just confuse people and like you said most platforms might drop that. Pro tip: This is a good reason to never name your modules with the version at the end. Nathan On Sun, 18 Jan 2015 5:47 am Matthias Kuhn matth...@opengis.ch wrote: Hi all, Sorry for the long mail but I think it is an important topic. Increasing the major version number is a rather big step and should be considered carefully. So before going into too many technical details (no worries, you find them below) I think it is important to have a clear idea why we would want that and what we expect from this move. In order to avoid another troublesome major version change (QGIS 4) for as long as possible. Qt 5 and Python 3 are IMO mandatory changes when QGIS 3 comes but they should not be the cause for it but rather dependencies of it. I thought that it would be a good idea to use the QEP process to handle this. We could create a label QGIS3 there which we could apply to QEPs that will require QGIS3. And another QEP specifically for QGIS 3, that lists other things to do (cleanup of deprecated API, Qt 5, Python 3...). Some ideas what could be labelled with QGIS3: * Composer - Layout * Database aware datasources (Make QGIS aware of datasources(providers/tables) on the same database. That would allow to better handle database dependent properties like foreign keys (which involve multiple tables). * Abstraction of the .qgs file structure. Now it depends on XML. A new project format including portable layers (memory saver) may use something different. Or stick to XML. * Geometry redesign (It's a rather big rework, I guess there will be some implications on the API leading to different behavior. I don't know it in detail and the roadmap) * [Your idea goes here] And now to the technical notes: I think that both Qt 5 and Python 3 are ready to be used. They are available for almost any platform and are can be considered stable. If we switch the major version number in QGIS to 3, they should be made a highly recommended dependency and developers should treat them as the main target. At least for Qt5 I can say that it is compatible to Qt4 to a very high degree. I think also for python it is possible to write code that works with python 2.7 and 3.x (The pandas module which is quite complex is compatible with both). That means, it should be possible to make plugins work independent of these versions. There is one thing however that causes me some headaches which is PyQt5. This must not be set equal with Qt5. It is possible to combine Qt5 with PyQt4 (Read that again!) [1]. With this combination all the above compatibility notes (should) apply. Upgrading to PyQt5 however comes with some caveats. PyQt5 removes all the deprecated things from Qt. That may affect some plugins. Even worse, it forces python plugins to change their imports. Instead of import PyQt4 one will have to write import PyQt5. Basically rendering all plugins incompatible. So we could consider to switch to Qt5 and keep PyQt4 and have an easy transition. However, I hardly doubt that every platform will offer this combination. Most distributions will probably do the obvious and bundle PyQt4 linked against Qt4 and PyQt5 linked against Qt5. This leaves us with the options: 1. Include PyQt4 in our sources (you may deduce my stance to this from the discussion here [2]) 2. Switch to PyQt5 and force all plugins to update Version 2 would render all plugins subsequently incompatible with QGIS 2 what would probably disappoint many. So I thought that python may be flexible enough to offer aliases for modules (is it, python experts?). So would it be possible to alias both - PyQt4 and PyQt5 - with PyQt? That way plugins could be updated with an easy search-and-replace to just import PyQt (and check for PyQt.version if required) and still have them work with QGIS 2 and QGIS 3. Regards, Matthias [1] http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html [2] https://github.com/qgis/QGIS/pull/1726 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
Right, python 3 has been around long enough the much of the python world has finally caught up. For those that can't get python 3 they'll just need to use the last QGIS 2.x release a little longer (there are still people running 1.8). Please file a ticket now with OSGeo4w to start preparing to include it, since there will be a time when both python 2 and 3 will be installed side-by-side. I'll suggest a Google Summer of Code proposal/call for student interns in OSGeo ICA labs for a project on porting plugins to python 3, and/or providing tools to plugin authors to help them port. Thanks, Alex On 01/17/2015 10:12 AM, Werner Macho wrote: Oh - sorry - I did not think of that but: Numpy Scipy http://www.scipy.org/scipylib/faq.html#do-numpy-and-scipy-support-python-3-x matplotlib http://matplotlib.org/users/whats_new.html I guess unless you use a _very_ specific module you are safe. At least I could not find any module I use which is not available in python3 regards Werner On Sat, Jan 17, 2015 at 7:06 PM, Anita Graser anitagra...@gmx.at wrote: Thanks Werner, I was actually thinking of dependencies such as Numpy, Matplotlib, and other Python packages and whether they will be available for Python 3. Best wishes, Anita On Sat, Jan 17, 2015 at 6:02 PM, Werner Macho werner.ma...@gmail.com wrote: Hi! Depending on the plugin there will surely be a lot of which will not operate after an update to python3. And depending on the developer they will be updated or abandoned. Some will be easy to update - some will be harder to update. But you are right - if the plugin will NOT be updated we would loose it for python3. regards Werner On Sat, Jan 17, 2015 at 5:28 PM, Anita Graser anitagra...@gmx.at wrote: Would the switch to Python 3 mean that we would loose access to all the useful Python modules which don't update? Thanks for taking the time to try clarify the situation! Best wishes Anita On Sat, Jan 17, 2015 at 4:16 PM, Alexander Bruy alexander.b...@gmail.com wrote: If I'm not wrong, support for Qt5 already added by Matthias. Regarding Python 3, I'm not sure about time plan, as in this case we depends on OSGeo4W update for Windows platform. 2015-01-17 16:27 GMT+02:00 Anita Graser anitagra...@gmx.at: On Sat, Jan 17, 2015 at 12:36 PM, Alexander Bruy alexander.b...@gmail.com wrote: Agreed with Nathan, 3.0 should come with Pytrhon 3 and Qt5, or we will have QGIS 4 very soon after QGIS 3 Can you estimate a realistic time plan for these switches to new Python and Qt? Best wishes, Anita -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1
On Sun, Jan 18, 2015 at 3:59 AM, Nathan Woodrow madman...@gmail.com wrote: We have a import hook in place so it would be possible to have just import PyQt and handle which version is imported on our side however this is a bit magic and I'm not sure many people would like it. Stuff like this also breaks tooling because there is no PyQt module so most auto complete will not work. (I have tried this trick before to strip Qgs from the front of all classes on the fly) Agreed that adding magic to import PyQt4 or PyQt5 would not make things better. Plugin developers still would need to be aware of that and couldn't use new functionality from Qt5 anyway. QGIS 3 will supposedly introduce API cleanup, so the plugins will need to be adjusted anyway (some more, some less). Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
