Re: [Development] Goodbye
It will be in good hands with Christian Kandeler and Joerg Bornemann. Not to worry! > On Feb 10, 2018, at 12:45 AM, Denis Shienkov <denis.shien...@gmail.com> wrote: > > Wow, Jake, what will be with QBS? > > BR, > > Denis > > > 09.02.2018 23:14, Jake Petroules пишет: >> Steve Jobs once said: >> >>> “I have looked in the mirror every morning and asked myself: "If today were >>> the last day of my life, would I want to do what I am about to do today?" >>> And whenever the answer has been "No" for too many days in a row, I know I >>> need to change something.” >> >> After 8 years of Qt, it's time to say goodbye. Both from my employment in >> The Qt Company and my roles in the Qt Project. I'd like to thank those of >> you in the company and in the Qt Project who have supported me over the >> years in various ways. It's been a great adventure. Friday, February 23rd >> will be my last day. >> >> I hereby relinquish my role as Maintainer of Apple build system support >> across all projects under the Qt Project umbrella (nominating Oswald >> Buddenhagen as my replacement), and my role as Maintainer of the Apple >> watchOS platform (nominating Tor Arne Vestbø as my replacement). >> >> Please feel free to contact me at jake.petrou...@petroules.com if you have >> any questions, comments, or otherwise. >> >> I wish you all the best. >> >> Sincerely, >> Jake Petroules >> ___ >> 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 -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Goodbye
Steve Jobs once said: > “I have looked in the mirror every morning and asked myself: "If today were > the last day of my life, would I want to do what I am about to do today?" And > whenever the answer has been "No" for too many days in a row, I know I need > to change something.” After 8 years of Qt, it's time to say goodbye. Both from my employment in The Qt Company and my roles in the Qt Project. I'd like to thank those of you in the company and in the Qt Project who have supported me over the years in various ways. It's been a great adventure. Friday, February 23rd will be my last day. I hereby relinquish my role as Maintainer of Apple build system support across all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my replacement), and my role as Maintainer of the Apple watchOS platform (nominating Tor Arne Vestbø as my replacement). Please feel free to contact me at jake.petrou...@petroules.com if you have any questions, comments, or otherwise. I wish you all the best. Sincerely, Jake Petroules ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository request: Qt Notifier
“Qt Notifications” (qtnotifications) would be more grammatically in line with the rest of our repository names. -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From: Development <development-bounces+jake.petroules=qt...@qt-project.org> on behalf of Ryan Chu <ryan@qt.io> Sent: Monday, January 15, 2018 4:25:20 PM To: development@qt-project.org Subject: [Development] Repository request: Qt Notifier Hi all, I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. The first draft of this work was implemented in QtAndroidExtra https://codereview.qt-project.org/#/c/216407/. That would have added its 3rdparty libraries to every application, even if this feature is not used. A standalone module makes it possible for users to include or exclude this feature. Name of the project: Qt Notify Responsible person: Ryan Chu Gerrit user/email: ryan@qt.io<mailto:ryan@qt.io> Desired repository name: qtnotify Best regards, Ryan Chu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Adam Treat for approver
Adam is one of our best. Obvious +1. -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From: Development <development-bounces+jake.petroules=qt...@qt-project.org> on behalf of Simon Hausmann <simon.hausm...@qt.io> Sent: Monday, January 15, 2018 2:52:29 PM To: development@qt-project.org Subject: [Development] Nominating Adam Treat for approver Hi, I would like to nominate Adam for approver status. He has been developing with Qt for more than a decade and has been working on Qt and Qt 3D studio full time for about a year. I fully trust him to review changes thoroughly and reject stuff that looks fishy :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About the presence of /System/Library/Frameworks/Carbon.framework
> On Dec 21, 2017, at 3:57 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Thursday December 21 2017 13:47:34 Konstantin Tokarev wrote: > >> Check uname maybe? > > Possibly: just `uname` returns Darwin. That should certainly work for the > desktop OS, but I have no way of checking what it returns on other Apple OSes they all return "Darwin" > (and if the Carbon.framework exists there). it does not :) > > R. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0
> On Dec 19, 2017, at 2:28 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On terça-feira, 19 de dezembro de 2017 12:44:36 PST Oleg Yadrov wrote: >> Configuration finishes successfully, I run make a get a message >> "qlocale_unix.cpp:36: error: '_CS_LOCALE' was not declared in this scope. > > qlocale_unix.cpp line 36 in Qt 4.8 is a comment: > > http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/tools/qlocale_unix.cpp#n36 > > Did you mean line 58? > http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/tools/qlocale_unix.cpp#n58 > > If this is just an #include issue, try compiling with precompiled headers > (pass -pch to configure). > >> Later on make stops due to multiple errors in QWSServer. > > QWS was *only* designed for Linux. Do not try to run it on any other > platform. > You should use X11 on QNX instead. The early QPA might work, but we really > can't recommend it until Qt 5. > >> Am I doing something wrong, or is it really so that nobody tested if Qt >= >> 4.8.5 builds for QNX 6.5 before me? > > You are doing something wrong: trying Qt 4.8 for any new project in > almost-2018. Please upgrade. Consulting services... > >> PS: I'm not sure what "-embedded i386" parameter is needed for, but if I >> don't specify it, make fails due to something related to X11 header files. > > Don't pass options you don't understand. That option is the one that turned > the Linux-only QWS subsystem on. Remove it and make sure your buildsystem has > X11 headers. > > Or upgrade to Qt 5. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qbs 1.10 released
Hi everyone! Following our successful Qt, Qt Creator, and Qt 3D Studio releases yesterday, we have released qbs 1.10 today. Find all the relevant information in the blog post at http://blog.qt.io/blog/2017/12/07/qbs-1-10-released/ > On Dec 7, 2017, at 3:29 AM, Jani Heikkinen <jani.heikki...@qt.io> wrote: > > Hi everyone! > > I am happy to announce that Qt 5.10.0 and Qt Creator 4.5.0 are released today. > > More information about releases can be found from blog posts: > Qt 5.10.0: http://blog.qt.io/blog/2017/12/07/qt-5-10-released/ > Qt Creator 4.5.0: http://blog.qt.io/blog/2017/12/07/qt-creator-4-5-0-released/ > > Big thanks to everyone involved! > > br, > Jani Heikkinen > Release Manager > The Qt Company > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Maintainers of qt3dstudio/qt3dstudio
+1, no brainer! > On Nov 2, 2017, at 5:54 AM, Adam Treat <adam.tr...@qt.io> wrote: > > +1 > > On 11/02/2017 08:11 AM, Lars Knoll wrote: >> Hi Pasi, >> >> I fully support this. Qt 3D Studio is a big piece that TQtC just open >> sourced earlier and it’s good to get a defined maintainer structure for that >> project. >> >> Cheers, >> Lars >> >>> On 2 Nov 2017, at 12:48, Pasi Keränen <pasi.kera...@qt.io> wrote: >>> >>> Hi all, >>> >>> Those of you who have been following our blog posts or who went to QtCon >>> this year know about the new 3D UI design tool and runtime combination we >>> received as contribution from NVIDIA earlier this year. The tool is now >>> known as Qt 3D Studio and the repositories were opened before Qt WS 2017. >>> For more info check out: >>> http://blog.qt.io/blog/2017/10/11/qt-3d-studio-source-code-pre-release-snapshots-available/ >>> >>> I’d like to name myself (Pasi Keränen) as the maintainer of Qt 3D Studio. >>> I’ve been involved in the project since the early negotiations with NVIDIA >>> and handling the receiving of the contribution from them. All the way to >>> leading the Qt integration work that is still ongoing towards 1.0 release >>> later this month. >>> >>> As Qt 3D Studio is a large piece of work I’d like to also suggest the >>> following persons as maintainers of sub-areas of Qt 3D Studio: >>> Soili Väinämö – Maintainer of UX, ensuring the user experience of the tool >>> and runtime develop going onwards. Soili has been doing excellent work in >>> both converting the look’n’feel of the application to leading UX studies on >>> how to improve the usability of the product from end user point of view. >>> Tomi Korpipää – Maintainer of Editor Application code. Tomi has done great >>> work in handling the bug flow and converting the look’n’feel to more Qt >>> like together with Soili. >>> Antti Määttä – Maintainer of Runtime 1.0 and runtime integration. Antti has >>> long history of working with 3D engine code and has done excellent work in >>> for example prototyping OpenGL ES 2 support in the runtime component of Qt >>> 3D Studio. >>> Laszlo Agocs – Maintainer of Qt 3D based Runtime 2.0. Laszlo has been >>> working on the prototype runtime for some time now and is already looking >>> in to productizing it. >>> Miikka Heikkinen – Maintainer of installer and viewer application. Miikka >>> has been instrumental in getting the installer creation implemented and >>> also has been adding new experimental features to the viewer like image >>> sequence generation. >>> >>> Regards, >>> Pasi Keränen >>> Team lead of TQtC 3D Team, Oulu >>> ___ >>> 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 mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Getting build flags for platforms without pkg-config
> On Oct 30, 2017, at 9:11 AM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 30.10.2017, 18:53, "Konstantin Tokarev" <annu...@yandex.ru>: >> 30.10.2017, 18:43, "Thiago Macieira" <thiago.macie...@intel.com>: >>> On segunda-feira, 30 de outubro de 2017 08:27:02 PDT Konstantin Tokarev >>> wrote: >>>> >> $ cmake --find-package -DNAME=Qt5Core -DCOMPILER_ID=GNU -DLANGUAGE=CXX >>>> >> -DMODE=COMPILE >>>> >> -I/home/apol/devel/kde5/include/ >>>> >> -I/home/apol/devel/kde5/include/QtCore >>>> >> -I/home/apol/devel/kde5/lib64//mkspecs/linux-g++ >>>> > >>>> > -DQT_CORE_LIB is missing. Any volunteers to add it to the cmake files? >>>> >>>> It is already set: >>> >>> If it's already set, why is it missing? >> >> Apparently because cmake's imitation of pkg-config is half-assed. > > So, it seems to me that the most reasonable way to support more build systems > without duplicating data between them is to enhance pkg-config support. In > fact, > .pc files can be as rich as our .pri modules, containing extra data in custom > variables, and build systems can rely on original pkg-config tool or parse > .pc files > directly (it's a simple declarative format, if variable substitutions are not > used). > > AFAIK there no technical reason why providing .pc files for MSVC and macOS > frameworks would be impossible. Providing pkg-config files for Qt modules is something that's high on our list for the Qbs port of Qt; it's currently being worked on. >> >>> -- >>> Thiago Macieira - thiago.macieira (AT) intel.com >>>Software Architect - Intel Open Source Technology Center >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Regards, >> Konstantin >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
I believe we use qemu for the CI machines anyways, so we could probably emulate a ppc or mips CPU running Debian quite easily. > On Oct 23, 2017, at 1:59 PM, Dmitry Shachnev <mitya57...@gmail.com> wrote: > > On Fri, Oct 20, 2017 at 08:14:12AM -0700, Thiago Macieira wrote: >> For every architecture where the processor can run in either endianness, the >> system chooses one and sticks to it, so all software is specifically compiled >> for that choice. It's also encoded in the Qt sysinfo name: >> >> $ $QTLIBDIR/libQt5Core.t.so | head -1 >> This is the QtCore library version Qt 5.10.0 (x86_64-little_endian-lp64 >> shared >> (dynamic) debug build; by GCC 7.2.1 20171005 [gcc-7-branch revision 253439]) >> >> See >> https://www.debian.org/releases/stable/i386/ch02s01.html.en >> armel - l for little endian >> mipsel - l for little endian >> mips64el- l for little endian >> ppc64el - l for little endian >> >> I'd recommend trying the mips build, though it doesn't have the "e" which I >> believe stands for either "embedded" or "EABI" (where the E stands for >> "embedded"). > > No, in Debian architecture names “el” means little endian. > > If you can consider running native big endian hardware for CI, then Debian’s > mips architecture would work, but other good choices are s390x and ppc64. > > See https://wiki.debian.org/ArchitectureSpecificsMemo#Summary for the full > list of Debian architectures with their endianness. > > -- > Dmitry Shachnev > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 18, 2017, at 12:48 AM, Christian Gagneraud <chg...@gmail.com> wrote: > > The trap: > From reading your comments, I had the feeling that you're thinking that > building Qt with Qbs will help having a better Qt/Qbs integration when > building the user's project. > I think it's dangerous, the 3 things are orthogonal: building Qt with Qbs, > Qbs having a build dependency on Qt, and user using Qbs to build their > Qt-dependent (or not) own projects. You're right, they are orthogonal. The Qt module files happen to be located in the qbs repository right now. The Qt module files, long term, should be located with or generated by the build of Qt itself. For the latter case, building Qt with Qbs implies that that will become the reality anyways, which is why I strongly associated the two. Of course, we could do it *now* even when still building with qmake, but there would be no point doing things in that order. Just like there are CMake files shipped with Qt, which exist when Qt is built with qmake, and will continue to exist when it's built with Qbs. So again, we already agree - it's just a matter of how it's being phrased/explained. > The leak: > Current Qt build system (qmake) leaks into Qbs via qbs-setup-qt. > QtC suffers from that as well, I wrote an email about that, when i realised > that QtC was indirectly executing the cross-compiler defined in qmake's > mkspec and found on the PATH instead of using the one defined in the QtC kit. > This is rather scary. If I didn't say so before, this is entirely temporary. It will go away. I'm not sure about the Qt Creator case being referenced here, but if you can open a bug report that would be helpful. > Thanks for explaining, maybe this means that Qt should not be a Qbs module. > Or it should be a "container" module that gets populated by a probe. Possibly. This is what I was referring to by "dynamically generate modules at runtime". By the way, Qt is not currently one module, it's several dozen. > The handling of a product dependency on, say, Qt.Widgets, should not be > different than a product dependency on boost or whatever library. > Qbs doesn't have/need a boost module. And right now, it isn't different. You're confusing the existence of qbs-setup-qt with some sort of fundamental hardcoded tie-in to Qt. It's simply a helper tool that fills in some module properties. In terms of the high level constructs available in the Qbs language, Qt is no more special than anything else. And like I said before, qbs-setup-qt should probably go away eventually. > Now I understand that Qt is more than the sum of it's libraries/modules, > there are moc, qdoc, qrc, uic, Qml, ... too. And this make the job harder. Not necessarily. The non-Qt related things are in many ways more difficult than the Qt parts. >> Qbs != Qt is a "problem"? I'm not sure what you mean. The decoupling >> of Qbs and Qt is a strength, and it seems like you already agree with >> that... > > I agree that it would be a strength, if Qbs and Qt were not tightly coupled. > > My understanding is that Qbs can be used on non Qt-dependent projects > (bare-metal or not), nice. But this doesn't make Qbs completely decoupled > from Qt, because as soon as I need Qt for my project, the whole "q" kitchen > sink get pulled in. This is not a Qbs-specific problem tho. Indeed, Qbs can be used for non-Qt projects and this is the default case (unlike qmake where it must be explicitly turned OFF). I don't understand why you think this doesn't make Qbs completely decoupled from Qt though. You're saying that Qbs isn't decoupled from Qt because if you need Qt for your project... Qt gets pulled in? That doesn't make any sense. Can you provide a more concrete example? >> Hey, positive *and* negative (but constructive) feedback is always >> welcome. :) > > This was not even negative, i am not satisfied with all the build systems > I've tried so far, but it's OK, such is life! :) > > What I like with Qbs is the flexibility and its structured yet dynamic > language (Qml-ish). > But I'm having scalability and performance issues, that's another story that > i will report on the Qbs mailing list once i'm back on my Qbs stuff. Anything in this area is something we want to address. So please so provide specific feedback for any issues you're running into. -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 17, 2017, at 12:17 PM, Christian Gagneraud <chg...@gmail.com> wrote: > > With all due respect may I suggest that building qt with qbs is actually a > trap, please don't rely on that to solve your user's problems. > Qt is your toolkit, not mine. You should not leak. (No offense. I'm just > sharing my experience, but it seems I need to justify myself if I don't want > to be labelled "what are you smoking", I'm getting really pissed off about > that) We both want to solve the same problems, but I'm not sure exactly what you mean here about how building Qt with Qbs is a trap and that we should not "leak". My point was that the Qbs module files to describe the various Qt libraries must come from somewhere - either as a probe-based module within Qbs, an installation of Qt itself, or a combination. If we rely solely on probe-based modules within Qbs, then we need a way to dynamically generate modules at runtime (since we can't know about Qt modules which don't yet exist), which is currently not possible. This could end up being useful in the general case too, or maybe it isn't, but like any major architectural decision, it needs time and thought. > We (at work) all want this, the only problem with qbs are: > - stability (not blaming qbs, I knew I picked up an on going effort) > - Qbs != Qt Qbs != Qt is a "problem"? I'm not sure what you mean. The decoupling of Qbs and Qt is a strength, and it seems like you already agree with that... > - CI: can qbs solve Windows PC, Linux pc and arbitratly SoC tuned embedded > Linux builds w/o relying on qmake? > > I have hope, of all the cross-build systems I have used in the past 15 years, > none have been satisfactory, could qbs make a break through? Hey, positive *and* negative (but constructive) feedback is always welcome. :) -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 17, 2017, at 9:21 AM, Christian Gagneraud <chg...@gmail.com> wrote: > > On 17/10/2017 7:52 pm, "Jake Petroules" <jake.petrou...@qt.io> wrote: > > > On Oct 16, 2017, at 3:34 PM, jeandet <alexis.jean...@member.fsf.org> wrote: > > > > I have the feeling that a Qt build system will always force the users > > to choose between another tool they know but where the Qt support might > > not be the best and a Qt focused tool with a good Qt support but they > > will have to deal with external libs and might suffer corner cases. > > Indeed, which is why Qbs aims to solve both of those problems. Excellent Qt > support and excellent non-Qt support. Choose both. > > > As Qt user I started with qmake, I enjoyed writing projects with qmake > > then I switched to CMake to make easier usage of non Qt libs and > > config. Finally I switched to Meson and won't go back to CMake. I'm not > > sure I would switch to Qbs unless it gets less Qt focused. > > You should watch my World Summit talk when it's available on YouTube. :) > > One of the key points I talked about and which is very important is that Qbs > is NOT Qt-focused. Is it meant to be a completely generic build tool which > just happens to ship with out-of-the-box Qt support. I've been working on Qbs > for 5 years and have made close to 1000 changes, and for all of those 5 years > I actually haven't worked on the Qt support very much at all. > > Well, from a qbs user POV, Qt is still a privileged component (not talking > about qbs own build dependency here). And "qbs-setup-qt" is the curlprint. > > I don't see why this is needed (in an ideal world). This is actually a qmake > backdoor into qbs. Or call it a high coupling hotspot if you wish. > Can qbs be used to build a qt dependent project without a qt profile? I don't > think so. > > Qt should be detected the same way as any other user's project dependency > (probe link and include specifics), instead qmake is used as a proxy. > > In that respect cmake (or any other build system) got it right, qbs got it > wrong. > > On Linux, qt should be detected using qbs probe and package-config, period. > > I never liked qbs profile, they are awkward to manage in CI. > > Once you have a toolchain and a Qt profile everything is cool, but if you > start from a virgin install (eg. generic docker image), things look bad. I > guess this is a distro integration problem. But "distro" is Linux specific. > Mac and windows are far beyond. I never liked profiles either, and we have been moving away from them as a hard requirement. On macOS and Linux you can now build projects without a profile at all (there might be a bug or two with certain MSVC installations at the moment) if you don't use Qt. Getting rid of qbs-setup-qt will take some time, and we still need to find a solution to the problem of having to hardcode the list of all possible Qt modules (although when Qt itself is built with Qbs this problem may simply go away by definition). In fact you could argue right now that Qt is NOT a privileged component since it requires special additional setup to use it. But don't mistake this as a "fundamental design flaw", it's always been a temporary solution. We have top men working on it right now... top men. > > Chris > > > > > I still miss the point of making a dedicated build system instead of > > contributing to more general build systems like Meson or even CMake. > > Qbs is just as general as both of those, and in my opinion, even more so. > Please, try it out - you may be surprised! > -- > Jake Petroules - jake.petrou...@qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 16, 2017, at 3:34 PM, jeandet <alexis.jean...@member.fsf.org> wrote: > > I have the feeling that a Qt build system will always force the users > to choose between another tool they know but where the Qt support might > not be the best and a Qt focused tool with a good Qt support but they > will have to deal with external libs and might suffer corner cases. Indeed, which is why Qbs aims to solve both of those problems. Excellent Qt support and excellent non-Qt support. Choose both. > As Qt user I started with qmake, I enjoyed writing projects with qmake > then I switched to CMake to make easier usage of non Qt libs and > config. Finally I switched to Meson and won't go back to CMake. I'm not > sure I would switch to Qbs unless it gets less Qt focused. You should watch my World Summit talk when it's available on YouTube. :) One of the key points I talked about and which is very important is that Qbs is NOT Qt-focused. Is it meant to be a completely generic build tool which just happens to ship with out-of-the-box Qt support. I've been working on Qbs for 5 years and have made close to 1000 changes, and for all of those 5 years I actually haven't worked on the Qt support very much at all. > I still miss the point of making a dedicated build system instead of > contributing to more general build systems like Meson or even CMake. Qbs is just as general as both of those, and in my opinion, even more so. Please, try it out - you may be surprised! -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 16, 2017, at 2:46 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > I have no real experience with Meson, but at least it has following > advantages: > > * Its language is typed(!), has native support for arrays(!), and > functions/methods have > first-class return values(!) > * Its language has native support for properties, with syntax that really > looks like > properties in another languages > * It is target-oriented from the start and is not so burdened by legacy ways > of doing > things wrong, which plague old CMake projects and confuse newcomers > * It is written in scripting language, so it's easier to add (and possibly > distribute) new > functionality without getting it through upstream hands first. Basically ALL of these are key advantages of Qbs as well, and all but the third bullet point are a direct result of the language being QML. "target-oriented from the start" is a great way to express what I have used significantly more words to express in previous discussions. I will borrow this phrase. :) > That said, I totally dislike the idea of inventing restricted DSL language > for build system > instead of using general purpose language (like e.g. in QBS or Premake). The DSL is still fairly restricted, because it's declarative at the top level. What's special is that the right-hand side of property bindings can be arbitrary JavaScript expressions. So it's really two languages in one, although I suppose QML implies JavaScript by definition. -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 16, 2017, at 11:14 AM, Tobias Hunger <tobias.hun...@qt.io> wrote: > > Hi Jake, > > to use your version control picture: Are we trying to sell subversion by > showing how great that is compared to CVS and RCS, while git is just getting > introduced into the market? Your analogy is stacked to support your (biased) argument. In my (admittedly also biased) version, autotools, qmake, CMake, etc., are RCS, CVS, and Subversion. Qbs is git. Rhetoric like this is good for presentations and advertisements, but not very good in logic-based debates. > I am still missing a comparison of qbs and *current* build system options. > All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake is > what qbs will be competing with by the time it is ready to be used in earnest. Please give concrete examples of how CMake 3.x is so much more competitive now vs 2.x before continuing with this sort of argument. I'm also not opposed to comparing against a wider range of build tools, but keep in mind it's more useful to compare against what's actually relevant to our users in the market *now* (as in what people are already using), rather than options that do exist but no one has actually considered or used yet in the context of Qt. > So far we excluded most possible build systems on the grounds that they do > not support the mixed host/target builds we do. That requirement is going > away. So we have more options now. Just to name two: Bazel promises great > scalability and reliability, meson claims to be simple and fast. Even CMake > made a lot of progress since version 2.x. Qbs also promises scalability and reliability and also claims to be simple and fast. Apparently, stating the tagline of a product somehow means that product is the best choice...? Meson is the same age as Qbs, so you can't reasonably put it into the conversation, because it did not exist at the time we invented Qbs. Do you expect us to simply give up because competition *exists*? They have most certainly not magically leapfrogged over us in the same amount of time. Same with Bazel - released in 2015. Again, some new software comes around and we just give up? Sounds good, let's abandon Qt and sell Xamarin consulting services instead since they're better than us now. Hey Microsoft, since clang is simply way better than MSVC now, why don't you just stop developing your compiler? Absurd. > I would also appreciate getting some numbers to back up the claims made about > qbs. Well, you heard what I said on Thursday. Maybe you could volunteer some time to help do this. The rest of us are already heavily booked working on features and doing the Qt port so it's much lower on our list of priorities now. > > Best Regards, > Tobias > > -- > Tobias Hunger, Senior Software Engineer | The Qt Company > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 > B -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 16, 2017, at 4:42 AM, Kevin Kofler <kevin.kof...@chello.at> wrote: > > Christian Gagneraud wrote: >> I would resume this post as "I love CMake, CMake is the only way. >> You're all wrong." >> This post doesn't explain anything, doesn't gives any analysis, no >> comparison, no argument whatsoever, nothing. > > It makes one important point (and elaborates it to great lengths): developer > familiarity. Even if QBS were actually a lot better than CMake (something I > am also very sceptical about), it would still be universally hated simply > because it is not what developers (and distribution packagers!) know. > > As a distribution packager, I am really fed up of some upstream projects > reinventing their own custom build systems (qmake, gyp, gn, qbs, etc.) that > don't work with our existing packaging boilerplate. Keep in mind - and this is VERY important - Qbs is NOT "the Qt build system". It happens to be developed by the same people - that is all. We actually encourage people to use it for non-Qt projects. There's actually a lot of design decisions that went into making Qbs better in ways that are not even necessarily important for Qt itself right now, but are important for ensuring that it's suitable for *any* project (and just in general having a better foundation that Qt could also benefit from in the future as well). As I said in my talk at World Summit, "Qbs should go beyond Qt". I agree projects should not invent their own build systems. But Qbs is not "Qt's" build system, it is a new product and when I said in my talk that it's intended to compete with CMake, I didn't just mean "as a build system for Qt or for Qt based projects". ;) >> How many people had the same reaction when clang started? >> Nowadays, clang is actually far superior to gcc, it brought tooling >> like we would never have dared to dream of . > > Yet, Fedora packages are still built using GCC and there are no plans to > change that any time soon. The generated code is simply more efficient. > >> Same goes with SVN vs git, now (almost) everyone have given up with SVN. >> SVN was "CVS in better", git is a completely different approach to >> SCM, SVN is now a zombie. > > Yet, the git way to do things is not necessarily better. Revision IDs are > not comparable without having the absolute history. Developers can commit > their work locally without pushing it, encouraging intransparent > development. And the learning curve is a lot steeper if you are not used to > it yet. > > That said, git nowadays has the exact same argument going for it as CMake: > it is what everyone is now used to. > > Kevin Kofler > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 15, 2017, at 7:23 PM, Ben Lau <xben...@gmail.com> wrote: > > > On 14 October 2017 at 00:55, Denis Shienkov <denis.shien...@gmail.com> wrote: > Hi all, my 5-cents: > > QBS is better (best best) than CMake, IMHO, as CMake is too complicated. :) > > > I am still new to QBS, but I think it is better than CMake too. However, I > think it has missed a critical feature - A simple way to run custom script. > > For example, run a script to call external command (not a product by your > application) to deploy your application to App Store or simply upload to a > server. > > Currently it is quite difficult to do it via qbs, so it will still need a > platform depended script system. This is already possible - just create a rule to do this, and put it in its own product (with builtByDefault:false). Then you can simply invoke your process via `qbs run -p my_script`. Perhaps this could be rationalized into a dedicated feature (there is something about "action targets" on JIRA) but it's not that hard to get something pretty close with today's qbs. > Just my 2 cents > > QBS needs still in BinaryFiles support (e.g. to allow todo patching, merge > for some output > files using custom algorithms), better QtC integration (e.g. with Android && > iOS). > > In other things QBS is very flexible, e.g. I have used it for creation of > some application's > Installers (for Windows), packing to archives, adding of additional rules for > creating of HEX, > MAP and so forth 'post build' things, and more more others (include compiling > a projects > for bare-metal architectures, e.g. AVR and so on). I don't know is it > possible to do it with > CMake with same as it simple in QBS (because CMake it is hell, IMHO). > > Besides, AFAIK, Qt has the wip/qbs branch, where it builds with QBS instead > of qmake. > > BR, > Denis > > 2017-10-13 18:30 GMT+03:00 Oswald Buddenhagen <oswald.buddenha...@qt.io>: > On Fri, Oct 13, 2017 at 04:19:51PM +0100, Sergio Martins wrote: > > On 2017-10-13 16:12, Thiago Macieira wrote: > > > On Friday, 13 October 2017 07:56:47 PDT Sergio Martins wrote: > > >> IMHO the qt-project is not in a position to reject Qt building with > > >> qbs, simply because there's no other implementation, nobody is > > >> going to port Qt to CMake (if you disagree start a new thread). > > > > > > There are volunteers to do that. They just need to know when they > > > could start doing the work to make a proof of concept. > > > > Good to know Thiago. I'd say they should ask on the mailing lists > > instead of waiting. > > > it already has been. we (the current maintianers of the qt build system, > and really anyone with a grain of taste) are strongly biased against a > cmake-based solution. in fact, we have rejected a cmake-based port of qt > creator some years ago. > > ps: there is a qbs-specific mailing list (this is specifically not > applicable to the above topic, but that's just a tangent to start with). > ___ > 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 mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QBS
> On Oct 15, 2017, at 11:20 AM, Christian Gagneraud <chg...@gmail.com> wrote: > > On 14 October 2017 at 04:22, Jean-Michaël Celerier > <jeanmichael.celer...@gmail.com> wrote: >>> nobody is going to port Qt to CMake (if you disagree start a new thread) >> >> https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8 > > I would resume this post as "I love CMake, CMake is the only way. > You're all wrong." > This post doesn't explain anything, doesn't gives any analysis, no > comparison, no argument whatsoever, nothing. > > How many people had the same reaction when clang started? > Nowadays, clang is actually far superior to gcc, it brought tooling > like we would never have dared to dream of . > > Same goes with SVN vs git, now (almost) everyone have given up with SVN. > SVN was "CVS in better", git is a completely different approach to > SCM, SVN is now a zombie. > > "Not reinventing the wheel" has to be balanced with "innovation". > > IMHO, Qbs' great potential is the "completely new approach". > Qbs would be a failed attempt if it was "CMake in better". > > I think it's worth thinking about that, and be critical instead of > being blind nay-sayer. > >>> a complete CMake build for Qt was already contributed upstream (quite some >>> time ago) .. and rejected .. > > It would be interesting to know why. Oswald said "we (...) are > strongly biased against a > cmake-based solution", but didn't give any reason/justification (Or I > missed it). > > Did this CMake port cover all the features provided by qmake? > Did this CMake port provide all the configuration needed by Qt, on all > the supported platform? > Could the Qt CI switch to CMake then? > > And what about this "Nominating Kevin Funk for Maintainer qtbase/Build > Systems/CMake" thread? > Will Kevin Funk (aka. "The CMake guy" according to Sergio) be fair > when it comes to evaluating new build systems for Qt? or is it an > hijack attempt, an insider infiltration? > Or is it pure timing coincidence, and Kevin Funk is actually a "build > system*s* guy"? As I said in my QtWS talk, we recognize that people must be given a choice of build system for their own projects, and for that reason we will continue to support and provide CMake modules for Qt libraries. Since Kevin's been doing the work of maintaining these modules anyways, it makes sense that he officially be labeled Maintainer. Ossi is still chief maintainer of build systems generally, Kevin is simply being nominated as a sub-maintainer for the CMake build systems area just as I am a sub-maintainer of the Apple Platforms (macOS/iOS) build systems area. This has nothing to do with Qbs or Qt's use of it. André actually asked me if I was OK with him nominating Kevin, given my role in driving Qbs, which of course I am for the above stated reasons. :) > I have no power of decision, so i will accept any. > > Nonetheless, I think it would be a mistake to choose a build system > over the other because "I love Xyz, Xyz is the only way. You're all > wrong." > > Who knows, maybe the answer to "Which new build system for Qt" could > be neither CMake, neither Qbs. We've already decided internally that we want to push Qbs as the new build tool, and I have no doubt that the community will agree. > My 2 cents, > Chris > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
VxWorks 7 = gcc 4.8.1 -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From: Development <development-bounces+jake.petroules=qt...@qt-project.org> on behalf of Simon Hausmann <simon.hausm...@qt.io> Sent: Wednesday, October 11, 2017 8:52:57 PM To: Thiago Macieira Cc: Development Subject: Re: [Development] Any supported platforms not tested in CI? Hi, Integrity (ghs) is checked during the qt5 build. Vxworks is the only target I can think of that is not CI tested. But iirc that’s a gcc flavor. Simon On 11. Oct 2017, at 20:49, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: Are there any supported platforms that we do not test in the CI? Probably INTEGRITY? I'm asking based on this outcome from QtCS: We will not add compilers that are worse than what we have today. Right now, Qt 5.10 has a configure-time warning if we don't find C++11 . I'd like to make that an error and for that I've just pushed a change that makes it so. So the question is: are there any platforms that could break even after passing the CI check? -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto: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] Announcement for developers of Qt on macOS and iOS
Hi all,
I've recently merged some changes into qtbase that I think warrant a
warning/announcement to help people understand some strange errors that might
pop up in the future.
The background is this: in Xcode 9, there is a new Clang builtin function
called __builtin_available (C, C++) / @available (Objective-C). There is also a
new warning, unguarded-availability, which will be emitted whenever you
unconditionally call an API that might not be available on your deployment
target (for example if we call an API introduced in macOS Sierra v10.12, but Qt
must still be compatible with OS X Yosemite v10.10). By wrapping the API call
site like so:
if (__builtin_available(macOS 10.12, *)) {
// Call 10.12 API normally
} else {
// Do something else for 10.10 and 10.11
}
we inform the compiler via __builtin_available that we are performing the
necessary runtime check for the OS version before calling any potentially
unavailable APIs. This means that we get compile time validation of API
availability for APIs we use in Qt, something that has previously only been
availably in Swift. Like always, the compiler automatically takes care of
weak-linking the functions so there is no need to use dlopen/dlsym, and this
works for all languages.
This builtin is part of LLVM 5, here are the docs:
https://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available
Now, as for what this means for Qt. In Qt 5.10 and beyond,
unguarded-availability warnings are now a hard error
(https://codereview.qt-project.org/#/c/206348/). But what about older versions
of Clang, and other compilers, where this builtin is not available? Thanks to a
bit of macro magic (https://codereview.qt-project.org/#/c/206346/16//ALL),
we'll be able to use this new builtin function everywhere in Qt, on all
compilers and platforms. My "polyfill" will simply transform the
__builtin_available calls to an implementation that uses
QOperatingSystemVersion behind the scenes, to perform the check.
Basically, all you need to do is make sure you use __builtin_available where
necessary (and Xcode 9 will force you to). You may no longer use
QSysInfo::macVersion (which is deprecated entirely, by the way),
QOperatingSystemVersion, or respondsToSelector, to perform API availability
checks. If you run into an error like "symbol 'macOS' undefined", you probably
forgot to include qglobal_p.h, where the polyfill is housed.
I've already audited the entire Qt codebase, and adjusted all call sites as
necessary. Unless I missed something, the work is done, but for future
development, now everyone knows.
Cheers,
--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Upcoming Clang compiler changes for macOS and iOS: RFC for solutions
ystemVersion(QOperatingSystemVersion::TvOS, tvos_major, tvos_minor,
tvos_patch)
#define QT_AVAILABLE_WATCHOS(watchos_major, watchos_minor, watchos_patch) \
QOperatingSystemVersion::current() >=
QOperatingSystemVersion(QOperatingSystemVersion::WatchOS, watchos_major,
watchos_minor, watchos_patch)
#define QT_AVAILABLE_MACOS_IOS(macos_major, macos_minor, macos_patch,
ios_major, ios_minor, ios_patch) \
QOperatingSystemVersion::current() >=
QOperatingSystemVersion(QOperatingSystemVersion::MacOS, macos_major,
macos_minor, macos_patch) || \
QOperatingSystemVersion::current() >=
QOperatingSystemVersion(QOperatingSystemVersion::IOS, ios_major, ios_minor,
ios_patch)
#define QT_AVAILABLE_DARWIN(macos_major, macos_minor, macos_patch, ios_major,
ios_minor, ios_patch, tvos_major, tvos_minor, tvos_patch, watchos_major,
watchos_minor, watchos_patch) \
QOperatingSystemVersion::current() >=
QOperatingSystemVersion(QOperatingSystemVersion::MacOS, macos_major,
macos_minor, macos_patch) || \
QOperatingSystemVersion::current() >=
QOperatingSystemVersion(QOperatingSystemVersion::IOS, ios_major, ios_minor,
ios_patch) || \
QOperatingSystemVersion::current() >=
QOperatingSystemVersion(QOperatingSystemVersion::TvOS, tvos_major, tvos_minor,
tvos_patch) || \
QOperatingSystemVersion::current() >=
QOperatingSystemVersion(QOperatingSystemVersion::WatchOS, watchos_major,
watchos_minor, watchos_patch)
#endif
and a typical usage of the last one would look like:
if (QT_AVAILABLE_DARWIN(/*macOS*/ 10,13,0, /*iOS*/ 11,0,0, /*tvOS*/ 11,0,0,
/*watchOS*/ 4,0,0)) {
// use new APIs...
}
My other attempt at a macro which instead "backports" the new language feature
looks like this:
#define QT_AVAILABLE_LPAREN (
#define QT_AVAILABLE_RPAREN )
#define QT_AVAILABLE_COMMA ,
#define QT_AVAILABLE_CAT(L, R) QT_AVAILABLE_CAT_(L, R)
#define QT_AVAILABLE_CAT_(L, R) L ## R
#define QT_AVAILABLE_EXPAND(...) __VA_ARGS__
#define QT_AVAILABLE_SPLIT(OP, D) QT_AVAILABLE_EXPAND(OP
QT_AVAILABLE_CAT(QT_AVAILABLE_SPLIT_, D) QT_AVAILABLE_RPAREN)
#define QT_AVAILABLE_SPLIT_macOS QT_AVAILABLE_LPAREN
QOperatingSystemVersion(QOperatingSystemVersion::MacOS QT_AVAILABLE_COMMA
#define QT_AVAILABLE_SPLIT_iOS QT_AVAILABLE_LPAREN
QOperatingSystemVersion(QOperatingSystemVersion::IOS QT_AVAILABLE_COMMA
#define QT_AVAILABLE_SPLIT_tvOS QT_AVAILABLE_LPAREN
QOperatingSystemVersion(QOperatingSystemVersion::TvOS QT_AVAILABLE_COMMA
#define QT_AVAILABLE_SPLIT_watchOS QT_AVAILABLE_LPAREN
QOperatingSystemVersion(QOperatingSystemVersion::WatchOS QT_AVAILABLE_COMMA
static bool qtAvailable(const std::vector )
{
std::vector types;
const auto current = QOperatingSystemVersion::current();
for (const auto : versions) {
types.push_back(v.type());
if (current >= v)
return true;
}
return !types.contains(current.type());
}
#if __has_builtin(__builtin_available) && 0
#define __builtin_available2 __builtin_available
#define __builtin_available3 __builtin_available
#define __builtin_available4 __builtin_available
#else
#define __builtin_available(a, e) \
qtAvailable({QT_AVAILABLE_SPLIT(, a)})
#define __builtin_available2(a, b, e) \
qtAvailable({QT_AVAILABLE_SPLIT(, a), QT_AVAILABLE_SPLIT(, b)})
#define __builtin_available3(a, b, c, e) \
qtAvailable({QT_AVAILABLE_SPLIT(, a), QT_AVAILABLE_SPLIT(, b),
QT_AVAILABLE_SPLIT(, c)})
#define __builtin_available4(a, b, c, d, e) \
qtAvailable({QT_AVAILABLE_SPLIT(, a), QT_AVAILABLE_SPLIT(, b),
QT_AVAILABLE_SPLIT(, c), QT_AVAILABLE_SPLIT(, d)})
#endif
But I don't know how to transform i.e. "10.10" into 10,10" in the expanded
macro, nor do I know any way to support variable arguments in a way that lets
us drop the last argument.
So... can anyone do better than my versions? Patches very welcome. :)
--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt and IoT infographic
> On Aug 24, 2017, at 9:08 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On Thursday, 24 August 2017 20:06:56 PDT Jake Petroules wrote: >> In our license management systems, there happen to be exactly 12 "platforms" >> codified, so it's possible someone in marketing looked at a copy of that >> list in Salesforce or something. That list is: >> >> - X11 >> - Embedded Linux >> - Windows (desktop Windows) >> - macOS >> - Embedded Windows (i.e. Windows CE, and therefore obsolete) >> - Android >> - QNX >> - VxWorks (which isn't actually an officially supported platform yet aside >> from that fork of 5.5) >> - INTEGRITY > > Looks like the licence key mechanism we used to use for Qt 3 and 4, and Qt 5 > where X11 > and QWS were distinct implementations and we delivered different sources to > customers. The order matches that order too (except for Android, that should > be Symbian in that position). Yep: ... - Embedded Windows - Symbian - Android - S40 - QNX ... I imagine QWS was in the place where Embedded Linux is now as there's no other gaps in the bit set and the last platforms in the list are too new to have preceded it. > A little bit of trivia: > > In the beginning of time, we used to split the source repository (CVS, then > Perforce) into multiple source packages, according to the file names. That's > why there's "qt-x11-2.3.0" and "qt-embedded-2.3.0". In Qt 3 times, the Mac > version was also made opensource, so "qt-mac-free-3.1.2". Then, for 4.0, > Windows was made open source. > > [ "First there was Linux / and then there was Mac / now with Windows / on > the > Open Source track" anyone?] > > It was shortly before my time as release manager that we created the all- > desktop source package called "qt-all-opensource-src-4.3.0", which was the > Perforce repository minus the *_qws* files and a few things that weren't part > of any release (like the licence key decoder). Funny enough, the key decoder is the only place where the full list of all 14 platforms still exists. All mention of Symbian got purged from the Qt sources pretty thoroughly. Somehow, much older systems like IRIX, SCO, and others have survived longer. ;) > Later, after the Git repository > was opened up, we got permission to release all implementations in one source > package. Since we had already used "all", we needed a different tag for that. > We called it "qt-everywhere-opensource-src-4.6.0". > > And that's what it is still called: > http://download.qt.io/official_releases/qt/5.9/5.9.1/single/qt-everywhere-opensource-src-5.9.1.tar.xz > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt and IoT infographic
I'll find out who wrote that and why. In our license management systems, there happen to be exactly 12 "platforms" codified, so it's possible someone in marketing looked at a copy of that list in Salesforce or something. That list is: - X11 - Embedded Linux - Windows (desktop Windows) - macOS - Embedded Windows (i.e. Windows CE, and therefore obsolete) - Android - QNX - VxWorks (which isn't actually an officially supported platform yet aside from that fork of 5.5) - INTEGRITY - iOS (tvOS and watchOS aren't yet officially supported either but use the same license platform as iOS) - UWP (WinRT / Windows Runtime) - Embedded Android (obsolete?) Symbian and S40 used to be there too. > On Aug 24, 2017, at 2:05 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On Thursday, 24 August 2017 14:00:01 PDT Thiago Macieira wrote: >> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is >> that relevant to Qt or where is it exposed in Qt? > > It also says "12+ supported platforms". Where does that number come from? I > can count 7: > > - Linux > - Windows > - macOS > - Android > - iOS / tvOS / watchOS > - QNX > - INTEGRITY > > Even if you split the Apple embedded platforms, that's still 9. WinRT > shouldn't be split from Windows, since it's still Windows; Embedded Linux is > still Linux and so are all the different Linux distributions. > > Don't add FreeBSD there just because I like developing with it more than on > macOS. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [BB++] Now is 3.5x faster than Node.JS
Regardless, he has a point: in more diplomatic terms, this thread and those preceding it are not promoting useful discourse, so I'd encourage others to refrain from posting further replies, and let this thread die out. Sent from my iPhone - the most secure mobile device - via the Verizon network -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io<http://qbs.io> _ From: James McDonnell <jmcdonn...@blackberry.com<mailto:jmcdonn...@blackberry.com>> Sent: Saturday, July 22, 2017 11:27 AM Subject: Re: [Development] [BB++] Now is 3.5x faster than Node.JS To: Oleg Khotskin <o.khots...@gmail.com<mailto:o.khots...@gmail.com>>, Phil Bouchard <philipp...@gmail.com<mailto:philipp...@gmail.com>> Cc: development <development@qt-project.org<mailto:development@qt-project.org>> That's the sort of comment that drives new people away from open source projects. Please refrain from making such comments. Sent from my BlackBerry - the most secure mobile device - via the Rogers Network From: o.khots...@gmail.com<mailto:o.khots...@gmail.com> Sent: July 22, 2017 2:06 PM To: philipp...@gmail.com<mailto:philipp...@gmail.com> Cc: development@qt-project.org<mailto:development@qt-project.org> Subject: Re: [Development] [BB++] Now is 3.5x faster than Node.JS Does anyone take this dumbass seriously? -- Best regards, Oleg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Widgets maintainers
A big +1 to Gabriel for styles maintenance. The poor man has been doing a great job keeping his sanity while suffering through all those QMacStyle fixes lately... :) > On Jul 7, 2017, at 4:03 AM, Frederik Gladhorn <frederik.gladh...@qt.io> wrote: > > Hello all, hello Marc, > > First of all, thank you very much for taking care of the widgets module and > working to get bugs under control. > > We've been talking inside The Qt Company about the widgets module a lot > lately, since we do see it as a very important part of Qt, which doesn't > receive as much marketing and highlighting as it deserves. For traditional > UIs, widgets are certainly a viable and good building block. > > While we don't anticipate huge changes in the module, we will keep on > updating > the styles where it makes sense and take bugs serious. Since it's also a big > chunk of a module, we'd like to propse a team of maintainers, to make it > easier on everyone. > > Our proposal is: > Richard Gustavsen as overall maintainer > Gabriel de Dietrich for styles > Jan-Arve Sæther for layouts > Eskil Abrahamsen-Blomfeldt for all text related things > Andreas Aardal Hanssen for graphicsview > > Item Views is open and would fall to Richard for now, but if someone is > interested in helping out more with it, that's certainly appreciated. > > Cheers, > Frederik > > > On fredag 7. juli 2017 12.20.19 CEST Marc Mutz wrote: >> Hi all, >> >> KDAB is handing back widgets maintenance, which means that I'm stepping >> down as widgets maintainer. The focus of KDAB contributions to Qt is >> clearly elsewhere these days (Qt3D, Core, tooling), and the module >> deserves more focus than it has seen lately. >> >> To this end, Lars has assembled a team(!) of proposed widgets >> (sub)maintainers that we as KDAB and I personally fully support as >> successors. >> >> In Lars' absence, I'll leave it to Frederik to introduce them to you in >> detail (as if introduction was needed...). >> >> Thanks, >> Marc >> >> ___ >> 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 -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.10 pre-built bunaries
> On Jun 7, 2017, at 12:30 AM, Lars Knoll <lars.kn...@qt.io> wrote: > > Hi Jani, > >> On 7 Jun 2017, at 08:57, Jani Heikkinen <jani.heikki...@qt.io> wrote: >> >> Hi all, >> >> There has been discussion ongoing about 5.10 supported platforms and CI >> configurations. What we haven't agreed yet is Qt 5.10 pre-built binaries. I >> don't see big need to change anything from 5.9 but there is still couple of >> things on my mind: >> >> - Should we now switch from MinGW32 bit -> MinGW 64bit ones? With 5.9 this >> was too early but would it be time to do it now? Offering both isn't an >> option. And 5,9 is LTS so 5.10 could be good release to change that... > > We got a lot of questions about 32bit binaries still in the comments to the > release blog. But those were pretty much all about VS2017. I'd personally be > happy to move more towards 64 bit, but we should somehow find out how much > 32bit is still required by our users. >> >> - Can we start using RHEL 7.4 for linux packaging? Tony is planning to add >> RHEL 7.4 in CI and so on it would be wise to replace 7.2 with 7.4 in the >> packaging as well > > Sounds good to me, unless anybody knows about any reasons why we should stay > on 7.2. >> >> Is there some other change proposals which we should discuss about? > > I think we should strongly consider dropping 32bit for iOS. I thought we already agreed to do this. :) With Apple announcing that iOS 11 will no longer support 32-bit applications, let alone CPUs, there's very little value in us supporting it. 80-90% of iOS devices will likely be on iOS 11 in the first week or month of its release, and of the percentage that aren't, only a minority will be the 32-bit iPhone 5. We probably even support too many iOS versions as it is. Apple's official recommendation is that your deployment target should be "major version one below current, maximum minor version" - i.e. when iOS 11 is out, your deployment target should be 10.3. > Cheers, > Lars > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for Qt 5.10 platforms and configurations changes
> On Apr 27, 2017, at 11:28 PM, Lars Knoll <lars.kn...@qt.io> wrote: > > >> On 27 Apr 2017, at 16:59, Jake Petroules <jake.petrou...@qt.io> wrote: >> >>> >>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen <tuukka.turu...@qt.io> wrote: >>> >>> >>> Hi, >>> >>> Related to the Apple platforms, could we consider the following for Qt 5.10: >>> - Drop the older iPhone support by removing ARMv7 from iOS >>> (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) >>> - Consider also dropping ARMv7s support, which would allow dropping i386 >>> simulator support >> >> I really don't like how we use the term "support" in these emails because >> it's rather misleading. We use it to mean "tested in CI", whereas I (and >> most of the world, as far as I can tell) read it as "the code exists and is >> functional". "Removing support" to me means actively removing the code which >> makes something functional. > > Agree, there is a difference between the two. > > What I think we should however do for 5.10 is remove 32bit support for iOS > from CI and our binary packages. And that means that things will be untested > on 32bit iOS, and thus is likely to break at some point. I think 32-bit support on iOS is kind of unlikely to break accidentally, but I agree we should remove it from our binary packages. The iPhone 5 is dead. >> >> As an Open Source project, we need to keep in mind that dropping first party >> "support" for something means little to nothing unless we actually delete >> the associated code as well and refuse patches to re-add it, because people >> can always build their own copy of Qt, and commercial support will obviously >> still answer queries for most definitions of "unsupported", making the term >> "unsupported" a little meaningless. Perhaps we can start using the term >> "tier 1 support" as a synonym for what we actually mean by "support", in >> order to be more clear? I really liked the notion of tiered support that we >> used to have but it seems to have gone missing… > > For the commercial version, it’s to a large extent up to TQtC to define the > support offering. The open source project anyway does not offer any official > support for the Qt versions released. All you can do is ask on the mailing > lists or file a bug report and hope for the best. Or of course sit down, fix > it yourself and submit a patch :) My point was that if a commercial customer goes to support with a bug in a 32-bit build of Qt for iOS, support won't say "we do not support that, go away". They will fix the problem, regardless of the fact that it isn't part of a reference configuration. If a customer sets the minimum deployment target of Qt for iOS to 5.0 and then goes to support saying Qt doesn't work, support WILL tell them "we do not support that (because we deliberately broke it), we can't help you and you'll have to talk to Services and pay money if you want it working that badly". That's the real-world outcome, which is why I don't like using the term "supported" as a synonym for "is a reference configuration in CI". A reference configuration in CI always constitutes something that is supported. However, something that's supported is not necessarily a reference configuration in CI. We should make this clear to our users by not using the term "supported" in a misleading way. > >> >> Something like the following seems nice: >> Tier 1 - the most rigorously tested configurations, tested in CI >> Tier 2 - we actively try to make it work but it's a lower priority; will >> make and accept patches and provide support but isn't tested in CI >> Unsupported - we remove code that makes the functionality work; will refuse >> any related patches, commercial support refers queries to a separate (paid) >> business engagement > > I’m ok to describe things in tiers, as that’s what we have in practice. We > don’t test e.g. FreeBSD in CI, but we will accept patches if something’s > broken on that platform and someone cares enough to fix it. Same would be > true for 32bit iOS in 5.10 then. But the only thing the Qt project will be > able to give some guarantees for are the configurations tested in CI. >> >> Anyways, iOS 11 will likely drop support for 32-bit applications entirely >> (i.e. they will not launch because 32-bit system libs will be GONE). So I >> agree we should stop shipping 32-bit slices in our binary distributions of >> Qt for iOS. We sho
Re: [Development] Proposal for Qt 5.10 platforms and configurations changes
> On Apr 27, 2017, at 11:54 PM, Shawn Rutledge <shawn.rutle...@qt.io> wrote: > > >> On 27 Apr 2017, at 16:59, Jake Petroules <jake.petrou...@qt.io> wrote: >> >> Anyways, iOS 11 will likely drop support for 32-bit applications entirely >> (i.e. they will not launch because 32-bit system libs will be GONE). So I >> agree we should stop shipping 32-bit slices in our binary distributions of >> Qt for iOS. We should not deliberately break 32-bit support though (and it's >> hard to do this accidentally anyways). > > Well, the latest iOS versions don’t run on devices of a certain age (and in > other cases, you can upgrade but you’d better not, because you’ll regret it) > - that’s their way of shaking you down. But as long as developers can keep > enabling continued use of those devices somehow rather than sending them > promptly to the shredder as soon as Apple wants you to, I think we should > support them in their efforts, or at least not interfere. Removing 32-bit support from our packages only drops the iPhone 5 from support by Qt. The 5s and above are all 64-bit so this has been a long time coming. I'm all for dropping 32-bit "support" (from the CI). If people REALLY need 32-bit, they can go compile it themselves. > >> On 27 Apr 2017, at 17:00, Jake Petroules <jake.petrou...@qt.io> wrote: >> >>> On Apr 27, 2017, at 7:40 AM, BogDan Vatra <bogdan.va...@kdab.com> wrote: >>> >>> For Android I'd like to support 64 bit platforms (arm and x86) >> >> They are already supported. Feel free to compile Qt with the appropriate >> -arch options. Do you mean you want them in CI and want us to start shipping >> binaries for android amd64 and arm64? >> >> I'm not sure there's enough 64-bit devices out there to justify it yet. >> Android moves very slow... > > Lollipop came out in 2014. And there were 64-bit devices available by then. > So I suspect the majority of new devices are 64-bit by now. > > If _users_ are slow to upgrade their devices, that’s really good on them, not > going along with the planned obsolescence nonsense which is purely harmful: > to your wallet, to the environment, to the sense of guilt that you feel when > you do the wrong thing, and increasing inequality in the economy. Apple gets > a black mark in my book for trying so hard to remove that choice. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for Qt 5.10 platforms and configurations changes
> On Apr 27, 2017, at 7:40 AM, BogDan Vatra <bogdan.va...@kdab.com> wrote: > > For Android I'd like to support 64 bit platforms (arm and x86) They are already supported. Feel free to compile Qt with the appropriate -arch options. Do you mean you want them in CI and want us to start shipping binaries for android amd64 and arm64? I'm not sure there's enough 64-bit devices out there to justify it yet. Android moves very slow... > > BogDan. > > On April 27, 2017 12:29:08 PM GMT+03:00, Heikki Halmet <heikki.hal...@qt.io> > wrote: > Hi, > > > Below we have proposal for changes in supported platforms and configurations > from Qt 5.9 to 5.10. > > Please comment if the proposal is insufficient or the changes are > unacceptable somehow. > > > Please refer to Qt 5.9 Supported platforms -> > http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > > LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > > RHEL 7.2 -> RHEL 7.3 (Any benefits?) > > OpenSUSE 42.1 -> OpenSUSE 42.2 > > Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > > macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) > > macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) > > Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > > Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > > INTEGRITY GHS 2016.5.4 -> 2017.1.x > > Support for Android 8 (if available on time) > > iOS 11 support (if available on time. Current rumors -> september) > > > MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for > 5.10 is at the beginning of August. > > This means that we can only use Preview release of 10.13 for testing before > final official release is out. > > That can cause situation that we don’t have enough time to get 10.13 in > before 5.10 release so we can’t give guarantees that 10.13 will be supported > in 5.10. > > > NOTE! We will commit to wanted platform and software changes as long as those > are available straight after 5.9 release is out in the end of the May. > > With all others we'll do the best we can but we can't commit that those will > be supported in 5.10. > > > > > Best regards > > Heikki Halmet > > > The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland > > Email: heikki.hal...@qt.io > > Phone: +358408672112 > > www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject > Facebook: www.facebook.com/qt > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my > brevity.___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for Qt 5.10 platforms and configurations changes
> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen <tuukka.turu...@qt.io> wrote: > > > Hi, > > Related to the Apple platforms, could we consider the following for Qt 5.10: > - Drop the older iPhone support by removing ARMv7 from iOS > (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf) > - Consider also dropping ARMv7s support, which would allow dropping i386 > simulator support I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional. As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing... Something like the following seems nice: Tier 1 - the most rigorously tested configurations, tested in CI Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways). > - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus > supporting three latest ones means dropping one) Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :) Current list is: - Qt 5.6 - supports macOS 10.7 and up - Qt 5.7 - supports macOS 10.8 and up - Qt 5.8 - supports macOS 10.9 and up - Qt 5.9 - supports macOS 10.10 and up Planned: - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10 - Qt 5.11 - supports macOS 10.11 and up By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported". If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright. But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10) > > Yours, > > Tuukka > > On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" > <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of > jake.petrou...@qt.io> wrote: > > >> On Apr 27, 2017, at 2:29 AM, Heikki Halmet <heikki.hal...@qt.io> wrote: >> >> Hi, >> >> Below we have proposal for changes in supported platforms and configurations >> from Qt 5.9 to 5.10. >> Please comment if the proposal is insufficient or the changes are >> unacceptable somehow. >> >> Please refer to Qt 5.9 Supported platforms -> >> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html >> >> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: >> RHEL 7.2 -> RHEL 7.3 (Any benefits?) >> OpenSUSE 42.1 -> OpenSUSE 42.2 >> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) >> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) > >Apple does not ever release updates to older release series, so since 8.3 > already exists, this is guaranteed to remain 8.2.1. > >> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or
Re: [Development] Proposal for Qt 5.10 platforms and configurations changes
> On Apr 27, 2017, at 2:29 AM, Heikki Halmet <heikki.hal...@qt.io> wrote: > > Hi, > > Below we have proposal for changes in supported platforms and configurations > from Qt 5.9 to 5.10. > Please comment if the proposal is insufficient or the changes are > unacceptable somehow. > > Please refer to Qt 5.9 Supported platforms -> > http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html > > LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10: > RHEL 7.2 -> RHEL 7.3 (Any benefits?) > OpenSUSE 42.1 -> OpenSUSE 42.2 > Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI) > macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available) Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1. > macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available) 8.3.2, please. > Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 > Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3 > INTEGRITY GHS 2016.5.4 -> 2017.1.x > Support for Android 8 (if available on time) > iOS 11 support (if available on time. Current rumors -> september) > > MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for > 5.10 is at the beginning of August. > This means that we can only use Preview release of 10.13 for testing before > final official release is out. > That can cause situation that we don’t have enough time to get 10.13 in > before 5.10 release so we can’t give guarantees that 10.13 will be supported > in 5.10. How do you know it won't be called macOS 11? ;) The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does. Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support. > > NOTE! We will commit to wanted platform and software changes as long as those > are available straight after 5.9 release is out in the end of the May. > With all others we'll do the best we can but we can't commit that those will > be supported in 5.10. > > > > Best regards > Heikki Halmet > > The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland > Email: heikki.hal...@qt.io > Phone: +358408672112 > www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject > Facebook: www.facebook.com/qt > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] redistributing QPA and platform style plugins
> On Apr 3, 2017, at 3:09 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > Hi, > > As you know I've been tinkering with the Cocoa QPA plugin and the Macintosh > style. > > Are there legal restrictions to making my modified versions available (say on > github) other than maintaining the license headers and any licensing files? In short, no. You know Qt is licensed under GPL & LGPL, right? > How feasible is to extract these components and make it possible to build > them standalone (preferably using CMake)? A cursory look suggests that the > Cocoa platform plugin might be easier isolate than the built-in Macintosh > style, correct? Actually, I'm working on making the platform styles into plugins right now, so it'll be very easy to build QMacStyle standalone once https://codereview.qt-project.org/#/c/186909/ is merged. Keep in mind it'll still require a number of private headers, though. > And last but not least, does doing this have any incidence on "upstreaming", > should I ever decide to submit some of those modifications? Possibly, if others contribute to your modifications, they'll also need to sign the CLA and somehow "co-submit" the changes to the Qt Project alongside you. On that note, why not upstream the changes immediately and make things better for everyone? > Thanks, > René > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
> On Mar 10, 2017, at 9:33 AM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On sexta-feira, 10 de março de 2017 04:48:18 PST Joerg Bornemann wrote: >> No, but we have tried Duktape a year ago. >> I stopped working on a switch to Duktape because of three things: >> 1. C++-references to JS objects. One had to make sure that the engine >> doesn't garbage collect what you're referencing. That was possible in a >> hacky way. >> 2. Much worse: no way of implementing a QScripClass-like facility. >> Solvable, for sure, but nothing that's done easily along the way. >> 3. The insight that if we have to ship a JS engine anyways it can just >> be QtScript, or a stripped-down version of it for my sake. > > Except that QtScript has a very old JSC engine that hasn't received security > updates, or any updates of any kind, for some time. It would be irresponsible > to use it for new projects. > > Find another, please. We never said we will continue to use QtScript *as-is*. When I said JSC, I was talking about a modern version of JSC from the WebKit trunk, not the last copy of it that was bundled with QtScript. For standards-compliance & features, JSC is quite attractive as it's the most advanced. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
> On Mar 9, 2017, at 2:47 AM, Mathias Hasselmann <mathias.hasselm...@kdab.com> > wrote: > > > > Am 08.03.2017 um 21:23 schrieb Jake Petroules: >> The general idea is kind of following that of the Gradle wrapper, >> where any project that uses the Gradle build system also can include >> a standard wrapper script which obtains and bootstraps the build >> system itself before building your project, allowing ANY project >> based on that build system to be "zero dependencies". git clone & go, >> the system figures out the rest as much as it can. If qbs has similar >> capabilities like that, including online dependency fetching, I think >> a lot of people would appreciate it. > > Did you do any user research backing this claim, or is this a plain gut > feeling? CocoaPods is quite well loved by the Apple development community, which operates on the same principle as Gradle in that regard (personally I'd always source control the retrieved dependencies). Google also has internal tooling that utilizes online shared caches in order to build the massive projects that they have. > I know for a fact that Gradle and it's downloading features actually cause > serious problems for some of our customers who sit behind restrictive > firewalls and have to use complex proxy setups to > reach the Internet. They basically have to circumvent countless company > policies just to bootstrap Gradle. > > Besides I somehow doubt that it is even remotely reasonable to mimic a > build system that weights 225 MiB in size. Tools should know their task and > focus on that. No need for a kitchen sink. This would be an optional feature that you would by no means be required to use. Mobile developers will definitely want it though. Don't worry, Qt will never require network access to build. > Ciao, > Mathias > > -- > Mathias Hasselmann | mathias.hasselm...@kdab.com | Software Engineer > KDAB (Deutschland) GmbH KG, a KDAB Group company > Tel: +49-30-521325485 / +49-30-521325470 > KDAB - The Qt Experts > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
> On Mar 8, 2017, at 12:15 PM, Sune Vuorela <nos...@vuorela.dk> wrote: > > On 2017-03-08, Jake Petroules <jake.petrou...@qt.io> wrote: >> I'm working on the qbs bootstrapping. The requirements will be: a C++11 com= >> piler. End of requirements. Seriously. Not even bash, if you don't mind typ= >> ing a couple commands manually. > > I don't mind a bat script, a bash script or whatever is needed, but > that sounds great. >> >> Qt could then include a tiny bootstrap script which downloads and bootstrap= >> s qbs, then builds Qt (but the normal use case would be that you already ha= >> ve qbs installed). > > I really think that building Qt in the normal usecase would not involve > using Qt libraries. And a normal build setup should not touch the > network at all. In general I agree. If Qt was built with CMake, you wouldn't expect the Qt build scripts to obtain and bootstrap CMake itself. So I think that if it does so for qbs, you're already "getting more than you deserve". ;) The general idea is kind of following that of the Gradle wrapper, where any project that uses the Gradle build system also can include a standard wrapper script which obtains and bootstraps the build system itself before building your project, allowing ANY project based on that build system to be "zero dependencies". git clone & go, the system figures out the rest as much as it can. If qbs has similar capabilities like that, including online dependency fetching, I think a lot of people would appreciate it. Personally, I also prefer a build process never touch the network, but the average developer isn't that picky and just wants to Get Things Done. > /Sune > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
> On Mar 7, 2017, at 8:47 AM, Wolfgang Baron <wolfgang.ba...@gmx.net> wrote: > > On 7 Mar 2017, at 08:11, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > > There has been no discussion of qbs. Therefore, there is no > > decision on what to use for Qt 6. It might be cmake or qmake. > > Then please start that discussion now. Qbs is a secret weapon for all > developers trying to do test driven development but fighting long turn around > times in large projects. However, the lack of inside determination to feature > Qbs as the primary make system has stalled the acceptance and development of > Qbs. Qbs is a great improvement but lacks appropriate documentation, Please... file bug reports with what you think is missing. We feel that we're already doing a far better job than we did with qmake and want to make sure that Qbs has great documentation as it is very critical. I also do my best to make sure all qbs related questions on Stack Overflow are answered. > context sensitive help and first class support in Qt-Creator (yes, and there > may a little bug here or there). An official statement by the Qt Company > would greatly improve the willingness of the developer community to use and > improve Qbs. > > Please make that decision ASAP, so we can all enjoy the best make system ever > soon! Let me clarify: internally at The Qt Company we made the decision that Qbs will become the default build system for Qt 6. Technically the Qt Project has not yet made that decision but once the formalities are gone through, we will almost inevitably come to the same conclusion. > > Kind regards, > > Wolfgang > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] syncqt.pl in C++
> On Mar 6, 2017, at 1:51 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > > Em segunda-feira, 6 de março de 2017, às 21:25:48 CET, Egor Pugin escreveu: >> Hi, >> >> I'm experimenting with own builds of qt and found that raw sources in >> git repo (e.g. [1]) do not contain include dir. It is created by >> bin/syncqt.pl, so we have a perl dependency. > > Yes, we do. We've had that dependency for 15 years. And it will go away once Qt moves to Qbs as its default build system in Qt 6. > >> On later steps qt is built pretty good without any serious issues. >> >> Is there any attempts to rewrite syncqt.pl in c++? > > No. It will be "rewritten" (although the replacement will not be a direct translation) in JavaScript when Qt moves to Qbs. > >> Maybe someone, who tried to perform cmake-based build of qt, >> investigated this question? >> Could it be useful at all? > > I don't think we'll accept it. No, we won't. Qbs. ;) > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominate Mike Krus as approver
+1 for Mike Krus as Approver. > On Feb 6, 2017, at 8:11 AM, Sergio Martins <sergio.mart...@kdab.com> wrote: > > On 2017-02-06 14:54, Alex Blasche wrote: >>> There were no objections and maintainer of a module implies approver, so >>> could >>> somebody do the honours and grant Mike the rights please? The necessary >>> period >>> has long since passed. >> I am sorry but being the maintainer does not imply approver rights. > > https://wiki.qt.io/The_Qt_Governance_Model kind of implies you can't be a > maintainer if you're not an approver. > "How to become a Maintainer: An Approver who (...), may be nomiated (...)" > > What failed here is that he wasn't nominated for approver, so we need to wait > in any case :) > > +1 for approver, from me. > > > Btw, the "maintainers" group in gerrit > (https://codereview.qt-project.org/#/admin/groups/13,members) seems out of > date, it's missing Sean, Bogdan, Giulio, Milian and possibly more. > > > > Regards, > -- > Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt, C++ and OpenGL Experts > _______ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Eddy, "draft" does not do what you think it does. This is why no one can see the change. Please remove "draft" status and add "WIP: " at the front of the commit message instead so we can all take a look. Thanks, > On Jan 16, 2017, at 5:07 AM, Edward Welbourne <edward.welbou...@qt.io> wrote: > > On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote: >>> Just submitted first change set: >>> >>> https://codereview.qt-project.org/#/c/182341/ > > Frédéric Marchal replied: >> I'm seeing an error: "The page you requested was not found, or you do >> not have permission to view this page." > > I've just added you to the list of reviewers - does that help ? > > Eddy. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9)
LET'S DO IT! And thank you for following through on this idea. This will reduce our package testing burden significantly which is very important because it lowers the barrier to entry for us to actually add new platforms/installers. For example, adding tvOS to the combined macOS/iOS/Android package would be valuable. I would omit the host architectures (it provides no useful value since there are multiple host architectures in some cases) and target platforms from the filenames, though (like -android, -qnx, -android-ios), because they aren't there for the Windows package so it would be more consistent. The download descriptions should detail what each package contains. Also, can we simply subsume the QNX packages into the base enterprise packages? i.e. combine qt-enterprise-linux-x64-android and qt-enterprise-linux-x64-qnx? Or is there a licensing-related issue around that? And why do we need different packages based on the license, anyways? > On Dec 20, 2016, at 9:28 PM, Jani Heikkinen <jani.heikki...@qt.io> wrote: > > Hi all, > > I finally managed to do testing how big combined windows installer would be. > I was a bit surprised that it is only ~3.3 GB, which is still smaller than > combined mac-android-ios installer ;) Ok, this is done from 5.8 packages & > binaries so situation might be a bit different in 5.9 where we will have some > new binaries to be done. But in the other hand we will/should drop some so I > think the size of combined one should be still manageable. > > So I propose we will offer following set of offline installers from Qt 5.9 -> > > - For linux we will have 3 installers (instead of existing 5): > * qt-enterprise-linux-x64-android (already delivering this) > * qt-opensource-linux-x64-android (already delivering this) > ** Desktop gcc 64-bit > ** Android x86 > ** Android armv7 > * qt-enterprise-linux-x64-qnx (already delivering this) > ** Desktop gcc 64-bit > ** Qnx x86 > ** Qnx armv7 > ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries > will be offered like 5.8.0 > > - For mac we will have 2 installers (instead of existing 6): > * qt-enterprise-mac-x64-android-ios (already delivering this) > * qt-opensource-mac-x64-android-ios (already delivering this) > ** Desktop clang 64-bit > ** Android x86 > ** Android armv7 > ** iOS > > - For windows we will have 3 installers (instead of existing 17): > * qt-enterprise-windows-x86 (new) > * qt-opensource-windows-x86 (new) > ** Desktop MSVC 2013 x64 > ** Desktop MSVC 2015 x86 > ** Desktop MSVC 2015 x64 > ** Desktop MSVC 2017 x64 > ** Desktop MinGW 5.3 x86 > ** UWP MSVC 2015 x86 > ** UWP MSVC 2015 x64 > ** UWP MSVC 2015 armv7 > ** UWP MSVC 2017 x86 > ** UWP MSVC 2017 x64 > ** UWP MSVC 2017 armv7 > ** Android x86 > ** Android armv7 > * qt-enterprise-linux-x64-qnx (already delivering this) > ** Desktop MinGW 5.3 x86 > ** Qnx x86 > ** Qnx armv7 > ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries > will be offered like 5.8.0 > br, > Jani > > > From: Development <development-bounces+jani.heikkinen=qt...@qt-project.org> > on behalf of Thiago Macieira <thiago.macie...@intel.com> > Sent: Wednesday, November 30, 2016 5:05 PM > To: development@qt-project.org > Subject: Re: [Development] Qt 5.9 > > On quarta-feira, 30 de novembro de 2016 07:53:40 PST Jake Petroules wrote: >> How about we have one package per host platform which includes all possible >> hosts and targets compatible with it? Then we have 3 packages, ever. > > Or, at least, one binary per platform + compiler combination. So that's 1 > Linux package, 1 macOS package, 3 Windows packages today, with a 4th Windows > (MSVC 2017) coming for 5.9. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > 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 -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A new approach for Qt main()
> On Dec 9, 2016, at 5:02 AM, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote: > > On 09/12/2016 12:49, Jake Petroules wrote: >>> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø <tor.arne.ves...@qt.io> >>> wrote: >>> >>> On 09/12/2016 11:44, Lars Knoll wrote: >>>> Well, the problem is that the main() entry point is causing huge >>>> amounts of issues on at least Android and iOS. >>> >>> I don't know about Android, but on iOS this is patently false. >>> While the workaround is complex, it has worked very well in the 3 >>> years since its inception. Please don't use iOS as a straw-man in >>> this discussion. >> >> The point is that we shouldn't need such a workaround in the first >> place. That's kind of the point of this discussion. And as I said, >> the iOS situation is made even worse further by dynamic libraries. > > Obviously getting rid of workaround (in all platforms, not just iOS) would be > preferable. But describing the current (x years and counting) situation as > 'causing huge amount of issues' (on iOS) is just plain wrong, and derails the > discussion from pragmatic and constructive solutions to the problem. Again, I think you're missing Lars' point - "causing huge amount of issues" doesn't necessarily mean that we are constantly finding and fixing issues every week - in this context it means "the fact that we have a workaround at all", i.e. a suboptimal solution to an architectural problem that we wish wasn't there. Even ONE issue (the one that was "fixed" years ago) can still qualify as "huge amount of issues" simply because the solution in place is complicated and we don't like it. I think at this point we're nitpicking linguistics. We both understood what Lars meant and obviously both agree with him. > tor arne -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A new approach for Qt main()
> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote: > > On 09/12/2016 11:44, Lars Knoll wrote: >> Well, the problem is that the main() entry point is causing huge amounts >> of issues on at least Android and iOS. > > I don't know about Android, but on iOS this is patently false. While the > workaround is complex, it has worked very well in the 3 years since its > inception. Please don't use iOS as a straw-man in this discussion. The point is that we shouldn't need such a workaround in the first place. That's kind of the point of this discussion. And as I said, the iOS situation is made even worse further by dynamic libraries. > > Tor Arne > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A new approach for Qt main()
Without getting too much into the technical details, I'm all for it in
principle. It would certainly help on iOS especially as there's a lot of
complexity for the main() situation there, which is made even worse by trying
to support dynamic libraries.
Can you give an example of what the definition of QT_GUI_MAIN would look like
and what are the signatures of appInit and appExit?
> On Dec 9, 2016, at 1:35 AM, Morten Sorvig <morten.sor...@qt.io> wrote:
>
> Hi,
>
> We should consider changing the way Qt initialization and startup works.
> This is something I’ve personally been wanting to do for some time, and
> a recent offline discussion pushed it on my stack again.
>
> Currently, Qt and application startup looks something like this:
>
> int main(int argc, char **argv)
> {
> QApplication app(argc, argv);
>
> // Create root user objects/windows here
>
> return app.exec();
> }
>
> This is fine for the application but cause problems for the Qt platform
> implementation, which include:
>
> * The main entry point may be named something else than main()
>
> * The main entry point may be a callback which must be returned from
>
> * The platform/Qt/application initialization order is incorrect
>
> These have all been worked around in Qt platform code, for example by running
> Qt on a separate thread, using setjmp/longjmp to simulate a stack, or by
> temporarily setting up the native event loop before app.exec() is called.
>
> We can continue with the workarounds, but they lead to complications in Qt
> platform code and are also an extra hurdle for implementing support for new
> platforms, so from the Qt platform development point of view it is desirable
> with a cleanup.
>
> This would be an “all applications should/must port” event, not to be taken
> lightly. I think the porting would be trivial in many (if not most) cases,
> but some apps have special requirements for QApplication object management
> or main thread ownership. This includes our own QTestLib.
>
> As a starting point for a concrete API discussion I’ll briefly describe the
> solution I implemented for the NaCl port. The user API here is a macro which
> takes application init and exit callback functions:
>
> Q_GUI_MAIN(appInit, appExit);
>
> The use of a macro allows Qt to inject a main() call with native platform
> initialization code into the application, if needed. The init and exit
> functions are callbacks (which must return) and the root user objects
> must be created on the heap. The QApplication object is managed by Qt
> and has been created by the time appInit is called. The type of QApplication
> is decided by the macro, where there are CORE and WIDGETS variants as well.
>
> - Morten
>
>
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 29, 2016, at 11:28 PM, Alexander Blasche <alexander.blas...@qt.io> > wrote: > >> -Original Message- >> From: Development [mailto:development- >> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Jake Petroules > >>> That's why I still think we should proceed as I proposed: Keep online >>> offering >> as it is but drop separate macos + android offline installer (have macOS and >> macOS + mobile targets for macOS offline offering). Decreasing our offline >> installer offering is essential; needed testing effort at the moment is >> really huge >> & it is increasing all the time because of these parallel releases. That's >> why we >> need to decrease stuff to be tested to make our live easier. >> >> So don't test them. I'm not joking. There should be no reason to test every >> possible combination; just test each platform through the online installer >> and >> that should implicitly test that the offline one works. > > Sorry but that's not going to fly. > >> Our process shouldn't be so flimsy and untrustworthy that we're testing every >> possible combination. Let the community do it, and if there's a problem, >> we'll >> surely know soon enough. > > Software is a living and breathing thing. Its nature is such that it evolves > changes each time. Not testing is not an option. We could have more > confidence if history wouldn't proof us constantly wrong. Jake, even you had > your fair share of breaks during release time. Stop breaking other platforms > with your iOS changes and we can talk again ;) > > You can use the online installer if you want only one mobile platform but not > the other. Sure there is more MBs to download with offline but the releasing > and testing effort is an even greater concern. > > Dropping 32bit once Apple says so is a much more rewarding and likely > opportunity. How about we have one package per host platform which includes all possible hosts and targets compatible with it? Then we have 3 packages, ever. If our releasing and testing effort is the #1 concern over anything else, then having multi-gigabyte packages should not be a problem. We can then have: Windows host: includes Windows (i386-2015,x86_64-2015,i386-2015-winrt,x86_64-2015-winrt,armv7-2015-winrt) + Android (armv7,x86) macOS host: includes macOS (x86_64) + iOS (armv7,arm64,i386,x86_64) + Android (armv7,x86) Linux host: includes Linux (x86_64) + Android (armv7,x86) + QNX (armv7,x86)? By this estimation the Windows one would be around 3.5 GB (maybe less), about the same as the combined macOS+iOS+Android installer. In fact, because the WinRT and desktop binaries should be identical or very similar in many cases, they might compress even better than that (and/or we can look into the possibility of creating a unified Windows build whose DLLs work in either a classic desktop OR WinRT environment, and switch on the platform plugin. not sure to what degree that's possible) We could add the two 2013 builds (2013 WinRT is dead, so 2, not 4 or 5) and the MinGW to the Windows installer, ballooning it to around 6 GB or so (again, this may be totally fine), or we could separate those into 1 or 2 extra installers. Then we have between 3 and 5 rather than 13 like the 5.8 beta has currently. I don't know how useful the offline installers really are, so having the few users suffer a bit over longer download times should be OK given the nice tradeoff in testing. 90% of users should be on the online installer anyways. So, any good reasons we shouldn't do this? > >> One solution could be that we start using online ones at first & bring >> offline ones >> later. Earlier we have released beta with offline only so should we do this >> differently with Qt 5.9: >>> >>> Qt 5.9 alpha: src only >>> Qt 5.9 beta: online only > > I am against this. Online installers are much harder to handle when you have > to continuously install competing Qt versions. Testing requires to install 4 > different builds of Qt during for example beta time. Both types of builds > have their advantage and testing/trialing is not one where the online > installer shines. > > -- > Alex -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 29, 2016, at 11:28 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On quarta-feira, 30 de novembro de 2016 07:15:31 PST Alexander Blasche wrote: >> The big problem is that there are still plenty of 32bit users because they >> truly use 32bit platforms or 3rdparty software forces them to do so. Moving >> to 64 bit excludes users without alternatives. 32 bit does not exclude. >> Yes, I know this is a chicken and egg problem but right now we have reduced >> the 32bit package count for 5.9 already. Let's not rush too much. > > Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and > if > possible to 5.8 too. > >> There are already 11 windows binary types/packages in the current setup and >> that's too many. I see some opportunity when 2013 drops out in the future. > > How are there 11? There are currently 3 compilers and 2 architectures for > desktop Windows, so the maximum number possible is 6. I think you're forgetting WinRT? Also 2015 x86+x86_64+armv7 + 2013 x86 + armv7(phone), making 11. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 29, 2016, at 2:54 AM, Marco Piccolino <marco.a.piccol...@gmail.com> > wrote: > > We just had a little discussion about this on QtMob > (http://slackin.qtmob.org) where everybody does iOS/Android, and most people > do it on a macOS host. > It looks like people tend to use the online installer. > When it comes to the offline installers (which in our case are mainly used > for checking out betas, it seems) an installer for each platform seems to be > the preferred option. > This said, it seems that the main concern for our mobile devs is actually the > size of the Qt for iOS distribution per se and people would like to have the > option to not install simulator builds. I guarantee you we'll never do that while qmake remains the Qt build system. But in Qt 5.9 when Qt is built as shared libraries for iOS, a lot of the excess size should be moved out into external dSYM (debug symbol) files which can be made an optional component in the online installer. Also, 32-bit iOS is not long for this world, so we may be able to halve the size within the next few years when Apple removes all 32-bit support (even for applications) from iOS. > Br, > Marco Piccolino - QtMob community manager > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 29, 2016, at 3:08 AM, Jani Heikkinen <jani.heikki...@qt.io> wrote: > >>> >>> From: Development <development-bounces+jani.heikkinen=qt...@qt-project.org> >>> on behalf of Thiago Macieira <thiago.macie...@intel.com> >>> Sent: Tuesday, November 29, 2016 10:33 AM >>> To: development@qt-project.org >>> Subject: Re: [Development] Qt 5.9 >>> >>> On terça-feira, 29 de novembro de 2016 07:32:31 PST Jake Petroules wrote: >>>> I have no idea what I'm getting when I download these packages. Why do we >>>> maintain an inconsistency for macOS versus the other two host platforms? I >>>> don't see why we can't simplify this process and have ONE platform per >>>> installer... >>> >>> I agree with Jake. >>> >>> People download the one they need first (now!). If they need something else >>> later, they can just run the maintenance tool and have it install the rest. > > That is the case with online installation. With offline installer they cannot > update new stuff by using maintenance tool :( So users should prefer to > online installers; with that they got biggest flexibility & smallest package > size (online installer users are able to install just the stuff they need). > > But there is still users who need offline installers and that's why combined > installer (macOS, iOS + Android) is best for their purposes: If they don't > need mobile platforms at all they can just use pure desktop one. But if they > are doing mobile as well then they need to use that all-in-one offline > solution. > > That's why I still think we should proceed as I proposed: Keep online > offering as it is but drop separate macos + android offline installer (have > macOS and macOS + mobile targets for macOS offline offering). Decreasing our > offline installer offering is essential; needed testing effort at the moment > is really huge & it is increasing all the time because of these parallel > releases. That's why we need to decrease stuff to be tested to make our live > easier. So don't test them. I'm not joking. There should be no reason to test every possible combination; just test each platform through the online installer and that should implicitly test that the offline one works. Our process shouldn't be so flimsy and untrustworthy that we're testing every possible combination. Let the community do it, and if there's a problem, we'll surely know soon enough. > And how to encourage users to use online installers instead of offline ones? > One solution could be that we start using online ones at first & bring > offline ones later. Earlier we have released beta with offline only so should > we do this differently with Qt 5.9: > > Qt 5.9 alpha: src only > Qt 5.9 beta: online only > Qt 5.9 rc & final: online + offline > > br, > Jani > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
I don't know what sort of cross build and deployment environment you've set up, but I've worked with Qt Creator developing on actual embedded Linux hardware and the code-deploy-test cycle is lightning fast; no slower than desktop at all. iOS may be slower in particular due to our suboptimal build process implementation on that platform (and thus recommending that you use the iOS Simulator instead might not be a viable alternative), but I at least have never noticed any problems with slowness here so I'm not sure what you're referring to. Android, I'm not sure. Again, possibly due to the suboptimal build process implementation, but at least the emulators are blazing fast these days compared to the original SDK back in 2010 or so. > On Nov 28, 2016, at 11:37 PM, Alexander Nassian > <nass...@bitshift-dynamics.de> wrote: > > I don’t get the use case for having *only* iOS installed on my system. As > well as for example only a cross Qt for an embedded device (iOS is > practically the same thing). The normal development cycle should be (at least > in my opinion) mainly develop on the desktop and check on the target in a > regular manner. The cross build and deployment is enormously slower than on > the desktop (which is ok with a cycle as I described), so why would I ever > *only* use the cross build and deployment? Same thing for Android. Same thing > for any embedded Linux target, but in contrast to Android and iOS we don’t > deliver prebuilt binaries for them. > > Beste Grüße / Best regards, > Alexander Nassian > >> Am 29.11.2016 um 08:24 schrieb Jani Heikkinen <jani.heikki...@qt.io>: >> >>> -Original Message- >>> From: Development [mailto:development- >>> bounces+jani.heikkinen=qt...@qt-project.org] On Behalf Of Jake Petroules >>> Sent: maanantaina 28. marraskuuta 2016 20.23 >>> To: Alexander Blasche <alexander.blas...@qt.io> >>> Cc: development@qt-project.org; releas...@qt-project.org >>> Subject: Re: [Development] Qt 5.9 >>> >>> >>>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >>> <alexander.blas...@qt.io> wrote: >>>> >>>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >>> comments provided on this mail thread. The list describes the delta to Qt >>> 5.8 >>> packages: >>>> >>>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >>> >>> * For tvOS we drop 9.x and support 10.x >>> * For watchOS we drop 2.x and support 3.x >>> >>>> * MinGW remains 5.3 using 32 bit >>>> * Add MSVC 2017 64bit desktop >>>> * Add MSVC 2017 UWP (x64, x86, armv7) >>>> * Drop MSVC 2013 x86 >>>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >>> WinPhone 8.1 >>>> * Drop standalone macOS Android installer; One having iOS & Android >>> >>> As I said, let's not, and instead drop the massive macOS+iOS+Android >>> installer in favor of an iOS-only installer. >> >> Is it really so that users of iOS installer needs only iOS binaries and >> nothing for desktop side? >> >> In this case I agree this might be the optimal solution but this doesn't >> decrease amount of our installers and that's why I prefer just dropping that >> one & keep those two old ones: >> - one just for macOS + another one for macOS, iOS & Android >> >> br, >> Jani >> >>> >>>> * For Windows Android start doing Android Windows build with MinGW53 >>>> * Start supporting QNX 7.0 >>>> >>>> -- >>>> Alex >>>> >>>> ___ >>>> Development mailing list >>>> Development@qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petrou...@qt.io >>> The Qt Company - Silicon Valley >>> Qbs build tool evangelist - qbs.io >>> >>> ___ >>> 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 > -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 28, 2016, at 11:24 PM, Jani Heikkinen <jani.heikki...@qt.io> wrote: > >> -Original Message- >> From: Development [mailto:development- >> bounces+jani.heikkinen=qt...@qt-project.org] On Behalf Of Jake Petroules >> Sent: maanantaina 28. marraskuuta 2016 20.23 >> To: Alexander Blasche <alexander.blas...@qt.io> >> Cc: development@qt-project.org; releas...@qt-project.org >> Subject: Re: [Development] Qt 5.9 >> >> >>> On Nov 28, 2016, at 7:40 AM, Alexander Blasche >> <alexander.blas...@qt.io> wrote: >>> >>> Ok, let's summarize and restate the package list for Qt 5.9 based on the >> comments provided on this mail thread. The list describes the delta to Qt 5.8 >> packages: >>> >>> * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 >>> * For iOS we drop 7.x and support 8.x, 9.x, 10.x >> >> * For tvOS we drop 9.x and support 10.x >> * For watchOS we drop 2.x and support 3.x >> >>> * MinGW remains 5.3 using 32 bit >>> * Add MSVC 2017 64bit desktop >>> * Add MSVC 2017 UWP (x64, x86, armv7) >>> * Drop MSVC 2013 x86 >>> * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and >> WinPhone 8.1 >>> * Drop standalone macOS Android installer; One having iOS & Android >> >> As I said, let's not, and instead drop the massive macOS+iOS+Android >> installer in favor of an iOS-only installer. > > Is it really so that users of iOS installer needs only iOS binaries and > nothing for desktop side? > > In this case I agree this might be the optimal solution but this doesn't > decrease amount of our installers and that's why I prefer just dropping that > one & keep those two old ones: > - one just for macOS + another one for macOS, iOS & Android I have no idea what I'm getting when I download these packages. Why do we maintain an inconsistency for macOS versus the other two host platforms? I don't see why we can't simplify this process and have ONE platform per installer... Let's focus on delivering a better experience to our users and customers instead of dropping packages just because it makes our job a little bit easier. ;) > > br, > Jani > >> >>> * For Windows Android start doing Android Windows build with MinGW53 >>> * Start supporting QNX 7.0 >>> >>> -- >>> Alex >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Jake Petroules - jake.petrou...@qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 28, 2016, at 7:40 AM, Alexander Blasche <alexander.blas...@qt.io> > wrote: > > Ok, let's summarize and restate the package list for Qt 5.9 based on the > comments provided on this mail thread. The list describes the delta to Qt 5.8 > packages: > > * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12 > * For iOS we drop 7.x and support 8.x, 9.x, 10.x * For tvOS we drop 9.x and support 10.x * For watchOS we drop 2.x and support 3.x > * MinGW remains 5.3 using 32 bit > * Add MSVC 2017 64bit desktop > * Add MSVC 2017 UWP (x64, x86, armv7) > * Drop MSVC 2013 x86 > * Drop MSVC 2013 for WinRT/WinPhone & MSVC 2013 for WinRT 8.1 and WinPhone > 8.1 > * Drop standalone macOS Android installer; One having iOS & Android As I said, let's not, and instead drop the massive macOS+iOS+Android installer in favor of an iOS-only installer. > * For Windows Android start doing Android Windows build with MinGW53 > * Start supporting QNX 7.0 > > -- > Alex > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New library in qtbase
> On Nov 25, 2016, at 3:51 PM, Samuel Gaist <samuel.ga...@edeltech.ch> wrote: > > Hi, > > As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d > like to open a discussion about adding a new library in qtbase. > > Why this discussion ? > > Currently in work a pluggable notification system developed in its own > library in qtbase. > > Why add a new library ? > > Originally the submission was integrated in QPA however after some thoughts > and discussion, it was reworked to avoid that so that developers of non-GUI > application could also take advantage of notifications without the need of a > QGuiApplication. > > One of my motivation to move the code in its own library was that the second > implementation provided a run-time plugin selection mechanism much like the > QtSql module. After further discussion, the plugin selection has been moved > to build-time. > > The library as it is currently could even be in its own repository however > the goal in the long run is to replace the code used in QSystemTrayIcon by > calls to this module which at this time duplicates the showMessage logic for > macOS. Therefore having it as a separated repo would mean that qtbase would > depend on it to be build which IMHO is not an option. > > So basically we are at this point: > > 1) Keep the new notifications module I would rather it be a separate module, QtGui is becoming large. > 2) Move the code in the gui module since QImage might be used Maybe we can have two modules - QtNotifications and QtGraphicalNotifications, only the latter of which depends on QtGui. For Qt 6 I'd like to separate QtGui into two modules, one which handles just general graphics and imaging (QtGraphics), and another which handles the windowing system abstraction and user interface primitives (QtUi or QtGui). Of course that's a separate discussion but it would help situations like this... > In any case, the outcome of this discussion should likely be written in a > QUIP so we have a clear set of rules about adding new libraries in existing > Qt modules. > > Thank you for your attention > > Samuel > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Anyways, +1 overall. -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 23, 2016, at 1:49 AM, Tim Blechmann <t...@klingt.org> wrote: > > hi all, > >>>> The currently sold CPU's are not really the measurement stick here. The >>>> measurement stick is actually installed Win 32 systems. >>> Yes, but what's the 32-bit Windows install base which is capable of running >>> Qt? We only support Windows 7 and above now, so I can't imagine it's very >>> many. Perhaps we should try to find some metrics to base our decision on. >> >> That's an important point: since Qt 5.7, we no longer support anything older >> than Windows 7. That was the first Windows with decent 64-bit support and >> computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-bit >> version pre-installed. So the chances of users running 64-bit Windows are >> much >> higher now. > > when using qt inside a plugin it is not necessarily a question how many > users are on 64-bit windows, but how many are on 64-bit hosts, as 32-bit > host can run on 64-bit windows. True, and this is a good point. Many Windows applications are still 32-bit. > > i don't care about the binary packages, though. as long as i can still > build from sources, i'm fine ... but please don't completely drop > support for 32-bit windows. Of course this is out of the question (and would be of little to no benefit to Qt). We're talking ONLY about binary packages here, not to worry. :) > > cheers, > tim > > > _______ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 22, 2016, at 11:56 PM, Alexander Blasche <alexander.blas...@qt.io> > wrote: > > > >> -Original Message- >> From: Development [mailto:development- >> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Thiago >> Macieira > > > >> Good point. Considering that MSVC 2017 is coming (RC is already out), I'd >> also >> be prepared to have it available for 5.9, so I propose: >> >> 5.7 (for comparison, no change): >>32-bit 64-bit >> MSVC 2013 Y Y >> MSVC 2015 Y Y >> MSVC 2017 N N >> MinGW Y N >> (5 packages) >> >> 5.8: >>32-bit 64-bit >> MSVC 2013 Y Y >> MSVC 2015 N Y > I am not aware that we are dropping 2015 32bit support in 5.8. I thought the > platform/compiler definition for 5.8 was set in stone a long time ago. > >> MSVC 2017 N N >> MinGW Y Y >> (5 packages) >> >> 5.9: >>32-bit 64-bit >> MSVC 2013 N Y >> MSVC 2015 N Y >> MSVC 2017 N Y >> MinGW N Y >> (4 packages) > > I don't think we can drop all 32bit support. I do believe MSVC 2017 should be > part of the deal though. That's a good suggestion. Keeping these two options > in mind, I suggest to drop MSVC 2013 32 bit against MSVC 2017 64bit. This > keeps the number of packages the same. No one suggested dropping *all* 32-bit support just now, but I think we should reduce the number of 32-bit packages now and move towards eliminating them entirely within the next few releases. > >> This also allows us to pick one compiler to provide 32-bit support with if we >> need to. I just think it's time to let it die and get people who need it to >> compile >> from source. > > Compiling Qt from source (especially on Windows) is still a major headache > for our customers. s/customers/users/; this applies to all license types. Also, I don't think this is a relevant counterargument. Compiling Qt from source statically is a major headache for our users as well, yet we don't provide binary packages for Qt built statically. Let's instead focus on the question of whether 32-bit support is actually relevant to enough of our users to bother spending resources on it. >> >> There are no current Intel 32-bit only CPUs that regular Windows runs on, >> only >> legacy. I don't know AMD's product line, but I'd be surprised if it is >> different. > > The currently sold CPU's are not really the measurement stick here. The > measurement stick is actually installed Win 32 systems. Yes, but what's the 32-bit Windows install base which is capable of running Qt? We only support Windows 7 and above now, so I can't imagine it's very many. Perhaps we should try to find some metrics to base our decision on. > > > -- > Alex > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On Nov 22, 2016, at 5:58 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On terça-feira, 22 de novembro de 2016 16:07:25 PST Thiago Macieira wrote: >> On terça-feira, 22 de novembro de 2016 23:46:32 PST Jake Petroules wrote: >>>> - For MinGW I propose to start delivering 64 bit binary packages instead >>>> of 32 bit one & start using MinGW 6.x (6.2?) >>> >>> Does this make sense when we're still delivering 32-bit MSVC packages? I'd >>> opt to keep 32-bit or have both. >> >> I agree with Jake: replacing one with the other is not a good idea. We >> should provide both for a time, before dropping 32-bit. > > If we still have time, I'd like to see MinGW 64-bit for 5.8, so we can drop > the 32-bit binary build in time for 5.9. > > Otherwise, if we have to wait for 5.9 to bring MinGW 64-bit, then we can't > drop 32-bit until 5.10. Agreed. We should also consider dropping 32-bit MSVC since we've had both for a while and we only support Windows 7 and above now, which should mean adoption is good enough to do so. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Naming of path/directory-related environment variables in Qt
> On Nov 16, 2016, at 4:06 AM, J-P Nurmi <jpnu...@qt.io> wrote: > >> On 11 Nov 2016, at 17:10, Matthew Woehlke <mwoehlke.fl...@gmail.com> wrote: >> >> On 2016-11-11 10:13, Mitch Curtis wrote: >>> I'd like to establish some kind of convention for naming >>> path/directory-related environment variables in Qt, with the hope >>> that it could be set in stone with e.g. one of these newfangled >>> QUIPs. [...] So, can we all agree on using "PATH" when naming >>> environment variables that refer to paths? >> >> I believe that `FOO_DIR` is typical for variables that name a *single* >> directory. For multiple directories, XDG prefers `FOO_DIRS`, but >> otherwise `FOO_PATH` seems most common. >> >> Examples: >> PATH (duh) >> LD_LIBRARY_PATH >> PYTHONPATH >> LUA_PATH >> QT_PLUGIN_PATH >> LIBPATH >> COMPILER_PATH >> LIBRARY_PATH >> CPATH >> C_INCLUDE_PATH >> CPLUS_INCLUDE_PATH >> >> TMPDIR >> KDEDIRS >> XDG_DATA_DIRS >> XDG_RUNTIME_DIR >> >> I think a good rule would be single directories should use _DIR if >> anything (some cases e.g. HOME may be exceptions), and list of >> directories should use _PATH. >> >> Please don't use `FOO_FOLDER` :-). > > +1 for _DIR for single directories, and _PATH for list of directories. Also +1 > > -- > J-P Nurmi > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickControls for desktop: what's the plan?
> On Nov 10, 2016, at 6:08 AM, Marco Martin <notm...@gmail.com> wrote: > > On Thursday 10 November 2016 11:11:35 Olivier Goffart wrote: >> Writing and polishing styles to pixel perfection is indeed lot of work. And >> QStyle has the advantage hat it already exists. However one can copy-paste >> the code to turn existing styles into QCC2 style. (You will have two style >> to maintain since QtWidgets is still maintained) >> >> The proxy style to QStyle that Marco is developing is a good intermediate >> solution for people wanting to develop cross platform desktop applications, >> while waiting for proper native looking themes on each platform. > > yeah, I also see it more like as a temporary solution as well, if not else > for > the fact that it can work only on QApplication instances. > For us it's important to get in a short enough time span a good compelling > reasons for applications to start using qtquickcontrols2, but I agree on the > long run something else not linking to qwidgets is needed (which also speaks > against official inclusion in Qt, as would get deprecated soon-ish in that > case) OK, I think that's a very reasonable assessment. After that, if you have any ideas around creating a proper long term solution for QQC2 that doesn't rely on QStyle, we'd love to hear them! Patches are welcome as well. :) > -- > Marco Martin > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickControls for desktop: what's the plan?
> On Nov 9, 2016, at 3:40 PM, Aleix Pol <aleix...@kde.org> wrote: >>> we plan to keep it >>> multiplatform and with no external dependency other than Qt modules (that's >>> what KDE framework tier 1 means). A big reason is actually that it would be >>> quite easier to contribute to it. >> >> And when we do the work ourselves because we'll eventually have to, your >> work will be obsoleted and have been for nothing because no one will have a >> reason to use it when the upstream solution will be maintained by the Qt >> Project and on by default. Whereas if we work *together*, no one wastes time >> and we have a unified experience for everyone. >> >> All this does is fragment Qt, and look how well fragmentation has worked for >> Android. > > I don't think this is the correct way to have this conversation. > > Threatening that if things are developed outside Qt licensing policies > we're breaking the Qt project is way out of line, especially > considering the long collaboration history we've had between KDE and > Qt. There's a big difference between creating a new module that provides completely new functionality (in which case it would be disappointing yet completely fair to keep it out of the Qt Project if that's your choice), and adding a missing feature to an existing Qt module while deliberately keeping it out of the hands of the Qt Project and its commercial customers who pay for Qt to exist in the first place. That's rather selfish, and also rather shortsighted, because we WILL have to do this ourselves eventually if we want anyone to take QQC2 seriously. So why duplicate the work and let it all go to waste? > > Aleix -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QCS2016 Session Notes - QUIPs for Qt
Agree with meta/quips > On Nov 9, 2016, at 10:11 AM, Louai Al-Khanji <louai.al-kha...@qt.io> wrote: > > As far as I am concerned meta/quips will do just fine. It’s not worth a > bikeshed. > > Cheers, > Louai > > On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne" > <development-bounces+louai.al-khanji=qt...@qt-project.org on behalf of > kai.koe...@qt.io> wrote: > > > >> -Original Message- >> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- >> project.org] On Behalf Of Oswald Buddenhagen >> Sent: Wednesday, November 09, 2016 4:01 PM >> To: development@qt-project.org >> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt >> >> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote: >>> +1 for qt/quips, I don't think of it as a web site thing either. >>> >> well, i don't want it in qt/ - this is not a generic namespace for stuff that >> doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git >> (with an accurate status field), or be a submodule of an aggregated module. >> >> i can offer meta/ as an alternative. > >meta/quips would work for me, too. or qt-project/quips? > >> or maybe qtqt/ - that one already exists, but i suspect the objections will >> be >> the same as to www/. > >No idea what qtqt/ should stand for :) > >>> Kai Koehne wrote: >>>> I'd slightly prefer >>>> >>>> qt/quips >>>> >>>> because it's not directly related to the website, even if we'll >>>> generate an html presentation out of it. We might even consider >>>> adding it to qt/qt5.git at one point ... >>> >> that makes no sense to me at all. the scope if this is certainly wider than >> the >> qt product itself. > >Why do you think so? This is the repository where we want to document > processes >and design decisions for Qt, the project _and_ the product. It's surely > more meta than >most of the modules, but we've also projects like qt/qtqa and > qt/qtrepotools, which >do not contain a qt module, either. > >Regards > >Kai > ___ >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 -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickControls for desktop: what's the plan?
> On Nov 9, 2016, at 7:30 AM, Marco Martin <notm...@gmail.com> wrote: > > On Tuesday 08 November 2016 18:47:06 Jake Petroules wrote: >>> I was planning to keep it a KDE project, probably as a tier 1 framework. >> >> That seems like a bad idea. Let's submit it to Qt so that everyone can >> benefit and it can be kept better maintained alongside Qt and for all >> platforms. > > Being maintained as as an upstream Qt project, may be appealing, yes. > However, aslo it being a KDE project everyone can benefit. Everyone, as long as they use LGPL. That's not everyone. > we plan to keep it > multiplatform and with no external dependency other than Qt modules (that's > what KDE framework tier 1 means). A big reason is actually that it would be > quite easier to contribute to it. And when we do the work ourselves because we'll eventually have to, your work will be obsoleted and have been for nothing because no one will have a reason to use it when the upstream solution will be maintained by the Qt Project and on by default. Whereas if we work *together*, no one wastes time and we have a unified experience for everyone. All this does is fragment Qt, and look how well fragmentation has worked for Android. > > -- > Marco Martin > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickControls for desktop: what's the plan?
> On Nov 8, 2016, at 1:45 AM, Marco Martin <notm...@gmail.com> wrote: > > On Tuesday 08 November 2016, Alberto Mardegan wrote: >>> Even if is still incomplete (and are things that unfortunately can't be >>> fully styled yet in a fully desktop friendly way) it seems to work >>> remarkably well. >> >> That looks smart and simple! Any plans for submitting that to Qt, maybe >> as a playground project? >> >> Anyway, do you have a bug tracker? > > I was planning to keep it a KDE project, probably as a tier 1 framework. That seems like a bad idea. Let's submit it to Qt so that everyone can benefit and it can be kept better maintained alongside Qt and for all platforms. > -- > Marco Martin > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] COIN
> On Sep 27, 2016, at 3:00 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On terça-feira, 27 de setembro de 2016 19:27:07 PDT Liang Qi wrote: >>> I search over google and checked code.qt.io/cgit/ but could not find COIN >>> scripts. Is it public domain? Let me know if someone knows the repo link. >> >> https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ >> >> It's not in public domain yet. > > Note that public domain is not the same thing as open source. I would advise > the COIN team against releasing it as public domain. Choose a suitable, open > source licence for it. "public domain" is different from "Public Domain"; I think all parties involved understood what was meant. Obviously we wouldn't be so uninformed as to release a project as Public Domain in lieu of a proper Open Source license. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
> On Sep 20, 2016, at 12:18 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > 20.09.2016, 22:11, "Matthew Woehlke" <mwoehlke.fl...@gmail.com>: >> That works with e.g. make/ninja, but not so well with VS, but that's a >> VS failing that I don't see how Qbs could overcome, given that VS *is* >> the build tool and doesn't AFAIK support dynamic build graphs. > > QBS does not use VS as a build tool, it is not a project generator Although it can act as one; I recently added support for generating VS projects: https://codereview.qt-project.org/#/c/91353/ Qbs still performs the build entirely on its own though, the VS output is no more than a file listing. > > -- > Regards, > Konstantin > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Help! configure won't configure on Windows
> On Sep 18, 2016, at 4:44 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On domingo, 18 de setembro de 2016 22:22:57 PDT Oswald Buddenhagen wrote: >> On Sat, Sep 17, 2016 at 12:49:36PM -0700, Thiago Macieira wrote: >>> So how am I going to reconfigure qtbase once I've built the rest of qt5? >> >> you don't. you keep configuring qt5, or you clean out the non-qtbase >> artifacts first. >> >>> My workflow is: >> you should consider yourself lucky that this ever worked. > > It's worked for over 4 years. I may not be the only one doing this. > > Please fix it. I don't see why we should, it seems an illogical workflow to configure qt5 and then expect to be able to configure from qtbase... > >> >>> cd qtbase >>> configure >>> make >>> repeat for a month >>> cd .. # to qt5.git >>> qmake && make >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NSURLConnection backend in 5.6.2
> On Sep 14, 2016, at 12:46 AM, Lars Knoll <lars.kn...@qt.io> wrote: > > That’s the policy we have had all the time. No feature removal or additions, > no API changes in patch level releases. > > If a feature is really unused, or causes larger issues one can of course > discuss exceptions, but it should be a conscious decision involving the > relevant maintainers. But we didn't remove a "feature", only a particular implementation detail of an existing feature, which should have no practical effect. I don't think that a rare combination of configure options now resulting in different behavior should really count as a feature change. The feature itself is "SSL support", which is unchanged. Otherwise, any change to implementation details to fix bugs could theoretically be considered a feature removal or addition... > > Cheers, > Lars > > > > > On 14/09/16 09:36, "Development on behalf of Morten Sorvig" > <development-bounces+lars.knoll=qt...@qt-project.org on behalf of > morten.sor...@qt.io> wrote: > >> Should we have a “no feature removal for cleanup reasons in patch >> releases” policy? That’s easy to understand for everyone and we >> don’t have to make the "is it obscure enough” judgement. >> >> (The build failure could have been easily fixed so I don’t see >> it as a relevant reason.) >> >> Morten >> >> >> >>> On 13 Sep 2016, at 20:33, Jake Petroules <jake.petrou...@qt.io> wrote: >>> >>> Because the APIs are deprecated by Apple so they would have had to be >>> removed/changed soon anyways, especially when an alternative (which is the >>> default now) is already available. Also it caused build failure on >>> tvOS/watchOS. >>> >>>> On Sep 13, 2016, at 11:25 AM, Thiago Macieira <thiago.macie...@intel.com> >>>> wrote: >>>> >>>> The changelog contains this entry: >>>> >>>> - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has >>>> been removed, since SecureTransport is the default SSL backend on iOS >>>> and is enabled by default. This means that building with -no-openssl >>>> -no-securetransport will no longer provide SSL capabilities on iOS. >>>> >>>> WTH? Why are we removing options in a patch release? What happened? >>>> >>>> Is the backend so severely broken that it needed to be removed? >>>> -- >>>> Thiago Macieira - thiago.macieira (AT) intel.com >>>> Software Architect - Intel Open Source Technology Center >>>> >>>> ___ >>>> Development mailing list >>>> Development@qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petrou...@qt.io >>> Consulting Services Engineer - The Qt Company >>> Qbs build tool evangelist - qbs.io >>> >>> ___ >>> 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 mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NSURLConnection backend in 5.6.2
> On Sep 13, 2016, at 1:15 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote: >> On Sep 13, 2016, at 12:55 PM, Thiago Macieira >> <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: > >> On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: >> I'd be blown away if they did and I can't see how there would be a >> dependency. Also using deprecated APIs is a bad idea for app store >> compliance. I believe there have been rejections for that in the past. >> >> But did it work on macOS too? Or was it exclusively for the Apple embedded >> platforms? >> >> NSURLConnection was only ever used on iOS, not any of the other platforms. > > Ok, then that's less of a problem. If it could only be used on a platform > where no one will ever want to use it again, we can reasonably conclude no > one > will be using it. Testing again that quoting is fixed? > >> PS: can you configure your mail client to quote text properly in the >> plain-text format? >> >> Tell me how to do that in Apple Mail and I'm happy to. I think I heard a >> couple complaints after upgrading to Apple Mail 10 (Sierra). There's a >> checkbox under responding, "Use the same message format as the original >> message", maybe that will help. > > I don't know how. Check with other Mac users. This is not a new thing, you've > been doing it for months or more. > > If you can't configure your MUA to quote properly for a mailing list, don't > use > it for mailing lists. > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NSURLConnection backend in 5.6.2
On Sep 13, 2016, at 1:15 PM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote: On Sep 13, 2016, at 12:55 PM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com><mailto:thiago.macie...@intel.com>> wrote: On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: I'd be blown away if they did and I can't see how there would be a dependency. Also using deprecated APIs is a bad idea for app store compliance. I believe there have been rejections for that in the past. But did it work on macOS too? Or was it exclusively for the Apple embedded platforms? NSURLConnection was only ever used on iOS, not any of the other platforms. Ok, then that's less of a problem. If it could only be used on a platform where no one will ever want to use it again, we can reasonably conclude no one will be using it. PS: can you configure your mail client to quote text properly in the plain-text format? Tell me how to do that in Apple Mail and I'm happy to. I think I heard a couple complaints after upgrading to Apple Mail 10 (Sierra). There's a checkbox under responding, "Use the same message format as the original message", maybe that will help. I don't know how. Check with other Mac users. This is not a new thing, you've been doing it for months or more. Testing that quoting hopefully works properly. If you can't configure your MUA to quote properly for a mailing list, don't use it for mailing lists. -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NSURLConnection backend in 5.6.2
On Sep 13, 2016, at 12:55 PM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: I'd be blown away if they did and I can't see how there would be a dependency. Also using deprecated APIs is a bad idea for app store compliance. I believe there have been rejections for that in the past. But did it work on macOS too? Or was it exclusively for the Apple embedded platforms? NSURLConnection was only ever used on iOS, not any of the other platforms. PS: can you configure your mail client to quote text properly in the plain-text format? Tell me how to do that in Apple Mail and I'm happy to. I think I heard a couple complaints after upgrading to Apple Mail 10 (Sierra). There's a checkbox under responding, "Use the same message format as the original message", maybe that will help. -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NSURLConnection backend in 5.6.2
On Sep 13, 2016, at 12:32 PM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: On terça-feira, 13 de setembro de 2016 18:41:50 PDT Jake Petroules wrote: They can and have before. Anyways, it doesn't matter. The code was unused, untested, and was in the way of other things, so its removal is inconsequential. Also it caused build failure on tvOS/watchOS. Are we sure none of our users depended on it? I'd be blown away if they did and I can't see how there would be a dependency. Also using deprecated APIs is a bad idea for app store compliance. I believe there have been rejections for that in the past. -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
On Sep 13, 2016, at 12:10 PM, Christian Kandeler
<christian.kande...@qt.io<mailto:christian.kande...@qt.io>> wrote:
[Sorry about the formatting, using outlook]
Stephen Kelly wrote:
> Here's the CMake version:
[ ... ]
> execute_process(
> COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list
> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
> OUTPUT_VARIABLE fileList
> )
How do you know where the input file is located?
> However, it is cheating in the same way that the QBS version from
> Christian is cheating - it assumes '--list' exists:
Yes, I was assuming a cooperating tool.
> Christian, can you create a version which does not require --list?
There are two possibilities:
a) The inner workings of the tool are known and "simple enough". That's the
case in Bo's example, so there we could just open the input file and derive the
output artifacts from the number we find there.
b) Otherwise, our outputArtifacts script has to run the tool in "real mode"
(using the "--generate" option). The actual command would be a no-op then. This
is icky, both conceptually and for practical reasons, because commands of
non-competing rules are run in parallel, whereas the outputArtifacts scripts
are not. I think so far we only use this approach for the infamous qdoc tool.
And asset catalogs, XIBs/NIBs/storyboards, Java sources, and TypeScript sources.
Christian
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
--
Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io>
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io<http://qbs.io>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NSURLConnection backend in 5.6.2
On Sep 13, 2016, at 11:40 AM, Konstantin Tokarev <annu...@yandex.ru<mailto:annu...@yandex.ru>> wrote: 13.09.2016, 21:33, "Jake Petroules" <jake.petrou...@qt.io<mailto:jake.petrou...@qt.io>>: Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. AFAIK they cannot remove API from released SDK, and users may choose to use it even if it's not latest and greatest anymore. They can and have before. Anyways, it doesn't matter. The code was unused, untested, and was in the way of other things, so its removal is inconsequential. Also it caused build failure on tvOS/watchOS. On Sep 13, 2016, at 11:25 AM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: The changelog contains this entry: - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has been removed, since SecureTransport is the default SSL backend on iOS and is enabled by default. This means that building with -no-openssl -no-securetransport will no longer provide SSL capabilities on iOS. WTH? Why are we removing options in a patch release? What happened? Is the backend so severely broken that it needed to be removed? -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> , ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NSURLConnection backend in 5.6.2
Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. Also it caused build failure on tvOS/watchOS. On Sep 13, 2016, at 11:25 AM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: The changelog contains this entry: - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has been removed, since SecureTransport is the default SSL backend on iOS and is enabled by default. This means that building with -no-openssl -no-securetransport will no longer provide SSL capabilities on iOS. WTH? Why are we removing options in a patch release? What happened? Is the backend so severely broken that it needed to be removed? -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
I just found a perfect example of how hard building a JAR file is in qmake for example, compared to qbs: qbs-javac-scan.pro Description: qbs-javac-scan.pro qbs-javac-scan.qbs Description: qbs-javac-scan.qbs And the qmake version technically doesn't even handle dependencies properly (e.g. removing an anonymous inner class will still result in the corresponding (stale) class file being included in the JAR file).On Sep 8, 2016, at 9:16 AM, Jake Petroules <jake.petrou...@qt.io> wrote: Another thing that's very hard to do in other build systems is building Java code. The class files emitted by a Java compiler actually vary depending on the contents of the Java files themselves. Imagine you've built a JAR file, and then you add a new anonymous inner class within one of your Java source files. The command line invocation to build the JAR file needs to be updated to contain the new class file that will result. Impossible with qmake/CMake/Makefiles/etc. Whereas Qbs has sophisticated support exactly for this case: https://github.com/qt-labs/qbs/tree/master/share/qbs/modules/java, made possible by its dynamic build graph. On Sep 8, 2016, at 6:52 AM, Bo Thorsen <b...@vikingsoft.eu> wrote: Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev: > The only problem is that you have to run moc on each of the .h files. Run moc from inside script when you generate header. Yes, I thought about that at the time as well. While simple enpough, there are some complications. You would have to run moc exactly like if it was done by the qmake built makefiles, with exactly the same environment and arguments. Not impossible, but it does sound brittle. For example different qmake versions might do things differently. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io ___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.ioConsulting Services Engineer - The Qt CompanyQbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
Another thing that's very hard to do in other build systems is building Java code. The class files emitted by a Java compiler actually vary depending on the contents of the Java files themselves. Imagine you've built a JAR file, and then you add a new anonymous inner class within one of your Java source files. The command line invocation to build the JAR file needs to be updated to contain the new class file that will result. Impossible with qmake/CMake/Makefiles/etc. Whereas Qbs has sophisticated support exactly for this case: https://github.com/qt-labs/qbs/tree/master/share/qbs/modules/java, made possible by its dynamic build graph. On Sep 8, 2016, at 6:52 AM, Bo Thorsen <b...@vikingsoft.eu<mailto:b...@vikingsoft.eu>> wrote: Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev: > The only problem is that you have to run moc on each of the .h files. Run moc from inside script when you generate header. Yes, I thought about that at the time as well. While simple enpough, there are some complications. You would have to run moc exactly like if it was done by the qmake built makefiles, with exactly the same environment and arguments. Not impossible, but it does sound brittle. For example different qmake versions might do things differently. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Network Maintainership Changes
On Sep 7, 2016, at 11:45 AM, Morten Sorvig <morten.sor...@qt.io<mailto:morten.sor...@qt.io>> wrote: On 6 Sep 2016, at 21:05, Richard Moore <r...@kde.org<mailto:r...@kde.org>> wrote: Hi All, As some of you may know, I'm planning to step down as maintainer of Qt Network. This is because now that the Qt company has people in a position to work on the network stack full time I think it makes much more sense for them to be the maintainer - it doesn't mean I'll be moving away from working on Qt (in fact I hope it will mean I'll have more time to actually get things done as a result). I'd like to nominate Timur as my replacement - he's already spent an inordinate amount of time fixing bugs, to say nothing of adding support for HTTP/2 so I'm sure things are in good hands. https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z On a similar note, I'd like to nominate Jesús Fernández as the maintainer of the QtNetworkAuth module - he wrote it after all! https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z +1 to both Timur and Jesús from me. Also what Morten said. Morten ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
On Sep 6, 2016, at 5:14 PM, Kevin Kofler <kevin.kof...@chello.at<mailto:kevin.kof...@chello.at>> wrote: Ch'Gans wrote: I never wanted to use CMake b/c for me it look like a gross hack (Reminds me of GNU M4). The CMake language is much easier to use than m4, and also there is just one layer rather than having autoconf on top of m4, with shell script snippets mixed in. There is a reason CMake is being proposed for Qt and autotools is not. Makefiles are out-dated (no punt intended) and so is CMake and any other Makefile-based tools. Makefiles are dead! CMake is ill! (Friendly, easy and provocative argument) CMake can generate other build files than makefiles (e.g., the Ninja generator is basically a drop-in replacement). Again, Ninja has its architectural limitations as well, so this would not be useful. The problem isn't (just) Makefiles, it's the fact that we don't have a build tool that is fundamentally better and more powerful than anything we've ever had before, and we CAN have this. It's like C++ vs Motorola 68k assembler. I guess somebody could even get CMake to write Qbs files, it would just be one more generator. :-) Again, useless, because Qbs is more powerful and at a much higher level of abstraction, so a generator would only be useful in the reverse direction. It's like trying to make a compiler to transform Motorola 68k assembler to C++. Only the reverse transformation of that can done in a useful manner. Kevin Kofler ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
On Sep 5, 2016, at 4:12 PM, Jake Petroules <jake.petrou...@qt.io<mailto:jake.petrou...@qt.io>> wrote: On Sep 5, 2016, at 3:38 PM, Kevin Kofler <kevin.kof...@chello.at<mailto:kevin.kof...@chello.at>> wrote: - (Milian) CMakeis used by e.g. clang and it works for them … and the whole stack of software from the KDE project, and other large projects. Keep in mind that "large projects use X, therefore X is great" is a poor argument, because large does not necessarily mean complex. Any build tool is good at handling a large project (including autotools), but few are good at handling complex ones. Moreover, because Y uses X and it works for Y, does not mean X works for Z. As an incredibly simple example, make is inherently limited in that it cannot even represent a rule with multiple outputs (there are some workarounds, but they are hacky and rather limited in how they can be applied). And ninja is no magic bullet here either, because that still represents a static build graph, whereas the content of Qbs' build graph can actually change during the execution of the build. Many of you seem to not understand how complex build tools can get and just how simple Qbs can make problems that are incredibly challenging in other systems. Perhaps you should actually try Qbs before complaining about it. Or perhaps we simply need more/better examples to show the community the difference between the Rolls-Royce Trent 900 jet engine that is Qbs, and the wet firecrackers that are CMake and qmake. Perhaps both. :) No one WANTS to use CMake. They use it because they HAVE to, because it's the only thing that exists. Feel free to long for the "good old days" of the stone age, when food was scarce, disease was rampant, and life was short, but we will move forward towards a better future. -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io/> s/CMake/Qbs/ Fail. -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
On Sep 5, 2016, at 3:38 PM, Kevin Kofler <kevin.kof...@chello.at<mailto:kevin.kof...@chello.at>> wrote: - (Milian) CMakeis used by e.g. clang and it works for them … and the whole stack of software from the KDE project, and other large projects. Keep in mind that "large projects use X, therefore X is great" is a poor argument, because large does not necessarily mean complex. Any build tool is good at handling a large project (including autotools), but few are good at handling complex ones. Moreover, because Y uses X and it works for Y, does not mean X works for Z. As an incredibly simple example, make is inherently limited in that it cannot even represent a rule with multiple outputs (there are some workarounds, but they are hacky and rather limited in how they can be applied). And ninja is no magic bullet here either, because that still represents a static build graph, whereas the content of Qbs' build graph can actually change during the execution of the build. Many of you seem to not understand how complex build tools can get and just how simple Qbs can make problems that are incredibly challenging in other systems. Perhaps you should actually try Qbs before complaining about it. Or perhaps we simply need more/better examples to show the community the difference between the Rolls-Royce Trent 900 jet engine that is CMake, and the wet firecrackers that are CMake and qmake. Perhaps both. :) No one WANTS to use CMake. They use it because they HAVE to, because it's the only thing that exists. Feel free to long for the "good old days" of the stone age, when food was scarce, disease was rampant, and life was short, but we will move forward towards a better future. -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Mike Krus as tvOS maintainer
+1 On Aug 30, 2016, at 4:51 AM, Tor Arne Vestbø <tor.arne.ves...@qt.io<mailto:tor.arne.ves...@qt.io>> wrote: Hi all! Mike Krus was so kind to contribute support for Apple's tvOS to the UIKit platforms, and I'd like to make it official that he's the tvOS maintainer. I'll still be maintaining the overall UIKit platform, including iOS. Cheers, Tor Arne ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt on Apple watchOS
Hi All, Preliminary support for Qt on Apple watchOS has been merged to dev branch (targeting Qt 5.9): https://codereview.qt-project.org/#/c/159725/ Due to platform limitations, there is no support for graphical content like QtWidgets, QML, etc., but can be useful for sharing cross platform backend code. -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
I always find it hilarious how people start debates about UTF-8 vs UTF-16 in string APIs. Let us not forget that in an ideal world, the QString API wouldn't expose the underlying encoding *at all*, and it would be an implementation detail unknown to users. See Swift's String class for example: https://developer.apple.com/swift/blog/?id=30 If you're thinking in terms of code units instead of in terms of grapheme clusters, you don't truly understand Unicode. And also end up with historical radioactive waste like UTF-16. On Jul 12, 2016, at 5:58 AM, charleyb123 . <charleyb...@gmail.com<mailto:charleyb...@gmail.com>> wrote: On Tue, Jul 12, 2016 at 3:47 AM, Marco Bubke <marco.bu...@qt.io<mailto:marco.bu...@qt.io>> wrote: , Lets face it, the world is much bigger than Qt, and I think there is much to gain if we integrate better with alien libraries. My understanding is that most alien libraries are not binary-based (i.e., they are ternary or use other forms of multi-valued-logic (MVL)). ;-)) --charley ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal For Qt 5.8 Platforms And SW Updates
Looks good to me. Note that it's macOS now, not OS X. On Jun 20, 2016, at 5:15 AM, Heikki Halmet <heikki.hal...@qt.io<mailto:heikki.hal...@qt.io>> wrote: Hi, Below is our proposal for target platforms and sw updates in Qt 5.8 release. Some might come after feature freeze or some changes might not happen at all. OpenSUSE 42.1 x86_64 ( - OpenSUSE 13.1 will be dropped after 42.1 is in) • Openssl: 1.0.2h Rhel 6.6 (build's packages) & Rhel 7.2 x86_64 (will appear as a developer build) • Openssl: 1.0.2h • Android ndk r10e • Android sdk 25.1.7 • Python-devel (or python-dev) Ubuntu 16.04 x86_64 ( - Will drop Ubuntu 14.04 and 15.04 when it's in) • Openssl: 1.0.2h • Python-devel (or python-dev) OS X 10.12 beta • Xcode 8 beta & command line tools • Android ndk r10e • Android sdk 25.1.7 OS X 10.11.5 x86_64 • Xcode 7.3.1 & command line tools • Android ndk r10e • Android sdk 25.1.7 OS X 10.10 x86_64 OS X 10.9 x86_64 OSX 10.8 will be dropped! Windows 10 x86 • Openssl: 1.0.2h • Visual Studio 2015 update 2 Windows 10 x86_64 • Openssl: 1.0.2h • Visual Studio 2015 update 2 Windows 7 x86 • Openssl: 1.0.2h • Android ndk r10e • Android sdk 25.1.7 • MinGw 5.3.0 Windows 8.1 x86 • Openssl: 1.0.2h • Visual Studio 2013 update 5 Windows 8.1 x86_64 • Openssl: 1.0.2h (latest) • Visual Studio 2013 update 5 Best regards Heikki Halmet The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland Email: heikki.hal...@qt.io<mailto:heikki.hal...@qt.io> Phone: +358408672112 www.qt.io<http://www.qt.io/> | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt<http://www.facebook.com/qt> ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] VirtualBox 5.1 will migrate to Qt 5
Hi all, Interesting little tidbit I thought I'd share with the community -- looks like VirtualBox is finally upgrading to Qt 5 (5.5.1, to be precise) in the upcoming 5.1 release. Nice to see some major Qt 4 users making the switch! https://forums.virtualbox.org/viewtopic.php?f=15=77998 strings VirtualBox.app/Contents/Frameworks/QtCoreVBox.framework/Versions/5/QtCoreVBox | grep 'Qt 5' Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by Clang 6.0 (clang-600.0.57) (Apple)) -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.8 branching & Feature Freeze
+1. I requested this earlier as well. On Jun 15, 2016, at 1:51 AM, Mike Krus <mike.k...@kdab.com<mailto:mike.k...@kdab.com>> wrote: Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike On 15 Jun 2016, at 08:15, Tuukka Turunen <tuukka.turu...@qt.io<mailto:tuukka.turu...@qt.io>> wrote: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: development@qt-project.org<mailto:development@qt-project.org> Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikki...@qt.io<mailto:jani.heikki...@qt.io> +358 50 4873735 http://qt.io<http://qt.io/> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]<http://qt.io/> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]<http://www.facebook.com/Qt> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png]<http://www.twitter.com/qtproject> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png]<https://www.linkedin.com/company/the-qt-company/> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png]<https://plus.google.com/104580575722059274792> [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png]<https://www.youtube.com/QtStudios> ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.k...@kdab.com<mailto:mike.k...@kdab.com> | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Supported platforms for Qt 5.8
Hi all, Might be a bit premature, but is anyone opposed to dropping OS X 10.9 and iOS 7.x in Qt 5.8? This would follow dropping one OS X and iOS release per Qt release for the past 3 releases, but after that I think we should slow to dropping one release for each release we add (so, once annually or about once every two Qt minor releases). 10.10 and 8.0 were larger releases that began a new "generation" so I think that gives us a better baseline to start with before slowing to an annual upgrade cycle. -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer
+1. I touch Windows as little as possible, yet I'm still aware of Maurice's prominence in the WinRT space. :) On May 12, 2016, at 7:48 AM, Simon Hausmann <simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> wrote: +1. Those mobile Windows platforms keep coming back to Maurice :) Simon From: Development <development-bounces+simon.hausmann=qt...@qt-project.org<mailto:development-bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Andrew Knight <andrew.kni...@intopalo.com<mailto:andrew.kni...@intopalo.com>> Sent: Thursday, May 12, 2016 2:09:44 PM To: development@qt-project.org<mailto:development@qt-project.org> Subject: [Development] Proposing Maurice Kalinowski as the Qt for Windows Runtime (winrt) Platform Maintainer The Windows Runtime port of Qt covers the platform-specific code in Qt, most of it in the "winrt" platform plugin, which enables Qt to run as Windows 8/10 Store Apps, on Windows Phone 8/10, and Windows IoT Core. As the standing Windows Runtime Platform Maintainer, I hereby step down from my post. Over the past year, my contributions to the port have wained, and I simply do not have time to keep up with Windows development. It would be in the best interest of the Qt Project to nominate a new Maintainer. That said, I would like to propose Maurice Kalinowski as the new Windows Runtime Platform Maintainer. He has been active for the entire existence of the port, and has been the primary contributor to it for at least the past six months. He is continuously staying informed of the state of Microsoft's OS technologies, testing Qt on different devices (including the HoloLens!), and making the port better in general. In many ways, he is the acting maintainer already. Cheers, Andrew ___ Development mailing list Development@qt-project.org<mailto: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 -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [5.7-beta] compile error with xcode-6.4
On May 3, 2016, at 10:55 PM, Tim Blechmann <t...@klingt.org<mailto:t...@klingt.org>> wrote: r.h:759:21: error: destination for this 'memmove' call is a pointer to class containing a dynamic class> 'QPixmap'; vtable pointer will be overwritten [-Werror,-Wdynamic-class-memaccess]> memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * sizeof(T)); ~~~ ^ has support for xcode-6.4 been dropped? Not officially. You should always use the latest XCode, no matter what, though. https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with xcode-6.1.1 Indeed, but we're changing policies. Users are expected to use the latest and greatest OS X and XCode, since they're now free for upgrading. I'm not sure whether this applies to 5.7 or not. pricing should not be the only point to consider: requiring latest xcode versions implies requiring the latest sdk. requiring the latest sdk means that: Technically you can copy a newer SDK into an older Xcode version (provided the toolchain supports it). * legacy code using deprecated sdk functions might not compile a certain codebase (depending on the age of your codebase this maybe lead to significant effort) As I've said many times before, the SDK we use to build Qt has no bearing on the SDK you use to build your applications. We can build with the 10.11 SDK, you can build with the 10.8 SDK, and that's completely fine. * compiling with a minimum osx version X of sdk version Y is different than compiling against minimum osx version X of sdk version X. there are subtle differences ...which is exactly why we want to support M+N configuration instead of M*N configurations. and this should not be the case if the code were bug-free ... but we've experienced (toolchain) bugs in the past were the only workaround was to downgrade the osx sdk, which implies downgrading the compiler. end-users won't care if a crash is caused by a bug in application code or in qt or in the apple toolchain. they will blame the application. Rightly so, because in those rare cases it'll always be a bug in your application and not in Qt. See above. And before you say it's more difficult to build Qt on one platform and your applications on another, (a) how often do you actually need to build Qt?, and (b) it is not in our interests to spend the significant effort to test and support 16 (vs 4) different configurations that are unnecessary for 99.9% of users in 99.9% of cases. ... but we had this discussion already in the past :) cheers, tim ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [5.7-beta] compile error with xcode-6.4
On May 3, 2016, at 9:48 AM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: Em terça-feira, 3 de maio de 2016, às 16:33:46 PDT, Tim Blechmann escreveu: compiling the 5.7-beta tarball with xcode-6.4 fails with: r.h:759:21: error: destination for this 'memmove' call is a pointer to class containing a dynamic class> 'QPixmap'; vtable pointer will be overwritten [-Werror,-Wdynamic-class-memaccess]> memmove(abegin, aend, (d->size - itemsToErase - itemsUntouched) * sizeof(T)); ~~~ ^ has support for xcode-6.4 been dropped? Not officially. You should always use the latest XCode, no matter what, though. Not yet but it will be at some point. https://wiki.qt.io/Qt_5.7_Tools_and_Versions still lists OSX 10.9 with xcode-6.1.1 Indeed, but we're changing policies. Users are expected to use the latest and greatest OS X and XCode, since they're now free for upgrading. I'm not sure whether this applies to 5.7 or not. Not 5.7 yet. We haven't started ripping out any of the SDK conditions, and can't until https://codereview.qt-project.org/#/c/151146/ is merged, which is blocked by CI capability limitations at the moment. /me pokes CI team again :) Still, note that this is not an error. It's a warning turned to error because of the -Werror, which means that you used -developer-build. In that case, please send a patch. :-) -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Short QDateTime optimisation
On May 1, 2016, at 7:35 PM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: Hello https://codereview.qt-project.org/157714 I've just pushed one large commit that changes QDateTime to support a "short QDateTime Optimisation". Inspired by the SSO mechanism used in libc++ and similar to what we've done to QVersionNumber, I've made QDateTime not allocate memory for most uses (local time or UTC, within 2 million years of 1970). The optimisation is only for 64-bit systems, since QDateTime simply wasn't wide enough to accommodate the data. 32 bits isn't enough for storing seconds since 1970, much less milliseconds and the extra information we needed. But on 64-bit systems, the pointer is split in two: 8 bits for status flags (including the LSB indicating it's a short QDateTime) and 56 bits for the millisecond count. The commit is quite large. I will spend some time during the next week seeing if I can split it up into bite-sized chunks. Meanwhile, I'd like to ask for help testing this. Since I've dropped the use of QSharedDataPointer, I might have introduced sharing issues. And I'd really like someone to run the unit tests on a big-endian system. Too bad, I thought I could have helped you here but the MIPS board I just bought is LE. :( You could always try Debian mips or ppc in qemu. They have prebuilt images. -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt QuickLook plugin
That would be pretty awesome. It's possible we could ship it inside of Qt Creator? You can put them in either ~/Library/QuickLook or in $BUNDLE_CONTENTS/Library/QuickLook On Apr 30, 2016, at 4:09 PM, Samuel Gaist <samuel.ga...@edeltech.ch<mailto:samuel.ga...@edeltech.ch>> wrote: Hi, I wrote a small QuickLook plugin for OS X that allows to get a preview of Qt's .pro, .pri and .qrc files without opening any editor. Would there be any interest in making it part of the standard OS X installation ? If so, what would be the process to include it ? Cheers Samuel ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMovie no longer supports .mng
If we can simply update libmng and recompile against the new version then we should do so immediately! On Apr 26, 2016, at 4:47 PM, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: On quarta-feira, 27 de abril de 2016 01:39:38 PDT Kevin Kofler wrote: Thiago Macieira wrote: Sorry, just deleting. That makes downloading and maintaining such a library SEP. As a distribution packager, I think that's a good plan. :-) The people on proprietary operating systems seem less happy about that, as evidenced by this thread. But that's not MY problem… ;-) Indeed. If we want the binaries to include the builds, we could include the DLLs for those libraries too. -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMovie no longer supports .mng
The MNG and JPEG2000 plugins are no longer built by default on most platforms because upstream development has stalled and there are known security vulnerabilities. See https://codereview.qt-project.org/#/c/141429/ You can still build them manually if you really want them. Perhaps you could help port the JPEG2000 plugin to https://github.com/uclouvain/openjpeg On Apr 24, 2016, at 2:12 PM, Tom Isaacson <tom.isaac...@navico.com<mailto:tom.isaac...@navico.com>> wrote: I've just upgraded from Qt 5.5.1 to 5.6 using Visual Studio 2013 for 32-bit on Windows 7 and I've found that QMovie fails to load .mng files. Calling QMovie::supportedFormats() just returns "gif". Previously this was working fine. Is this an intentional change? How can I get round it? Thanks, Tom Isaacson ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Possible bug in touch event coordinates in QtWebEngine when using pixelDeviceRatio
Hi Christophe, Without commenting on the content of your patch at the moment, you just need to sign our CLA and push the change to our Gerrit Code Review system, where we can review and then hopefully integrate it. Check out https://wiki.qt.io/Qt_Contribution_Guidelines which will walk you through the complete process. > On Oct 14, 2015, at 4:08 AM, Christophe Chapuis <chris.chap...@gmail.com> > wrote: > > Hello folks, > > I am currently working towards using QtWebEngine for our project (LuneOS), > and I stumbled upon an issue. I am using the experimental devicePixelRatio > property in the QML WebEngineView component, so that our html page is > displayed nicely on mobile device with high DPI. > > However, I remarked that when using devicePixelRatio, only a part of the > webpage was responding to touch events on device. Therefore I suspected an > issue in the conversion of touch event coordinates, and found out that touch > events don't seem to be mapped to web coordinates using dpiScale. > > I did this modification, and now it seems to be working fine: > https://github.com/webOS-ports/qtwebengine/commit/ec0a2f759cd1fb2675ae6f761c6172004cf8af23 > > <https://github.com/webOS-ports/qtwebengine/commit/ec0a2f759cd1fb2675ae6f761c6172004cf8af23> > > Do you agree with this modification ? How could I push that upstream ? > > Regards, > Christophe Chapuis > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTime microsecond support
> On Oct 14, 2015, at 1:22 PM, Dustin Mitchell <dmmit...@gmail.com> wrote: > > Hello, > > Are there plans to support microseconds in the QTime class? I need to parse > timestamps from a text file and it has microsecond resolution. If not, I'd be > willing to implement this feature. > > Dustin > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development +1 -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
c.m...@kdab.com> | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development In general this sounds like a dangerous idea because it carries over all the old API concepts (i.e. (QChar *, size_t) is an extremely broken abstraction). You need to read and truly comprehend https://developer.apple.com/swift/blog/?id=30 before suggesting any changes to string-related APIs for the next major version of Qt, because if anything, THAT is what it should look like. Anything but that is a near-useless wrapper around binary data, not a true string class. -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 build issues on OS X : rpath
> On Sep 28, 2015, at 2:40 PM, Thiago Macieira <thiago.macie...@intel.com> > wrote: > > On Monday 28 September 2015 21:30:33 Massimo Callegari wrote: >>> Can you explain what broke for you? >> >> Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure >> as described here: http://doc.qt.io/qt-5/osx-deployment.html >> With prebuilt Qt 5.5.x clang64, QtFrameworks don't use absolute paths >> anymore, but instead they use @rpath, so calling something like this >> >> install_name_tool -change @rpath/QtCore.framework/Versions/5/QtCore >> @executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore >> myapp.app/Contents/MacOs/myapp >> appears not to be working. (and not needed anymore) > > Does the tool report an error now? Is that what broke? With `install_name_tool -change A B C`, if the dependent shared library install name A does not exist in the Mach-O file C, it's a no-op and the tool returns 0. > >> If Qt is built with -rpath, then an application is in charge to tell Qt how >> to resolve @rpath, thus the need of adding QMAKE_LFLAGS += >> -Wl,-rpath,@executable_path/../Frameworks > > And if you don't do that do your executable, the loading fails? Correct. But you're supposed to add that. > What if we add an extra rpath to Qt libs as @executable_path/../Frameworks? > Would this make loading work? No. The rpath list is embedded in the loading binary A, and specifies where the loading binary A looks for its dependents. If a dependent shared library install name B contains the placeholder '@rpath', that placeholder is substituted for each rpath in loading binary A's rpath list (recursively replacing other placeholders like @executable_path and @loader_path if present) until a match is found. This would only help QtGui find QtCore, for example. The loading binary A still has to find a Qt library in the first place. Please refer to https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html > Jake, Morten: as a stop-gap, is there a configure-time switch to revert to > the > old behaviour? This change seems to be too much for a patch release. It > should > be left for 5.6.0 only. ./configure -no-rpath -- that switch has been there since the beginning of time. I don't remember if that also sets CONFIG+=absolute_library_soname by default. It's also useless, because you virtually never want that (unless you are MacPorts, Debian, etc.), and the changes required on the application side are both less intrusive and easier to deal with anyways, in addition to being the correct workflow on Apple platforms and not breaking code signing. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 build issues on OS X : rpath
> On Sep 28, 2015, at 2:30 PM, Massimo Callegari <massimocalleg...@yahoo.it> > wrote: > > On Monday 28 September 2015 19:09:11 Massimo Callegari wrote: >>> But please guys, when introducing such an important change, you are warmthly >>> invited to mention it in a visible place. > >> It's in the changelog. > >> But I confess the line you're referring to does not indicate that anything >> should break. Qt being build with rpath should enable more, but not remove >> functionality that existed. > >> Can you explain what broke for you? From what I can see, nothing is "broken" for him in the sense he is not limited from doing anything he was previously able to do. > Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure > as described here: > http://doc.qt.io/qt-5/osx-deployment.html > With prebuilt Qt 5.5.x clang64, QtFrameworks don't use absolute paths > anymore, but instead they use @rpath, so calling something like this > > install_name_tool -change @rpath/QtCore.framework/Versions/5/QtCore > @executable_path/../Frameworks/QtCore.framework/Versions/5/QtCore > myapp.app/Contents/MacOs/myapp > appears not to be working. (and not needed anymore) Do not do that. You *want* the @rpath version; using anything but rpath-based install names on Apple platforms is an obscure edge case. If you think you need that, you almost certainly don't. We need to start code-signing our official releases to stop people from doing this. :) > If Qt is built with -rpath, then an application is in charge to tell Qt how > to resolve @rpath, thus the need of adding QMAKE_LFLAGS += > -Wl,-rpath,@executable_path/../Frameworks > > I might got it wrong, but at least this is what I got and how I made it work > back again. > If there is a proper and official way to deploy any Qt5 version in a unique > way, please point me to the right documentation. That is the right way and always has been. Ideally you should use: QMAKE_RPATHDIR = @executable_path/../Frameworks instead of specifying the linker flag manually, but the idea is the same. These are basic aspects of OS X development which Qt doesn't add anything special to, and so the deployment process for Qt 5 frameworks is identical to the deployment process for "any other OS X framework". Basically, make sure your app has @executable_path/../Frameworks in its rpath list, and don't touch the Qt frameworks or the install names that get linked into your binary. If you are ever using install_name_tool to post-process your binary, you are probably doing something wrong, or your dependencies are doing something wrong (for example, Qt < 5.5). I agree we should update the "OS X Deployment" documentation (and possibly link to Apple documentation on dyld and rpaths, and how they work). > Obviously I am talking about deploying a Qt application and the Qt Frameworks > into a DMG package, to be run on a machine that doesn't have Qt installed. > > I am using OSX 10.10.5 and XCode 7, if this can add any value. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development In closing, always use @rpath-based install names, and never use install_name_tool. -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Old platform-specific functions
> On Sep 15, 2015, at 9:07 PM, Sze Howe Koh <szehowe@gmail.com> wrote: > > Hi all, > > There's a list of platform-specific functions from Qt 4: > http://doc.qt.io/qt-5/exportedfunctions.html > > It looks like most of these functions are now gone. The non-existing > functions should be removed from the documentation, but 3 functions > remain in the code base: > > * qt_mac_secure_keyboard() is marked Q_DEAD_CODE_FROM_QT4_MAC (qlineedit.cpp) Maybe introduce a new function in QPA, exposed through QtMac namespace in QtMacExtras? > * qt_mac_set_dock_menu() is marked QT_DEPRECATED, and is slated for > removal in Qt 6 (qmenu.h) Replaced by QMenu::setAsDockMenu (http://doc.qt.io/qt-5/qmenu.html#setAsDockMenu <http://doc.qt.io/qt-5/qmenu.html#setAsDockMenu>) > * qt_set_sequence_auto_mnemonic() is not marked as dead/deprecated in any way. Maybe introduce a new function on QShortcut that takes an enum (Auto, On, Off)? > > Should any of these be left in the documentation? (Note that > qt_set_sequence_auto_mnemonic() is currently documented as a way to > get non-standard behaviour on OS X: > http://doc.qt.io/qt-5/qshortcut.html#details ) > > > Regards, > Sze-Howe > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] allow Qt for iOS to be built as shared libraries
> On Sep 13, 2015, at 4:26 AM, Robin Lobel <div...@divideconcept.net> wrote: > > Hi Jake, > > Do you have any update on this ? > https://codereview.qt-project.org/#/c/123023/ > > I agree It'd be great to have such option starting with iOS 8. > > thanks > Robin Lobel Yes, I'm going to do some more testing on this today. -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.5.0 build issues on OS X : rpath
> On Sep 12, 2015, at 3:43 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > Hello, > > I've noticed another build issue on OS X that became apparent only after > managing a full build and install. > The default now appears to be to create shared libraries with the > install_name containing @rpath, with the alternative being a fully relative > install_name (i.e. only the library name, no path at all) Relative install names are useless, there is virtually no reason you'd want this. > This is different from 5.4.2- where the default was to store the full path in > the install_name (config += absolute_library_soname). > > While the new rpath default is probably fine in Qt's preferred/standard way > for creating stand-alone app-bundles that contain the required Qt frameworks, > it breaks dynamic loading in all other cases, or at the very least when Qt is > built to be installed in a central, shared location (as in MacPorts or Fink). Dynamic library loading on Apple platforms is done in a decoupled manner - on OS X 10.5 and above you should always prefix the install name of a library with @rpath, and it is the loading binary's responsibility to specify (using an rpath list) where it will look for its dependent libraries (rather than the dependent library specifying where its depending binaries will look for it, which is clearly backwards). So, this doesn't break dynamic loading, per se. You would just need to specify the (absolute) install location of Qt as an rpath in your binary, and everything works fine. However, in cases where Qt is intended to not be relocated (your MacPorts/Fink case), it can be more convenient to use an absolute install name, and then your loading binary need not specify that path in its rpath list. Note that the install name of a library gets embedded in your binary when you link to it - that's why no rpath list is needed to load a library that you've linked to, which has an absolute install name. When it has an rpath, that @rpath is a placeholder which is to be replaced with each entry in the calling binary's rpath list until a match is found, and then the library is loaded. Many people seem to be confused by this decoupled aspect of loading and how it's intended to be used (further, many people don't realize rpath is a LIST, not a single entry), so I want to make sure you understand it properly. > For now I'm handling this by setting +absolute_library_soname when > configuring with -no-rpath (and that seems to have the intended result), but > that is of course not quite correct semantically. If you're configuring with -no-rpath, the only valid thing in combination with this case is an absolute install name, so you should not need to specify it additionally. > Supposing I were to submit a patch for this, how would I approach the issue? > Allow something like "-rpath absolute" on OS X, maybe? Or have I been > overlooking another way to add absolute_library_soname through configure? > Either way, I think this is a choice that should be available through > configure, and documented by configure --help; I don't think it's acceptable > to relegate this to a qmake -config call after running configure, like for > LTO (ltcg) builds . > > R. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development "-rpath absolute" is conceptually invalid. What you want is -no-rpath, which uses absolute sonames and doesn't embed any rpaths in any binaries. If that alone is insufficient, there is a bug. I'd expect a Qt framework from a -no-rpath build and other default configure options to have an install name of i.e. /usr/local/Qt-5.6.0/lib/QtCore.framework/Versions/5/QtCore, and no rpath list. Which of these things don't happen when using -no-rpath? -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
