Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Oswald Buddenhagen wrote: but i do. my purpose was to keep the imo (slightly) detrimental change out of qt, and enabling our developer use case to be convenient. i never considered the distro case relevant as such - i demonstrated why it is a non-issue back then, and i did it again in my previous mail. there is simply no problem that needs solving upstream. the fact that fedora successfully ships qt5 packages proves this. The problems are those that Thiago already mentioned: Some programs need adaptations to build on distros because they do not expect the binary names we ship. (That said, this is indeed the lesser evil compared to the problems qtchooser causes.) correct. there is no problem at all if you put the binaries of each qt build into an own directory (a subdirectory of qt's libexec would be probably right, even if it sounds backwards at first) and then alias them from /usr/bin with suffixes. This is, in fact, exactly what we are doing. no, i already said it back then. and your (or maybe rex') argument was I think Rex wrote that. - literally - that you can't do it, because distros won't agree among themselves. so upstream mandating a solution by renaming the binaries itself is necessary. hilarious. as if that would keep anyone from doing what they want anyway. If upstream were to ship suffixed binaries such as qmake-qt5, it would do 2 things: 1. ensure that some distro won't come up with its own naming scheme, e.g. qmake5, q5make, qt5-qmake, qmake_from_Qt_5 or whatever some packager can dream up (if the official binaries are called qmake-qt5 etc., there will be no reason for a distro to use any of the other names), 2. ensure that programs/scripts do not have to handle both renamed and unrenamed binaries, because ALL Qt binaries (from ALL distros and from upstream) should then be using the renamed ones (as there would be no reason to rename it back to qmake, at most to ship both variants for compatibility). Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android Serial Port USB device
On Sun, Jan 18, 2015 at 9:42 PM, Thiago Macieira thiago.macie...@intel.com wrote: I'd like to hear someone from Enterprise Qt here too. My opinion is that we should accept the feature but make it an optional build-time dependency or an optional run-time dependency. That way, Enterprise Qt does not need a licence change and customers who will not install usb-serial-for-android will need to root their devices. I have been looking for alternatives and it seems this one would be acceptable even for Enterprise customers: https://github.com/ksksue/FTDriver Apache 2.0 license, supports FTDI (most common chip, proprietary protocol) and CDC-ACM (most common alternative to FTDI, standard). No external dependency. Lighweight (1 file, ~1,000 lines of code). Problem: it's unmaintained, since author moved to another library: https://github.com/ksksue/PhysicaloidLibrary Physicaloid does a lot more stuff, which we probably don't need. My proposal: adopt FTDriver, include it as part of Qt and implement Qt Serial Port on Android. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Mon, Jan 19, 2015 at 07:30:46PM -0800, Thiago Macieira wrote: On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote: Oswald Buddenhagen wrote: correct. as far as i'm concerned, the purpose of qtchooser is to be a frontend tool which targets developers working with multiple qt versions, regardless whether these versions come from distro packages or own builds. The thing is, we asked for something that fulfills distro's needs. You shot that down and instead got Thiago to implement something different. And now you say yourself that it is not what was asked for. I'm agreeing with Kevin here. [...] So no, don't tell us qtchooser is not meant to solve distros' problems. It's meant exactly for them. but i do. my purpose was to keep the imo (slightly) detrimental change out of qt, and enabling our developer use case to be convenient. i never considered the distro case relevant as such - i demonstrated why it is a non-issue back then, and i did it again in my previous mail. there is simply no problem that needs solving upstream. the fact that fedora successfully ships qt5 packages proves this. build systems which target specific (major) qt versions are simply out of scope. Says who? says me. and in case you already forgot the context: we're talking about the scope of qtchooser at this point. of course one can insist on making qtchooser (used explicitly, not relying on aliasing) the only blessed interface for build systems, but i think it's obvious that this idea is a non-starter. To be clear: Ossi was talking about development files and tools, not about the libraries. And also note he's referring to another self-made problem of not allowing binaries outside of /usr/bin. correct. there is no problem at all if you put the binaries of each qt build into an own directory (a subdirectory of qt's libexec would be probably right, even if it sounds backwards at first) and then alias them from /usr/bin with suffixes. if upstreams of qt-using applications choose to support distro-packaged qt (via having preference lists of suffixed qmakes, for example), that's a perfectly reasonable thing to do. if distros among themselves want to standardize on a pattern to ease this, i'm all for it. it's still not something *we* (qt upstream) need to be concerned with. Now this is really funny. We wanted to do the renaming upstream. You were one of those people who shot it down. correct. Now you are saying we should just do it downstream. no, i already said it back then. and your (or maybe rex') argument was - literally - that you can't do it, because distros won't agree among themselves. so upstream mandating a solution by renaming the binaries itself is necessary. hilarious. as if that would keep anyone from doing what they want anyway. i consider this discussion closed, including for qt6. You don't get to decide that. First of all, you can't tell what the environment for Qt 6 will be. the assumption is obviously that the environment won't change. i don't see how it could, and what i've seen so far doesn't suggest that i'm overly optimistic with that prediction. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
Hi Pasi, We have already forked and currently maintain a separate fork of three.js that is compatible with Qt3dCanvas so including that fork’s code as included 3rd party source code seems like the obvious thing to do. You have my support in doing this. We should not optimise for what makes the life of a package maintainers for a Linux distribution easier. We should optimise for what makes things easier for developers using Qt on all platforms. Give them something that is setup to works out of the box, and is known to work well with our given release. We do this currently with many other 3rd party dependencies. The whole argument is absurd anyway because we’re talking about a Javascript library. One that in the browser case will have a new version downloaded every time you go to a page that uses it. Regards, Andy Nichols From: development-bounces+andy.nichols=theqtcompany@qt-project.org development-bounces+andy.nichols=theqtcompany@qt-project.org on behalf of Keränen Pasi pasi.kera...@theqtcompany.com Sent: Tuesday, January 20, 2015 11:35 AM To: development@qt-project.org Subject: Re: [Development] Adding new third party component three.js to Qt? Hi everyone, So far it seems there has been some positive answers from the community, but the distribution packaging side seems to have most comments against inclusion of the three.js library or at least have comments on HOW it should be included. Sorry, I¹m dropping out of the ³qtchooser² thread, it¹s going way over my understanding of packaging related issues, I¹m a graphics guy and will let the more capable people from our releasing side comment on that. But out of curiosity, can I ask for a show of hands on which distributions currently include the 100% JavaScript three.js based 3D scene graph library in them OR are expecting to do so in the future? Just to see how much impact are we talking about if we decide to include the library to cater for those users that do seem to want a ready ported and verified to work solution within their Qt SDK for their Canvas3D related scene graph needs (perhaps by taking the approach Louai suggested earlier to allow for the eventuality that some distribution wants to include their chosen version of three.js in it). Regards, Pasi On 19/01/15 13:27, Keränen Pasi pasi.kera...@theqtcompany.com wrote: Hi Louai, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] optimizing QComposeInputContext / TableGenerator?
On Tuesday 20 January 2015 04:32:21 Kevin Kofler wrote: Milian Wolff wrote: It can, indeed. But funnily enough it's not going to be much faster, at least in the tests I did. Still, one should probably be doing this anyways. I'll try to dig up my patch for that and sent it to Gerrit. It's a pity that one cannot just convert a const char* to a QChar directly, i.e. without any allocations. One cannot even reuse the same QString buffer to my knowledge... Why not something like this? QChar getQChar(const char *p) snip Did you just create that? If so, then it would need to get published by you as a patch as you are the author. It would be a very cool thing to have in QChar directly, i.e. QChar::fromUtf8 or similar. And we'll need proper unit tests. Also, best would be if we could share the code with the existing UTF8 decoders. Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Thiago Macieira wrote: The FHS does not restrict /opt to admin-installed packages. It simply says add-on application software packages, unlike /usr/local, for which it says for use by the system administrator when installing software locally. Fedora has historically interpreted add-on application software packages to mean packages not delivered by the Fedora Project. As far as I know, this matches Debian's interpretation. In Fedora, the rule has since been relaxed in theory: https://fedoraproject.org/wiki/Packaging:Guidelines#Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt but in practice, no package is currently using either of the 2 approved ways to use /opt, and our packaging committee has also stated that they will require a really good reason to allow a package to install to /opt/fedora, so far nobody has approached them with such a request because there are better solutions. (The Software Collection variant is preapproved and so more likely to get used, but so far we do not have any such Software Collection packaged in the official Fedora repositories either.) In the Qt case, whether we install the Qt binaries to /usr/lib(64)/qt5/bin or /opt/fedora/qt5/bin does not really change anything, except that only the former supports multilib qmake. There can still be only one unsuffixed binary found in the default PATH (the first listed hides all the others). So /opt does not solve any of our issues. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
Hi everyone, So far it seems there has been some positive answers from the community, but the distribution packaging side seems to have most comments against inclusion of the three.js library or at least have comments on HOW it should be included. Sorry, I¹m dropping out of the ³qtchooser² thread, it¹s going way over my understanding of packaging related issues, I¹m a graphics guy and will let the more capable people from our releasing side comment on that. But out of curiosity, can I ask for a show of hands on which distributions currently include the 100% JavaScript three.js based 3D scene graph library in them OR are expecting to do so in the future? Just to see how much impact are we talking about if we decide to include the library to cater for those users that do seem to want a ready ported and verified to work solution within their Qt SDK for their Canvas3D related scene graph needs (perhaps by taking the approach Louai suggested earlier to allow for the eventuality that some distribution wants to include their chosen version of three.js in it). Regards, Pasi On 19/01/15 13:27, Keränen Pasi pasi.kera...@theqtcompany.com wrote: Hi Louai, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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
Re: [Development] CI configuration changes
Hi all! Thanks for all the feedback we received. Based on those and the changes needed we have updated our proposal a bit. Binary packages are currently built with Ubuntu 11.10 because they deploy on different distros quite well. That's something we aim for, so that we don't have to start creating a secondary set of installers for another set of distros. We also need to upgrade the compiler version we use so that QtWebEngine can update to a newer Chromium version. To achieve this we are currently testing creating binaries RHEL 6.6b to see how they deploy, and it's looking promising. Other options we have are openSUSE 13.1 and Ubuntu 14.04 currently, and opinions are welcomed here. We also want to expand our CI coverage to newer platforms and free up some capacity to new platforms not yet in the CI. Thus we came up with these concrete changes to the CI, mainly to be done in the 5.5 time frame: - We will drop 11.10 targets from the CI regarding the 'dev' branch. - Ubuntu 12.04 LTS will be updated to be 14.04 LTS in 'dev' branch. - OSX 10.7 will be dropped in 'dev' branch. - OSX 10.7 will be moved to nightly builds (_state builds) in '5.4.x' branches. - Windows 10 will be added to the CI for 'dev' branch as soon as we have it available. - The *pkg* configs on different platforms are to be moved to nightly builds as well. - A few configurations are moved from Ubuntu to RHEL to correlate to the weight shift. A summary of the configuration for 'dev' branch would look smt like this: linux-arm-gnueabi-g++_Ubuntu_14.04_x64 linux-g++_static_Ubuntu_14.04_x64 linux-android-g++_Ubuntu_14.04_x64 linux-android_armeabi-g++_Ubuntu_14.04_x64 linux-imx6-armv7a_Ubuntu_14.04_x64 linux-qnx-armv7le_Ubuntu_14.04_x64 linux-qnx-x86_Ubuntu_14.04_x64 linux-g++_developer-build_openSUSE_13.1_x64 linux-x86-g++_shadow-build_RHEL_66_x64 (we have to cross-compile x86 on RHEL) linux-g++_no-widgets_RHEL_66_x64 linux-g++_developer-build_qtnamespace_qtlibinfix_RHEL_66_x64 macx-clang_no-framework_OSX_10.8 macx-clang_static_OSX_10.9 macx-clang_developer-build_OSX_10.9 macx-ios-clang_OSX_10.9 macx-clang_developer-build_qtnamespace_OSX_10.10 win32-mingw491_developer-build_qtlibinfix_opengl_Windows_7 win32-msvc2010_developer-build_qtnamespace_Windows_7 win32-msvc2010_opengl_dynamic_Windows_10 (Windows 8.1 until then) win64-msvc2013_developer-build_qtnamespace_Windows_81 wince70embedded-armv4i-msvc2008_Windows_7 winphone-arm-msvc2013_Windows_81 winrt-x64-msvc2013_Windows_81 -Tony -Original Message- From: development-bounces+tony.sarajarvi=theqtcompany.com@qt- project.org [mailto:development- bounces+tony.sarajarvi=theqtcompany@qt-project.org] On Behalf Of Sarajärvi Tony Sent: 4. joulukuuta 2014 14:26 To: Thiago Macieira; development@qt-project.org Subject: Re: [Development] CI configuration changes -Original Message- From: development-bounces+tony.sarajarvi=theqtcompany.com@qt- project.org [mailto:development- bounces+tony.sarajarvi=theqtcompany@qt-project.org] On Behalf Of Thiago Macieira Sent: 3. joulukuuta 2014 19:33 To: development@qt-project.org Subject: Re: [Development] CI configuration changes On Wednesday 03 December 2014 12:46:55 Sarajärvi Tony wrote: Now would be the time to read this through, and comment if you have anything to say about this ;) Hi Tony Hi :) Default configs runs for all submodule builds: linux-arm-gnueabi-g++_Ubuntu_11.10_x86 - to be moved to Ubuntu 14.04 linux-g++_shadow-build_Ubuntu_11.10_x86 - to be moved to Ubuntu 14.04 linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64 - to be removed Looks good, considering there's a namespace+infix left running below. linux-g++_no-widgets_Ubuntu_12.04_x64 linux-android-g++_Ubuntu_12.04_x64 linux-android_armeabi-g++_Ubuntu_12.04_x64 linux-imx6-armv7a_Ubuntu_12.04_x64 linux-qnx-armv7le_Ubuntu_12.04_x64 linux-qnx-x86_Ubuntu_12.04_x64 linux-g++_developer-build_OpenSuSE_13.1_x64 linux-g++_developer-build_qtnamespace_qtlibinfix_RHEL65_x64 macx-clang_developer-build_qtnamespace_OSX_10.7 - to be removed I don't see any other 10.7 remaining. Does this means we'll slowly stop supporting 10.7? It was still in the whole Qt5 build mentioned below, and moved to nightly builds to be as non-blocking. But I reopened the discussion over here... I won't make any drastic changes just yet. Also, I didn't think about this yesterday, but these changes were intended for both 5.4 and dev (future 5.5 ) branches. We could however have them different with the vm-cloner coming (separate templates cloned for every branch). I will not be sorry to see it go, but if it goes I promise you we'll break 10.7 support within one week (the forkfd work failed on 10.7 for unknown reasons and I will submit it with clear conscience as soon as the 10.7 it out of CI).
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tue, Jan 20, 2015 at 01:55:41PM +0100, Kevin Kofler wrote: Some programs need adaptations to build on distros because they do not expect the binary names we ship. but that work has already been done, long ago. even adjusting it to qt6 at some point will be a rather trivial effort (and zero for you if you bothered to upstream build system improvements that make upstream packages work out of the box with packaged qt). you can't do it, because distros won't agree among themselves. so upstream mandating a solution by renaming the binaries itself is necessary. hilarious. as if that would keep anyone from doing what they want anyway. If upstream were to ship suffixed binaries such as qmake-qt5, it would do 2 things: 1. ensure that some distro won't come up with its own naming scheme, e.g. qmake5, q5make, qt5-qmake, qmake_from_Qt_5 or whatever some packager can dream up (if the official binaries are called qmake-qt5 etc., there will be no reason for a distro to use any of the other names), but this is already the case, and has been since qt2. so that ship has sailed. in fact, when rex was pushing for the qmake-qt5 scheme, the debian (?) guys made clear that they'll keep their qmake5 (?) scheme anyway - they must, for compat reasons. so whatever we do is add-on only anyway. and if a *new* distro chooses *yet* another scheme ... well, shoot them. i suggested that the qt project should publish packaging guidelines, so there would be no need to become homocidal. also consider that this problem is a tad bigger than just qt. you really need to define a cross-distro standard anyway. 2. ensure that programs/scripts do not have to handle both renamed and unrenamed binaries, because ALL Qt binaries (from ALL distros and from upstream) should then be using the renamed ones (as there would be no reason to rename it back to qmake, at most to ship both variants for compatibility). but as others pointed out, the name clash of qmake from qt4 and qt5 is advantageous in some porting scenarios. and in case of unified dispatchers like qtchooser (and lots of custom scripts), divergence would be actively counter-productive. given that the problems specific to distros have been adequately solved (even if you find that hacky - which it certainly is in case of badly written build systems), i don't see why we should bother changing anything at this point. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Thiago Macieira wrote: If we get any issues reported to us about Fedora or RHEL's non-renamed binaries, we'll send back to you, with the recommendation that people file bug reports about not using qtchooser. I already do that. Now you're being a little over-dramatic, imo. Users in this case can simply install qtchooser and be done with it. -- Rex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 13:43:53 Kevin Kofler wrote: In the Qt case, whether we install the Qt binaries to /usr/lib(64)/qt5/bin or /opt/fedora/qt5/bin does not really change anything, except that only the former supports multilib qmake. There can still be only one unsuffixed binary found in the default PATH (the first listed hides all the others). So /opt does not solve any of our issues. Don't set PATH to include those. We have to teach users how to find qmake. To be honest, *I* don't like that option. I'm just relaying what was the first proposed solution. -- 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
Re: [Development] Error in compilation while compiling qt5 with qt3d
On Tuesday 20 January 2015 22:39:09 Arjun Das wrote: I am a beginner to QT framework, however i have solved all errors till now. But I am stuck on this one. Compilation of qt5 with qt3d module is failing for me in windows. I have given the following configuration: Is that a qtbase 5.5 (dev) build? -- 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
Re: [Development] C++ QML Interface thoughts
Is there any plans to complite QT QUICK for desktop as QWidgets as well? 2015-01-07 22:11 GMT+08:00 Luke Parry pumpkintea...@gmail.com: Hi Bo, Thank you for your advice. I think one fault lies is my confidence of whether QML is right for the job due to my inexperience. Currently my GUI is QML which is fantastic but I'm still unsure on the best approach I will take for the backend. The motivation for the question is justifying the long term design, such as potentially supporting other language bindings, user defined scripting / implementations.One case study that made me think of using this approach, is from a talk at Dev Days 2012 for Ipo.Plan (https://www.youtube.com/watch?v=kvWeE3kurEQ) I know my reply isn't technical but perhaps someone knows a good resource that may help? Also, would you be happy to send a pdf of your slides from the talk you held Qt Dev Days? Huge Thanks, Luke On 7 January 2015 at 12:17, Bo Thorsen b...@vikingsoft.eu wrote: Den 06-01-2015 kl. 12:47 skrev Luke Parry: I am having issues trying to implement a c++ qml interface/wrapper that supports virtual overrides. Something functionally similar to boost::python would be excellent. This should be generic enough to also support non-QObject classes too so it rules out signals and slots. On first glance, it is fairly trivial to implement a wrapper that calls methods for the pointer, however implementing virtual overrides soon becomes difficult. I want to achieve something like this ( http://pastebin.com/t3k957Hf ) In principle, this would work creating instances in QML but not the other way transforming from a c++ instance. Is this feasible with QML without some compromise? I would like to think I'm missing something subtle or something blatantly obvious. Sounds to me like you're basically recreating the QObject based connection between QML and C++ without using QObject. That seems silly to me. If you're going to do this, accept that you're using QObject based subobjects and then you don't need to do this at all. Anyway, if you insist on doing this, the trick would probably be to make the QObject wrapper object have a pointer to the real non-QObject object. Use aggregation instead of inheritance. 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 ___ 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] Error in compilation while compiling qt5 with qt3d
Hi, I am a beginner to QT framework, however i have solved all errors till now. But I am stuck on this one. Compilation of qt5 with qt3d module is failing for me in windows. I have given the following configuration: configure -debug-and-release -opensource -platform win32-msvc2012 -opengl desktop -nomake examples -nomake tests nmake The following error occurs after a long time of compilation of all other modules.Once it reaches qt3d: c:\build\qt5\qtbase\include\qtcore\../../../../../qt5/qtbase/src/corelib/kernel/qmetatype.h(1648) : error C2338: Type is not registered, please use the Q_DECLARE_METATYPE macro to make it known to Qt's meta-object system c:\build\qt5\qtbase\include\qtcore\../../../../../qt5/qtbase/src/corelib/kernel/qvariant.h(678) : see reference to function template instantiation 'int qMetaTypeIdT(void)' being compiled with [ T=QSurface * ] c:\build\qt5\qtbase\include\qtcore\../../../../../qt5/qtbase/src/corelib/kernel/qvariant.h(677) : while compiling class template member function 'QSurface QtPrivate::QVariantValueHelperT::metaType(const QVariant )' with [ T=QSurface * ] c:\build\qt5\qtbase\include\qtcore\../../../../../qt5/qtbase/src/corelib/kernel/qvariant.h(105) : see reference to function template instantiation 'QSurface QtPrivate::QVariantValueHelperT::metaType(const QVariant )' being compiled with [ T=QSurface * ] c:\build\qt5\qtbase\include\qtcore\../../../../../qt5/qtbase/src/corelib/kernel/qvariant.h(698) : see reference to class template instantiation 'QtPrivate::QVariantValueHelperT' being compiled with [ T=QSurface * ] c:\build\qt5\qtbase\include\qtcore\../../../../../qt5/qtbase/src/corelib/kernel/qvariant.h(817) : see reference to class template instantiation 'QtPrivate::QVariantValueHelperInterfaceT' being compiled with [ T=QSurface * ] c:\build\qt5\qtbase\include\qtcore\../../../../../qt5/qtbase/src/corelib/kernel/qvariant.h(343) : see reference to function template instantiation 'T qvariant_castT(const QVariant )' being compiled with [ T=QSurface * ] C:\qt5\qt3d\src\render\backend\qrenderaspect.cpp(327) : see reference to function template instantiation 'T QVariant::valueQSurface*(void) const' being compiled with [ T=QSurface * ] rendertexture.cpp C:\qt5\qt3d\src\render\backend\rendertexture.cpp(248) : error C2039: 'TextureComparisonOperators' : is not a member of 'QOpenGLTexture' c:\build\qt5\qtbase\include\qtgui\../../../../../qt5/qtbase/src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' C:\qt5\qt3d\src\render\backend\rendertexture.cpp(248) : error C2065: 'TextureComparisonOperators' : undeclared identifier C:\qt5\qt3d\src\render\backend\rendertexture.cpp(249) : error C2039: 'setComparisonFunction' : is not a member of 'QOpenGLTexture' c:\build\qt5\qtbase\include\qtgui\../../../../../qt5/qtbase/src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' C:\qt5\qt3d\src\render\backend\rendertexture.cpp(249) : error C2039: 'ComparisonFunction' : is not a member of 'QOpenGLTexture' c:\build\qt5\qtbase\include\qtgui\../../../../../qt5/qtbase/src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' C:\qt5\qt3d\src\render\backend\rendertexture.cpp(249) : error C2061: syntax error : identifier 'ComparisonFunction' C:\qt5\qt3d\src\render\backend\rendertexture.cpp(250) : error C2039: 'setComparisonMode' : is not a member of 'QOpenGLTexture' c:\build\qt5\qtbase\include\qtgui\../../../../../qt5/qtbase/src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' C:\qt5\qt3d\src\render\backend\rendertexture.cpp(250) : error C2039: 'ComparisonMode' : is not a member of 'QOpenGLTexture' c:\build\qt5\qtbase\include\qtgui\../../../../../qt5/qtbase/src/gui/opengl/qopengltexture.h(51) : see declaration of 'QOpenGLTexture' C:\qt5\qt3d\src\render\backend\rendertexture.cpp(250) : error C2061: syntax error : identifier 'ComparisonMode' platformsurfacefilter.cpp C:\qt5\qt3d\src\render\backend\platformsurfacefilter.cpp(47) : fatal error C1083: Cannot open include file: 'QPlatformSurfaceEvent': No such file or directory Thanks Regards Arjun ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI configuration changes
On Tuesday 20 January 2015 11:38:24 Sarajärvi Tony wrote: - OSX 10.7 will be dropped in 'dev' branch. What's your timeline for this? If you're looking at this for before the Qt 5.5 feature freeze, OS X 10.7 will break and will be effectively unsupported for 5.5 because I won't bother fixing forkfd for it. Given that you said that 10.7 will be on nightly builds for 5.4.x and not for 5.5.x, I'm assuming you meant for this to happen before the feature freeze. -- 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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 11:28:10 Oswald Buddenhagen wrote: So no, don't tell us qtchooser is not meant to solve distros' problems. It's meant exactly for them. but i do. my purpose was to keep the imo (slightly) detrimental change out of qt, and enabling our developer use case to be convenient. i never considered the distro case relevant as such - i demonstrated why it is a non-issue back then, and i did it again in my previous mail. there is simply no problem that needs solving upstream. the fact that fedora successfully ships qt5 packages proves this. I do remember you dismissing the distro's setup as an argument. I also dismissed your dismissal. -- 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
Re: [Development] Error in compilation while compiling qt5 with qt3d
On Tuesday 20 January 2015 22:39:09 Arjun Das wrote: Hi, I am a beginner to QT framework, however i have solved all errors till now. But I am stuck on this one. Compilation of qt5 with qt3d module is failing for me in windows. I have given the following configuration: Be sure to get a recent checkout of the dev branch of qtbase. The metatype declaration of QSurface was added fairly recently. Qt 5.4 is not new enough. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 10:04:51 Thiago Macieira wrote: On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote: given that the problems specific to distros have been adequately solved (even if you find that hacky - which it certainly is in case of badly written build systems), i don't see why we should bother changing anything at this point. In that case, nothing is going to change on our end either, I can live with that (though I don't like the situation, for the reasons explained above), but Thiago will not be happy. I will be happy with the renaming provided that: - it is done by Qt itself, not by distros patching - the documentation is updated to match - Qt Creator adapts Anything short of that is a recipe for incompatibility somewhere. And I agree with Thiago here. Whatever we do should be the documented right thing to do. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tue, Jan 20, 2015 at 06:59:46PM +0100, Kevin Kofler wrote: Oswald Buddenhagen wrote: but that work has already been done, long ago. even adjusting it to qt6 at some point will be a rather trivial effort (and zero for you if you bothered to upstream build system improvements that make upstream packages work out of the box with packaged qt). We do that. The problem is that some upstreams are not cooperative and blame us for breaking Qt instead, most notably the Qt Project itself (see also Thiago's replies), which is upstream for more than just core Qt. if we make it official by providing packaging guidelines, you can stick it right into their faces. also consider that this problem is a tad bigger than just qt. you really need to define a cross-distro standard anyway. The cross-distro standard is normally what upstream ships. The problems only come up when we have to rename it downstream. of course. but unifying the upstreams can be considered a goal in itself, and the intiative for that would have to come from an alliance of downstreams. but whatever - not my problem. but as others pointed out, the name clash of qmake from qt4 and qt5 is advantageous in some porting scenarios. The first step of porting needs to be to change the version of Qt used. This is very commonly the case when porting to a new major version of a library. that's besides the point. the scenario eike pointed out is two-way compatibility once the porting is done. and in case of unified dispatchers like qtchooser (and lots of custom scripts), divergence would be actively counter-productive. How so? You could wrap both the -qt5 and -qt4 names, with wrappers using different config files and/or different environment variables, and so select both a default Qt 5 and a default Qt 4, or just choose on the command line (e.g. qmake-qt5 -qt=debug). Trying to build Qt 5 code with your favorite Qt 4 will not work, the selection ought to be separate. when the qt4 one is named qmake and the qt5 one qmake-qt5, things become rather non-uniform. let's start with qtchooser: it would have to be aliased as qmake-qt5 to be compatible with qt5 upstream (which would be a dead alias for qt4), and it would still have to be aliased as qmake (which might be dead for qt5, depending whether you want to deviate from the qt5 guideline). and scripts are usually a mess, and supporting two binary names would make it even worse. of course these are arguably minor problems (even if some qt devs with particularly strong finger memory will disagree), but then, your problems as packagers are arguably minor, too. therefore, i prefer not to change anything, especially considering the cost of the upstream renaming itself. On Tue, Jan 20, 2015 at 10:04:51AM -0800, Thiago Macieira wrote: On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote: given that the problems specific to distros have been adequately solved (even if you find that hacky - which it certainly is in case of badly written build systems), i don't see why we should bother changing anything at this point. In that case, nothing is going to change on our end either, I can live with that (though I don't like the situation, for the reasons explained above), but Thiago will not be happy. I will be happy with the renaming provided that: kevin meant that you would be unhappy with deprecating qtchooser as far as distros are concerned, and staying with the status quo (i.e., distros provide renamed aliases). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Sigh get a room (on irc fex) guys. Mailbox full already ;-). Andreas Aardal Hanssen Den 20. jan. 2015 kl. 17.08 skrev Thiago Macieira thiago.macie...@intel.com: On Tuesday 20 January 2015 11:28:10 Oswald Buddenhagen wrote: So no, don't tell us qtchooser is not meant to solve distros' problems. It's meant exactly for them. but i do. my purpose was to keep the imo (slightly) detrimental change out of qt, and enabling our developer use case to be convenient. i never considered the distro case relevant as such - i demonstrated why it is a non-issue back then, and i did it again in my previous mail. there is simply no problem that needs solving upstream. the fact that fedora successfully ships qt5 packages proves this. I do remember you dismissing the distro's setup as an argument. I also dismissed your dismissal. -- 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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Oswald Buddenhagen wrote: but that work has already been done, long ago. even adjusting it to qt6 at some point will be a rather trivial effort (and zero for you if you bothered to upstream build system improvements that make upstream packages work out of the box with packaged qt). We do that. The problem is that some upstreams are not cooperative and blame us for breaking Qt instead, most notably the Qt Project itself (see also Thiago's replies), which is upstream for more than just core Qt. but this is already the case, and has been since qt2. so that ship has sailed. in fact, when rex was pushing for the qmake-qt5 scheme, the debian (?) guys made clear that they'll keep their qmake5 (?) scheme anyway - they must, for compat reasons. so whatever we do is add-on only anyway. I'm not aware of any distribution actually using the qmake5 naming scheme for the binary, and a quick Internet search doesn't find anything. Mandriva names its package that way, but the binary contained in it is actually called qmake-qt5. (So that's another distribution using our naming scheme.) Debian is now using qtchooser. (But have they ever shipped a qmake5 to begin with?) And if there is one, they can easily ship a qmake5 → qmake-qt5 symlink. Having the qmake-qt5 name standardized upstream would force them to support it in addition to the legacy one. and if a *new* distro chooses *yet* another scheme ... well, shoot them. i suggested that the qt project should publish packaging guidelines, so there would be no need to become homocidal. The potential for divergence is much less if the package already comes with usable binary names out of the box from upstream. also consider that this problem is a tad bigger than just qt. you really need to define a cross-distro standard anyway. The cross-distro standard is normally what upstream ships. The problems only come up when we have to rename it downstream. but as others pointed out, the name clash of qmake from qt4 and qt5 is advantageous in some porting scenarios. The first step of porting needs to be to change the version of Qt used. This is very commonly the case when porting to a new major version of a library. The advantage of doing it that way is that we do not rely on the user compiling the software to pick the correct version of the library, the software knows what it expects and should pick the right version automatically. and in case of unified dispatchers like qtchooser (and lots of custom scripts), divergence would be actively counter-productive. How so? You could wrap both the -qt5 and -qt4 names, with wrappers using different config files and/or different environment variables, and so select both a default Qt 5 and a default Qt 4, or just choose on the command line (e.g. qmake-qt5 -qt=debug). Trying to build Qt 5 code with your favorite Qt 4 will not work, the selection ought to be separate. given that the problems specific to distros have been adequately solved (even if you find that hacky - which it certainly is in case of badly written build systems), i don't see why we should bother changing anything at this point. In that case, nothing is going to change on our end either, I can live with that (though I don't like the situation, for the reasons explained above), but Thiago will not be happy. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote: given that the problems specific to distros have been adequately solved (even if you find that hacky - which it certainly is in case of badly written build systems), i don't see why we should bother changing anything at this point. In that case, nothing is going to change on our end either, I can live with that (though I don't like the situation, for the reasons explained above), but Thiago will not be happy. I will be happy with the renaming provided that: - it is done by Qt itself, not by distros patching - the documentation is updated to match - Qt Creator adapts Anything short of that is a recipe for incompatibility somewhere. -- 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
Re: [Development] C++ QML Interface thoughts
I don't think so. for example, the GUI of the qt creator, can purely implemented by qml? and, if I will developa GUI like visual studio, can I use qml instead of c++? 2015-01-21 2:33 GMT+08:00 Tomaz Canabrava tcanabr...@kde.org: On Tue, Jan 20, 2015 at 3:32 PM, techabc tech...@gmail.com wrote: Is there any plans to complite QT QUICK for desktop as QWidgets as well? It already is. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI configuration changes
On 20/01/15 21:44, Thiago Macieira thiago.macie...@intel.com wrote: On Tuesday 20 January 2015 19:21:04 Sarajärvi Tony wrote: What's your timeline for this? If I don't get any objections here, I could start the work immediately. Goal is to do it right away, so that we have time to verify the platforms before 5.5 feature freeze. If you're looking at this for before the Qt 5.5 feature freeze, OS X 10.7 will break and will be effectively unsupported for 5.5 because I won't bother fixing forkfd for it. My understanding is that OS X 10.7 is allowed to break in 5.5. Usually we give people a one version notice... So we shouldn't allow it to break in 5.5, but announce that support drops in 5.6. OS X 10.7 has been listed as Tier 2 already for Qt 5.4: http://doc.qt.io/qt-5/supported-platforms.html That said, we should of course carefully consider whether or not it is supported with Qt 5.5. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI configuration changes
On 21 Jan 2015, at 08:19, Turunen Tuukka tuukka.turu...@theqtcompany.com wrote: On 20/01/15 21:44, Thiago Macieira thiago.macie...@intel.com wrote: On Tuesday 20 January 2015 19:21:04 Sarajärvi Tony wrote: What's your timeline for this? If I don't get any objections here, I could start the work immediately. Goal is to do it right away, so that we have time to verify the platforms before 5.5 feature freeze. If you're looking at this for before the Qt 5.5 feature freeze, OS X 10.7 will break and will be effectively unsupported for 5.5 because I won't bother fixing forkfd for it. My understanding is that OS X 10.7 is allowed to break in 5.5. Usually we give people a one version notice... So we shouldn't allow it to break in 5.5, but announce that support drops in 5.6. OS X 10.7 has been listed as Tier 2 already for Qt 5.4: http://doc.qt.io/qt-5/supported-platforms.html That said, we should of course carefully consider whether or not it is supported with Qt 5.5. Maybe we should leave it in CI for the 5.5 timeframe. What would we have to give up to do that? This is an example of why I’d like our CI system to be transformed into a distributed one: it should be possible for anyone to add machines to the pool. Even if some of them are non-binding… e.g. a contributed machine would only be able to do +1/-1 on a patch, as a warning that a certain patch will break a tier 2 platform. There are many such platforms which we aren’t testing. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 15:39:28 Oswald Buddenhagen wrote: [snip] but this is already the case, and has been since qt2. so that ship has sailed. in fact, when rex was pushing for the qmake-qt5 scheme, the debian (?) guys made clear that they'll keep their qmake5 (?) scheme anyway - they must, for compat reasons. No, we didn't. And I actually don't remember anyone saying so. What we *might* have said is keeping qmake tied to qt4, previous to qtchooser. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 19:35:33 Oswald Buddenhagen wrote: On Tue, Jan 20, 2015 at 10:04:51AM -0800, Thiago Macieira wrote: On Tuesday 20 January 2015 18:59:46 Kevin Kofler wrote: given that the problems specific to distros have been adequately solved (even if you find that hacky - which it certainly is in case of badly written build systems), i don't see why we should bother changing anything at this point. In that case, nothing is going to change on our end either, I can live with that (though I don't like the situation, for the reasons explained above), but Thiago will not be happy. I will be happy with the renaming provided that: kevin meant that you would be unhappy with deprecating qtchooser as far as distros are concerned, and staying with the status quo (i.e., distros provide renamed aliases). I would be happy to deprecate its requirement from distros, if my requirements above are met. I like it for my own uses because it allows me to type: qmake -qt5-release instead of ../../bin/qmake or ../../../qtbase/bin/qmake or ~/obj/qt/qt5-release/qtbase/bin But I might replace it with a very simple shell script or function instead, if it's not required by distros. -- 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
Re: [Development] CI configuration changes
-Original Message- From: development-bounces+tony.sarajarvi=theqtcompany.com@qt- project.org [mailto:development- bounces+tony.sarajarvi=theqtcompany@qt-project.org] On Behalf Of Thiago Macieira Sent: 20. tammikuuta 2015 18:21 To: development@qt-project.org Subject: Re: [Development] CI configuration changes On Tuesday 20 January 2015 11:38:24 Sarajärvi Tony wrote: - OSX 10.7 will be dropped in 'dev' branch. What's your timeline for this? If I don't get any objections here, I could start the work immediately. Goal is to do it right away, so that we have time to verify the platforms before 5.5 feature freeze. If you're looking at this for before the Qt 5.5 feature freeze, OS X 10.7 will break and will be effectively unsupported for 5.5 because I won't bother fixing forkfd for it. My understanding is that OS X 10.7 is allowed to break in 5.5. Given that you said that 10.7 will be on nightly builds for 5.4.x and not for 5.5.x, I'm assuming you meant for this to happen before the feature freeze. Yes :) -- 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
Re: [Development] CI configuration changes
On Tuesday 20 January 2015 19:21:04 Sarajärvi Tony wrote: What's your timeline for this? If I don't get any objections here, I could start the work immediately. Goal is to do it right away, so that we have time to verify the platforms before 5.5 feature freeze. If you're looking at this for before the Qt 5.5 feature freeze, OS X 10.7 will break and will be effectively unsupported for 5.5 because I won't bother fixing forkfd for it. My understanding is that OS X 10.7 is allowed to break in 5.5. Usually we give people a one version notice... So we shouldn't allow it to break in 5.5, but announce that support drops in 5.6. Unless we figure out what's wrong. -- 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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 16:01:59 Lisandro Damián Nicanor Pérez Meyer wrote: On Tuesday 20 January 2015 15:39:28 Oswald Buddenhagen wrote: [snip] but this is already the case, and has been since qt2. so that ship has sailed. in fact, when rex was pushing for the qmake-qt5 scheme, the debian (?) guys made clear that they'll keep their qmake5 (?) scheme anyway - they must, for compat reasons. No, we didn't. And I actually don't remember anyone saying so. What we *might* have said is keeping qmake tied to qt4, previous to qtchooser. I think we had a proposal to name qmake qmake5 from upstream -- after my initial idea of calling it qmake3 was shot down[1]. But since we also discarded the idea of renaming, there was no qmake5. [1] $ qmake -v QMake version 3.0 Using Qt version 5.4.1 in /home/thiago/obj/qt/qt5/qtbase/lib -- 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
