Re: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit)
On Dienstag, 2. Oktober 2018 14:47:42 CEST Alex Blasche wrote: > Hi, > > We had this discussion for Qt 5.11 already but it is time to decide for Qt > 5.12. The discussion details can be found under > > https://bugreports.qt.io/browse/QTBUG-63708 > > Based on download figures and dropped MSVC2015 support for webengine we plan > to change MSVC2015 32bit binaries over to MSVC2017 32bit. I realize this > will not be happy news for everybody but considering the LTS implications > of Qt 5.12 it makes sense. Nevertheless if you believe you have strong > counter arguments please comment on the issue in Jira. > Would it be possible to just replace 32bit MSVC2015 with 32bit MSVC2017 on the CIs that test the individual modules, but keep both for qt5.git if we have the resources for it? `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit)
Wasn't it decided it was not the time to switch? Saying for myself - this will will likely see me not upgrade Qt distro until at least 6.0 once your suggested change hits.. On Tue, Oct 2, 2018 at 3:47 PM Alex Blasche wrote: > Hi, > > We had this discussion for Qt 5.11 already but it is time to decide for Qt > 5.12. The discussion details can be found under > > https://bugreports.qt.io/browse/QTBUG-63708 > > Based on download figures and dropped MSVC2015 support for webengine we > plan to change MSVC2015 32bit binaries over to MSVC2017 32bit. I realize > this will not be happy news for everybody but considering the LTS > implications of Qt 5.12 it makes sense. Nevertheless if you believe you > have strong counter arguments please comment on the issue in Jira. > > Thank you. > -- > Alex > > P.S. This does *not* mean that we drop 32bit for MSVC2015 support. We > merely drop the pre-built binary offering in our installer. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting a wip/qt6 branch for QtSerialBus
Hi Oswald, > the more pragmatic approach is to "hide" the qt6 variant behind ifdefs. If that is the "official" way, fine with me. > note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) > which does effectively the same, but to activate it you would need to > change .qmake.conf instead of just calling configure -qt6. Ok, I'll try this next time, seems like a sensible solution. I've also played a bit with the comment hjk gave me in [1] and it seems some of the changes can even be done for Qt5 - which is even better. I hereby declare that for now I don't need a wip branch, as enough other possiblities exist. Thanks for your time. Regards, André [1] https://bugreports.qt.io/browse/QTBUG-64145 Am 02.10.2018 um 13:08 schrieb Oswald Buddenhagen: On Tue, Oct 02, 2018 at 10:37:24AM +0200, André Hartmann wrote: I allready have some ideas for QCanBusDevice which requires binary-incompatible changes and therefore needs to be done for Qt6 [1]. To be able to already start the work, I'm hereby requesting a wip branch that could be merged when the "real" Qt6 development begins. The advantage would be, that others could already pick up that changes and test them, which hopefully will improve the code quality. the more pragmatic approach is to "hide" the qt6 variant behind ifdefs. in fact, the introduction of a respective configure feature (so you would #if QT_CONFIG(qt6)) has been on the table for quite a while already, but nobody pushed for it yet, presumably because we haven't officially started qt6 yet. note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) which does effectively the same, but to activate it you would need to change .qmake.conf instead of just calling configure -qt6. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 3D Maintainership
Hi all, I'd also like to say a big thank you for all the work you have put into Qt 3D. It is a great graphics API and is getting better with each release. I would be more than happy to be a co-maintainer of Qt 3D Render and will also help out with Qt 3D Core and the other modules. I agree with Laszlo that it is a good idea to sync up on the future of Qt 3D and the Qt graphics stack. We need a clear vision of what the scope of Qt 3D should be and how we should handle existing and new features that fall both inside and outside of this scope. As we add support for more backends, we also need to decide on how much of the underlying graphics API, such as OpenGL flags, should be abstracted away. The transition to Qt 6 is a good opportunity to make some changes in this area. It will be great to have a unified 2D-3D engine that can run on top of the different graphics backends and be a flexible foundation for both Qt Quick's Scene Graph, Qt 3D Studio, and other modules like Qt Charts and Qt Data Visualization. Cheers, Svenn-Arne On 14. sep. 2018 15:52, Laszlo Agocs wrote: > Hi guys, > > Thanks, Qt 3D is almost certainly going to be an important piece in Qt 6. > Once the dust settles and we have a clear view of the new maintainership > structure, we should definitely sync up on the state of things and plan a bit > ahead since there's plenty to be done and think about, especially with Qt 6 > and its potentially unified 2D-3D engines in mind. (renderer optimizations, > graphics API abstractions (RHI), shader graphs, some new features of course, > , fun times ahead :) ) > > Cheers, > Laszlo > > -Original Message- > From: Development On > Behalf Of Lars Knoll > Sent: fredag 14. september 2018 14.50 > To: Tuukka Turunen > Cc: Qt development mailing list ; Sean Harmer > > Subject: Re: [Development] Qt 3D Maintainership > > Hi Sean, > > First of all thank you for all the great work on Qt 3D over the last years. > Qt 3D has become a very important part of Qt, and I believe that parts of it > will get a much more central role in our graphics stack when we move towards > Qt 6. > > I’ve been discussing a bit with the graphics team in Oslo, and I think the > idea of having Laszlo as a co-maintainer is good. I would also like to > propose that we have Svenn-Arne as the co-maintainer for the renderer > component. He’s been doing a lot of good work in that area over the last year. > > We’re also trying to find candidates to help with some of the other modules, > and I hope we’ll at least one more person we can nominate there next week. > > Cheers, > Lars > > >> On 14 Sep 2018, at 12:47, Tuukka Turunen wrote: >> >> >> Hi Sean, >> >> Yes, Qt 3D certainly growing both in size and importance. Happily also the >> number of people working on it has been growing nicely. >> >> In addition to you and Paul, I believe we should be able to find 1-2 >> additional from developers of The Qt Company working on Qt 3D. >> >> Would it be possible to have someone from KDAB to maintain Qt 3D Extras? >> That is an area we have not touched that much. >> >> Yours, >> >> Tuukka >> >> On 14/09/2018, 13.29, "Development on behalf of Sean Harmer via >> Development" > behalf of development@qt-project.org> wrote: >> >> Hi All, >> >> my time available for Qt 3D outside of work, has as of late, been >> reduced due to increased family commitments - the good kind, but time >> consuming nonetheless. >> >> Given how Qt 3D has grown from our simple experiments in making 3D >> possible with Qt to the highly-configurable, multi-module, data >> processing monster it is today I feel it is no longer possible, nor >> wise, for me to maintain alone. Additionally, it looks as if Qt 3D will >> form an important piece of the graphics stack for Qt 6. >> >> As such I would like to propose that we split the maintainership and I >> would propose that Laszlo Agocs becomes co-maintainer. I am still happy >> to co-maintain and I have plenty of ideas about improvements we can make >> both within the Qt5 and Qt 6 time frames. We have learned a lot whilst >> developing Qt 3D and I think we can make it even better for Qt 6. >> >> I would also suggest that we find maintainers or co-maintainers for the >> sub-modules. I would propose Paul Lemire as (co-)maintainer for the >> render module. I'm happy to keep driving the animation module and help >> with qt3dcore. Other nominations are of course welcome. >> >> Kind regards and have a great weekend, >> >> Sean >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >
[Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit)
Hi, We had this discussion for Qt 5.11 already but it is time to decide for Qt 5.12. The discussion details can be found under https://bugreports.qt.io/browse/QTBUG-63708 Based on download figures and dropped MSVC2015 support for webengine we plan to change MSVC2015 32bit binaries over to MSVC2017 32bit. I realize this will not be happy news for everybody but considering the LTS implications of Qt 5.12 it makes sense. Nevertheless if you believe you have strong counter arguments please comment on the issue in Jira. Thank you. -- Alex P.S. This does *not* mean that we drop 32bit for MSVC2015 support. We merely drop the pre-built binary offering in our installer. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Windows, OpenGL ES and large textures
Greeting Qt enthusiasts and ex-trolls, I'm building multimedia software on Windows with Qt + libVLC and recently switched to the OpenGL ES backend (setAttribute(Qt::AA_UseOpenGLES)). Coming from the Desktop OpenGL I immediately noticed how smooth it was at resizing windows, and it felt like the proper way to go. Unfortunately when playing a 1440p / 60fps video the CPU usage increases and the rendering gets slower, like way slower than classic OpenGL. Is there a flag or some configuration to alter OpenGL ES behavior with larger textures that update frequently ? Maybe I'm doing my texturing "wrongly", you can review my shader for blending images here: https://github.com/omega-gg/Sky/blob/master/src/SkMedia/src/media/WBackendVlc.cpp#L371 Many thanks, -- Benjamin Arnaud ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] HEADS-UP: Branching from '5.9' to '5.9.7' complete
Hi! Branching from '5.9' -> '5.9.7' is now ready. From now on all changes targeted to Qt 5.9.7 release must be done in '5.9.7' and '5.9' is for Qt 5.9.8. And as usual no any nice-to-have's in '5.9.7' anymore! br, Jani From: Jani Heikkinen Sent: Monday, September 24, 2018 4:37 PM To: development@qt-project.org Cc: releas...@qt-project.org Subject: HEADS-UP: Branching from '5.9' to '5.9.7' started Hi all, We have soft branched '5.9.7' from '5.9' today. Final downmerge from '5.9' to '5.9.7' will happen Mon 1.10.2018. So there should be enough time to finalize ongoing changes in '5.9' and start using '5.9.7' for new changes targeted to Qt 5.9.7 release. Our target is to get Qt 5.9.7 release out as soon as possible. Hoping that can happen during week 41. br, Jani ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting a wip/qt6 branch for QtSerialBus
On Tue, Oct 02, 2018 at 10:37:24AM +0200, André Hartmann wrote: > I allready have some ideas for QCanBusDevice which requires > binary-incompatible changes and therefore needs to be done for Qt6 [1]. > > To be able to already start the work, I'm hereby requesting a wip branch > that could be merged when the "real" Qt6 development begins. > > The advantage would be, that others could already pick up that changes > and test them, which hopefully will improve the code quality. > the more pragmatic approach is to "hide" the qt6 variant behind ifdefs. in fact, the introduction of a respective configure feature (so you would #if QT_CONFIG(qt6)) has been on the table for quite a while already, but nobody pushed for it yet, presumably because we haven't officially started qt6 yet. note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) which does effectively the same, but to activate it you would need to change .qmake.conf instead of just calling configure -qt6. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Requesting a wip/qt6 branch for QtSerialBus
Hi all, I allready have some ideas for QCanBusDevice which requires binary-incompatible changes and therefore needs to be done for Qt6 [1]. To be able to already start the work, I'm hereby requesting a wip branch that could be merged when the "real" Qt6 development begins. The advantage would be, that others could already pick up that changes and test them, which hopefully will improve the code quality. Regards, André [1] https://bugreports.qt.io/browse/QTBUG-64145 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
