[Development] Converting types in Qt
Hi,
I would like to discuss type conversions in Qt. As you may know, Qt has
the ability to convert a known type to another known type. This works for
trivial cases like, for example, int to long, but also for more complex
ones like QByteArray to QString or CustomType to OtherCustomType. Type
conversion in Qt happens mostly without user interaction, for example in
QObject introspection or in QML, but it also can be used through public API:
- QVariant::convert - converts wrapped value to target type
- QVariant::canConvert - fast check if it may be possible to convert
wrapped type to a given target, which is, in my opinion, pretty useless,
unless the real conversion is really heavy
- QMetaType::registerConverter - allows to register a custom converter
function for a user defined type
- QMetaType::convert - perform conversion between two types
I would like to agree on some rules, regarding conversions, as the current
approach is chaotic:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix, everything is
even more complex.
1.1 Patch release or minor release only?
I would say that new conversions may appear only in minor releases,
obvious fixes to existing conversions may appear in patch releases, where by
obvious I mean crash fixes and cases in which the returned value is definitely
bogus.
1.2 Should conversion be perfect or based on a best effort?
Some of the conversion API returns a bool value which is a status
of conversion. What should it return if a conversion is not perfect, for
example int(-1) - uint or QVariantList{string, int, myobject} -
QStringList, should such a case be detected? How do we define the perfect
conversion? Sometimes only ideal, data lossless, conversions should be
allowed, for example QtTestLib is quite strict about it and it allows only
safe conversions. So, for example, int - long but not uint - int, but I
guess for normal use cases such strictness is not necessary.
I think we should base conversions on the best effort and set the
status to false only if a conversion failed completely, that is mainly if a
conversion is unknown or if underlying implementation detected a failure, like
QByteArray - float which uses QByteArray::toFloat(bool *ok)
1.3 Should we try to support a user's type conversions out of the box?
Currently a user needs to manually register a conversion function so
Qt can know it and use it. For certain types we can do much better, because we
can automatically convert some types. For example:
QVectorchar - QLinkedListint
QListFoo - QVectorFoo
QPointerFoo - QObject*
QPointerFoo - void*
QSharedDataPointerFoo - bool
MyQObject* - QPointerMyQObject
Currently we are not doing it for one reason which is behavior
compatibility. What if a user already defined a conversion that we want to add?
It could happen because the conversion was not available in a previous Qt
version. The problem is that the new conversion function may behave in a
different way, especially in edge cases and because of the lack of perfection
mentioned in 1.2. We need to pick only one function. That could be the Qt
version, but then we risk that an existing code will not work anymore. Are we
willing to accept that?
I believe that we should document the problem, and allow the
conversions.
1.4 Should a user be able to add Qt types conversion on his own?
Some conversions are missing, some we consider as not safe. A user,
assuming that he knows what he is doing, could register a conversion; for
example, QString - QChar, how bad is it? Currently, such usage is blocked,
because we are afraid that in the future we may add a conversion that
overrides it.
In my opinion it is not needed; it is a corner case, because we a)
should have the conversion and then it will appear in a future version b) the
conversion is invalid, and it is a sign of a user's broken code.
2. Can we modify an existing conversion?
All modification changes behavior. Of course we assume that changes are
sensible, but still it may break existing code.
2.1 Can we improve a conversion?
For example, QStringList - QString is very tempting, as it works
only if the list is of size 1. The conversion could join all strings instead,
it would be almost backward compatible, as we would alter only conversions
that failed previously.
I believe we should allow that; I can not wait for the bike-shedding
about which character or string we should use to join them.
2.2 How much we can break?
Is missing data in the result of a conversion a reasonable cause to
break behavior? For example QVariant(QColor) -
Re: [Development] About inheriting QBlitterPaintEngine from QGL2PaintEngineEx class
Hi, In my case the inter-operability is guaranteed by the fact the opengl libs I'm using come with a directfb/egl backend, i.e DirectFB surfaces are used as buffers where the GPU can daw. When that is said, it will be a lot of work to base QBlitterPaintEngine on top of QOpenGL2PaintEngineEx, to give something that gives acceptable performance. if it is feasible, I can have a look on it, but my big issue is that the QGL2PaintEngineEx is part of the QtOpenGL Module while the QBlitterPaintEngine is in the QtGui. And I can't find/see any clean way to isolate the QGL2PaintEngineEx declatartion/implementation and move it under QtGUI module. Could you give me some hints? Ah, right. That's not a problem. When we did Qt5 a few of the QGL* classes where replicated inside the QtGui module. To avoid name clashing they where called QOpenGL* instead. So inside src/gui/opengl you will find qopenglpaintengine_p.h which contains the class QOpenGL2PaintEngineEx, so you can use this. I think making QBlitterPaintEngine will lead to a bit of an odd architecture, but if your confident that it will solve your problem, then know yourself out :) Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Development help
hi , I loved Qt library very very much , and I want to be one of its contributors , so I'm asking about any references or texts that could help me to understand Qt library source code (especially QtGui module ) , so that I can then contribute and make changes :-) Thanks , I hope quick reply . ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth LE
Hi guys, and what plans for support of BLE in Windows? PS: E.g. I'm currently can help with Windows (MS BLE stack). I have an some BLE devices.. Best regards, Denis 2014-07-15 11:59 GMT+04:00 Blasche Alexander alexander.blas...@digia.com: Hi, It is being worked on and there will likely be some elements of it in 5.4. Whether it will be a tech preview or a regular release is yet to be determined as that depends on whether it will be done in time. Current target platforms are Linux and Android. I am fairly certain that there won't be any iOS support unless somebody is willing to help out on that front. -- Alex From: development-bounces+alexander.blasche=digia@qt-project.org [development-bounces+alexander.blasche=digia@qt-project.org] on behalf of Karl Beecher [k...@endocode.com] Sent: Friday, July 11, 2014 14:32 To: development@qt-project.org Subject: [Development] Bluetooth LE Hi, I’m currently looking to build a Qt-based app for Android and iOS. One of the requirements for the app is that it connects to a device using Bluetooth LE. I’ve been told that Bluetooth LE support is planned for a future Qt release. Could I ask what the current status of this is for both Android and iOS? Many thanks. Karl ___ 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] Development help
On Saturday 12 July 2014 14:33:28 ahmed taglsir wrote: hi , I loved Qt library very very much , and I want to be one of its contributors , so I'm asking about any references or texts that could help me to understand Qt library source code (especially QtGui module ) , so that I can then contribute and make changes :-) Hi, What you need to know should be found from here: http://qt-project.org/contribute There is no real technical documentation of the internals of Qt other than the source code itself and its few comments. There is however few articles in the wiki: http://qt-project.org/wiki/Category:QtInternals http://qt-project.org/wiki/Category:Developing_Qt::Qt_Internals (actually, these two pages should probably be merged.) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
On Tuesday 15 July 2014 08:55:29 Jędrzej Nowacki wrote:
Hi,
I would like to discuss type conversions in Qt. As you may know, Qt has
the ability to convert a known type to another known type. This works for
trivial cases like, for example, int to long, but also for more complex
ones like QByteArray to QString or CustomType to OtherCustomType.
Type conversion in Qt happens mostly without user interaction, for example
in QObject introspection or in QML, but it also can be used through public
API: - QVariant::convert - converts wrapped value to target type
- QVariant::canConvert - fast check if it may be possible to convert
wrapped type to a given target, which is, in my opinion, pretty useless,
unless the real conversion is really heavy
- QMetaType::registerConverter - allows to register a custom converter
function for a user defined type
- QMetaType::convert - perform conversion between two types
I would like to agree on some rules, regarding conversions, as the
current approach is chaotic:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix, everything
is even more complex.
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth changing
it.
1.1 Patch release or minor release only? [...]
Minor release only of course.
Path release is only for regressions and critical fixes. New conversions is a
feature.
1.2 Should conversion be perfect or based on a best effort?
Some of the conversion API returns a bool value which is a status
of conversion. What should it return if a conversion is not perfect, for
example int(-1) - uint or QVariantList{string, int, myobject} -
QStringList, should such a case be detected? How do we define the perfect
conversion? Sometimes only ideal, data lossless, conversions should be
allowed, for example QtTestLib is quite strict about it and it allows only
safe conversions. So, for example, int - long but not uint - int, but
I guess for normal use cases such strictness is not necessary.
I think we should base conversions on the best effort and set the
status to false only if a conversion failed completely, that is mainly if a
conversion is unknown or if underlying implementation detected a failure,
like QByteArray - float which uses QByteArray::toFloat(bool *ok)
You have to think of the use cases for QVariant::convert.
Most common are things like QVariant::toString and QVariant::toInt and such.
You usually have a function that expect a string or an int, and you do best
effort to get that from the QVariant to ease programmer life in the wonderful
wold of dynamic typing :-)
It is true that it would be good to have a bool *ok in case the conversion
failed totally.
1.3 Should we try to support a user's type conversions out of the box?
Currently a user needs to manually register a conversion function
so Qt can know it and use it. For certain types we can do much better,
because we can automatically convert some types. For example:
QVectorchar - QLinkedListint
QListFoo - QVectorFoo
QPointerFoo - QObject*
QPointerFoo - void*
QSharedDataPointerFoo - bool
MyQObject* - QPointerMyQObject
Currently we are not doing it for one reason which is behavior
compatibility. What if a user already defined a conversion that we want to
add? It could happen because the conversion was not available in a previous
Qt version. The problem is that the new conversion function may behave in a
different way, especially in edge cases and because of the lack of
perfection mentioned in 1.2. We need to pick only one function. That could
be the Qt version, but then we risk that an existing code will not work
anymore. Are we willing to accept that?
I believe that we should document the problem, and allow the
conversions.
I think we could try to automatically do conversion when we know how to do it.
And if there is an user defined conversion, it overrides the automatic one.
1.4 Should a user be able to add Qt types conversion on his own?
Some conversions are missing, some we consider as not safe. A user,
assuming that he knows what he is doing, could register a conversion; for
example, QString - QChar, how bad is it? Currently, such usage is
blocked, because we are afraid that in the future we may add a conversion
that overrides it.
In my opinion it is not needed; it is a corner case, because we a)
should have the conversion and then it will appear in a future version b)
the conversion is invalid, and it is a sign of a user's broken code.
I'd say no.
2. Can we modify an existing conversion?
All modification changes
Re: [Development] Bluetooth LE
Hi Denis, -Original Message- From: Denis Shienkov [mailto:denis.shien...@gmail.com] and what plans for support of BLE in Windows? PS: E.g. I'm currently can help with Windows (MS BLE stack). I have an some BLE devices.. It' pretty much the same situation as on iOS. It depends on the kind of support from other developers. The only minor? difference between the two platforms is that Windows could potentially support the entire QtBluetooth stack (classic and low energy) whereas iOS can only ever support BLE. If you have the time to help out on iOS or Windows (or even in general) please let me know and I happily sort the details out with you. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth LE
Alex, is that Windows could potentially support the entire QtBluetooth stack (classic and low energy) Yes. But Windows also has restrictions for BLE (I mean, the MS BT stack has restrictions): 1. BLE is supported from Windows 8 and newest 2. BLE in Windows do not support discovery (has no public Win32 API for it). If you have the time to help out on iOS or Windows (or even in general) please let me know and I happily sort the details out with you. Yes. I have a few free time to help with Windows (Win32) (classic low energy). BR, Denis 2014-07-15 14:05 GMT+04:00 Blasche Alexander alexander.blas...@digia.com: Hi Denis, -Original Message- From: Denis Shienkov [mailto:denis.shien...@gmail.com] and what plans for support of BLE in Windows? PS: E.g. I'm currently can help with Windows (MS BLE stack). I have an some BLE devices.. It' pretty much the same situation as on iOS. It depends on the kind of support from other developers. The only minor? difference between the two platforms is that Windows could potentially support the entire QtBluetooth stack (classic and low energy) whereas iOS can only ever support BLE. If you have the time to help out on iOS or Windows (or even in general) please let me know and I happily sort the details out with you. -- Alex ___ 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] Converting types in Qt
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix, everything
is even more complex.
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth changing
it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an nice to have
base?
Do we really think that's ok to disallow changing some int foo() { return
42; } to some int bar() { return 42; } that's easy to discover at build time,
but it's fine to change int foo() { return 42; } to int foo() { return -1; } ?
so Qt can know it and use it. For certain types we can do much better,
because we can automatically convert some types. For example:
QVectorchar - QLinkedListint
QVectorchar v; v.append(130);
QLinkedListint l = /*someSensibleAutomatedConversion*/(v);
assert(l.first() == 130) ? Depends ?
A conversion may be arbitrary. For example, most of the conversions
to QString. Should bool(false) - QString return False, 0, false?
What about precision of, for example, double - QString ?
We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to avoid to do it automatically, prefer to make it explicit.
Already now it's far too easy to make mistakes based on the nice
and easy QByteArray - QVariant - QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth LE
Hi Denis/Alex, I can't promise much development time, but I'd be happy to participate in reviews/testing for the Windows backends. The WinRT/WinPhone port might also benefit from these and so we should try to share code there if possible. -Andrew From: Denis Shienkovmailto:denis.shien...@gmail.com Sent: 15/07/2014 13:23 To: Blasche Alexandermailto:alexander.blas...@digia.com; development@qt-project.orgmailto:development@qt-project.org Subject: Re: [Development] Bluetooth LE Alex, is that Windows could potentially support the entire QtBluetooth stack (classic and low energy) Yes. But Windows also has restrictions for BLE (I mean, the MS BT stack has restrictions): 1. BLE is supported from Windows 8 and newest 2. BLE in Windows do not support discovery (has no public Win32 API for it). If you have the time to help out on iOS or Windows (or even in general) please let me know and I happily sort the details out with you. Yes. I have a few free time to help with Windows (Win32) (classic low energy). BR, Denis 2014-07-15 14:05 GMT+04:00 Blasche Alexander alexander.blas...@digia.commailto:alexander.blas...@digia.com: Hi Denis, -Original Message- From: Denis Shienkov [mailto:denis.shien...@gmail.commailto:denis.shien...@gmail.com] and what plans for support of BLE in Windows? PS: E.g. I'm currently can help with Windows (MS BLE stack). I have an some BLE devices.. It' pretty much the same situation as on iOS. It depends on the kind of support from other developers. The only minor? difference between the two platforms is that Windows could potentially support the entire QtBluetooth stack (classic and low energy) whereas iOS can only ever support BLE. If you have the time to help out on iOS or Windows (or even in general) please let me know and I happily sort the details out with you. -- Alex ___ Development mailing list Development@qt-project.orgmailto: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] Bluetooth LE
Hi Andrew, Happy to add you. I just setup qtconnectivity.git wip/win branch up for this purpose. -- Alex From: Knight Andrew Sent: Tuesday, July 15, 2014 14:38 To: Denis Shienkov; Blasche Alexander; development@qt-project.org Subject: RE: [Development] Bluetooth LE Hi Denis/Alex, I can't promise much development time, but I'd be happy to participate in reviews/testing for the Windows backends. The WinRT/WinPhone port might also benefit from these and so we should try to share code there if possible. -Andrew From: Denis Shienkovmailto:denis.shien...@gmail.com Sent: 15/07/2014 13:23 To: Blasche Alexandermailto:alexander.blas...@digia.com; development@qt-project.orgmailto:development@qt-project.org Subject: Re: [Development] Bluetooth LE Alex, is that Windows could potentially support the entire QtBluetooth stack (classic and low energy) Yes. But Windows also has restrictions for BLE (I mean, the MS BT stack has restrictions): 1. BLE is supported from Windows 8 and newest 2. BLE in Windows do not support discovery (has no public Win32 API for it). If you have the time to help out on iOS or Windows (or even in general) please let me know and I happily sort the details out with you. Yes. I have a few free time to help with Windows (Win32) (classic low energy). BR, Denis 2014-07-15 14:05 GMT+04:00 Blasche Alexander alexander.blas...@digia.commailto:alexander.blas...@digia.com: Hi Denis, -Original Message- From: Denis Shienkov [mailto:denis.shien...@gmail.commailto:denis.shien...@gmail.com] and what plans for support of BLE in Windows? PS: E.g. I'm currently can help with Windows (MS BLE stack). I have an some BLE devices.. It' pretty much the same situation as on iOS. It depends on the kind of support from other developers. The only minor? difference between the two platforms is that Windows could potentially support the entire QtBluetooth stack (classic and low energy) whereas iOS can only ever support BLE. If you have the time to help out on iOS or Windows (or even in general) please let me know and I happily sort the details out with you. -- Alex ___ Development mailing list Development@qt-project.orgmailto: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] Precompiled headers enabled for most modules (if you enabled precompiled headers)
On Tuesday 27 May 2014 14:21:40 Thiago Macieira wrote: Hello This is your friendly note that all Qt modules that don't have C or assembly code are now using precompiled headers. I've tested this solution for a couple of months with GCC on Linux, Clang on Linux, Clang on Mac and the Intel compiler on Linux. As it turns out, I didn't test it in all modules with Visual Studio. I've just fixed one problem in QtScript and we have one left in qtlocation for QtLocation which makes no sense to me and I can't reproduce. This change does *not* enable precompiled headers by default. You still need to pass -pch to the configure script or to configure.exe in order to get them. It simply creates a precompiled header for the modules that didn't previously define one, unless explicitly overridden. When you should override: - when you have C, Objective C (not Objective C++) or assembly sources [done for all current modules] - when you need to do ugl^H^H^Hclever hacks with preprocessing that not even NO_PCH_SOURCES can help [no known instance] - when you have a better precompilation source than the default Hey Thiago, I have an issue with PCH's. I do not pass the -pch flag to configure, yet still I regularly get build errors like the following, even on clean builds: In file included from command-line:0:0: /usr/include/stdc-predef.h:59:1: error: one or more PCH files were found, but they were invalid #endif ^ /usr/include/stdc-predef.h:59:1: error: use -Winvalid-pch for more information /usr/include/stdc-predef.h:59:1: fatal error: .pch/Qt5Quick: No such file or directory compilation terminated. The above is from QtDeclarative (dev branch), but I've also seen it in QtBase and QtXMLPatterns, even while doing make install after a successful make... It seems to be related to the number of jobs running, a make -j1 seems to work most of the time, yet a make -j40 on a compile cluster fails most of the time. It is pretty random, as it fails on different files across rebuilds. I guess, if I'd run a make in a for loop until if finished successfully it might work eventually but of course that is not an option. I'm now trying to explicitly disable pch with -no-pch in QtBase and see whether that makes a difference. Considering that I did not pass -pch before, I wonder if it makes any difference... Did anyone ever see such an issue? What am I doing wrong? I'm building Qt5 dev branches with gcc 4.9.0 over icecream on an up2date ArchLinux system. Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Precompiled headers enabled for most modules (if you enabled precompiled headers)
On Tuesday 15 July 2014 15:32:10 Milian Wolff wrote: On Tuesday 27 May 2014 14:21:40 Thiago Macieira wrote: Hello This is your friendly note that all Qt modules that don't have C or assembly code are now using precompiled headers. I've tested this solution for a couple of months with GCC on Linux, Clang on Linux, Clang on Mac and the Intel compiler on Linux. As it turns out, I didn't test it in all modules with Visual Studio. I've just fixed one problem in QtScript and we have one left in qtlocation for QtLocation which makes no sense to me and I can't reproduce. This change does *not* enable precompiled headers by default. You still need to pass -pch to the configure script or to configure.exe in order to get them. It simply creates a precompiled header for the modules that didn't previously define one, unless explicitly overridden. When you should override: - when you have C, Objective C (not Objective C++) or assembly sources [done for all current modules] - when you need to do ugl^H^H^Hclever hacks with preprocessing that not even NO_PCH_SOURCES can help [no known instance] - when you have a better precompilation source than the default Hey Thiago, I have an issue with PCH's. I do not pass the -pch flag to configure, yet still I regularly get build errors like the following, even on clean builds: In file included from command-line:0:0: /usr/include/stdc-predef.h:59:1: error: one or more PCH files were found, but they were invalid #endif ^ /usr/include/stdc-predef.h:59:1: error: use -Winvalid-pch for more information /usr/include/stdc-predef.h:59:1: fatal error: .pch/Qt5Quick: No such file or directory compilation terminated. The above is from QtDeclarative (dev branch), but I've also seen it in QtBase and QtXMLPatterns, even while doing make install after a successful make... It seems to be related to the number of jobs running, a make -j1 seems to work most of the time, yet a make -j40 on a compile cluster fails most of the time. It is pretty random, as it fails on different files across rebuilds. I guess, if I'd run a make in a for loop until if finished successfully it might work eventually but of course that is not an option. I'm now trying to explicitly disable pch with -no-pch in QtBase and see whether that makes a difference. Considering that I did not pass -pch before, I wonder if it makes any difference... Did anyone ever see such an issue? What am I doing wrong? I'm building Qt5 dev branches with gcc 4.9.0 over icecream on an up2date ArchLinux system. FTR: Passing -no-pch explicitly seems to have helped indeed. Which is odd, no? Did the default change and are PCH now enabled by default? Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Precompiled headers enabled for most modules (if you enabled precompiled headers)
On Tuesday 15 July 2014 15:32:10 Milian Wolff wrote: It seems to be related to the number of jobs running, a make -j1 seems to work most of the time, yet a make -j40 on a compile cluster fails most of the time. Theories: 1) one of the compilation processes started before the PCH-creation finished a) because qmake generated the wrong rules; b) because you have a bug in make 2) the rules are right, but the PCH creation is failing due to bug in the toolchain Please check all three possibilities. The easiest is to check the rules. Let me take the example of QtCore and qglobal.o: .obj/qglobal.o: /home/thiago/src/qt/qt5/qtbase/src/corelib/global/qglobal.cpp ../../include/QtCore/qstring.h \ [...] .pch/Qt5Core.gch/c++ $(CXX) -c -include .pch/Qt5Core $(CXXFLAGS) $(INCPATH) -o .obj/qglobal.o /home/thiago/src/qt/qt5/qtbase/src/corelib/global/qglobal.cpp So there *is* a rule that makes qglobal.o depend on the PCH output for me. It doesn't look like a qmake bug to me. To check if the bug is in make, you have to watch your system. When it enters a new build, does it halt for a second or two trying to precompile the headers, and *then* launch the other 40 processes? If so, it's not a make bug. If the above two prove correct, by process elimination we arrive at a bug in the toolchain. You maintioned that this happens when you're using Icecream, only sometimes, and when using a high -j. I have two theories for this: 1) creation got submitted to another machine and the transfer of the file back failed 2) creation succeeded, but icecc did not submit the PCH file to the remote machine to compile. In fact, #2 and remote building is usually at odds. Teambuilder had never fixed that. The scripts had rules to remove the PCH including so remote building would work. -- 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] Precompiled headers enabled for most modules (if you enabled precompiled headers)
On Tuesday 15 July 2014 08:15:55 Thiago Macieira wrote: On Tuesday 15 July 2014 15:32:10 Milian Wolff wrote: It seems to be related to the number of jobs running, a make -j1 seems to work most of the time, yet a make -j40 on a compile cluster fails most of the time. Theories: 1) one of the compilation processes started before the PCH-creation finished a) because qmake generated the wrong rules; b) because you have a bug in make 2) the rules are right, but the PCH creation is failing due to bug in the toolchain OK, but why are PCH's enabled by default? The output of configure --help does not indicate that. I.e. why is -include .pch/Qt5Something even passed to GCC in the first place by default? Please check all three possibilities. The easiest is to check the rules. Let me take the example of QtCore and qglobal.o: .obj/qglobal.o: /home/thiago/src/qt/qt5/qtbase/src/corelib/global/qglobal.cpp ../../include/QtCore/qstring.h \ [...] .pch/Qt5Core.gch/c++ $(CXX) -c -include .pch/Qt5Core $(CXXFLAGS) $(INCPATH) -o .obj/qglobal.o /home/thiago/src/qt/qt5/qtbase/src/corelib/global/qglobal.cpp So there *is* a rule that makes qglobal.o depend on the PCH output for me. It doesn't look like a qmake bug to me. To check if the bug is in make, you have to watch your system. When it enters a new build, does it halt for a second or two trying to precompile the headers, and *then* launch the other 40 processes? If so, it's not a make bug. If the above two prove correct, by process elimination we arrive at a bug in the toolchain. You maintioned that this happens when you're using Icecream, only sometimes, and when using a high -j. I have two theories for this: 1) creation got submitted to another machine and the transfer of the file back failed 2) creation succeeded, but icecc did not submit the PCH file to the remote machine to compile. In fact, #2 and remote building is usually at odds. Teambuilder had never fixed that. The scripts had rules to remove the PCH including so remote building would work. That does sound like a valid assumption on why it all fails on my end. I'll just stick to configure with -no-pch. Thanks -- 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] Precompiled headers enabled for most modules (if you enabled precompiled headers)
On Tuesday 15 July 2014 17:39:16 Milian Wolff wrote: OK, but why are PCH's enabled by default? The output of configure --help does not indicate that. I.e. why is -include .pch/Qt5Something even passed to GCC in the first place by default? The output is wrong. It's been auto since the beginning of history. -- 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] Converting types in Qt
On Tuesday 15 July 2014 10:38:52 Poenitz Andre wrote:
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a
behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix,
everything
is even more complex.
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an nice to have
base?
Do we really think that's ok to disallow changing some int foo() { return
42; } to some int bar() { return 42; } that's easy to discover at build
time, but it's fine to change int foo() { return 42; } to int foo() {
return -1; } ?
It's always a dilemma. We have to look at how likely we are to break
applications and I don't think adding a conversion is likely to cause
breakages.
so Qt can know it and use it. For certain types we can do much better,
because we can automatically convert some types. For example:
QVectorchar - QLinkedListint
QVectorchar v; v.append(130);
QLinkedListint l = /*someSensibleAutomatedConversion*/(v);
assert(l.first() == 130) ? Depends ?
QVariant(char(130)).toInt() already exists. You may argue that it is not
sensible but that's another issue.
I guess the example is more between QVectorT1 - QLinkedListT2 when there
exist a conversion from T1 to T2
A conversion may be arbitrary. For example, most of the
conversions
to QString. Should bool(false) - QString return False, 0,
false?
What about precision of, for example, double - QString ?
We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to avoid to do it automatically, prefer to make it explicit.
Already now it's far too easy to make mistakes based on the nice
and easy QByteArray - QVariant - QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
What's the mistake here? Wrong encoding? Bad performances?
When one use QVariant, it is because we want to enjoy dynamic typing and nice
conversions.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Nominating Milian Wolff as approver
Hi all, it’s my pleasure to nominate Milian Wolff as approver. He’s a great guy, works for KDAB and has done interesting work on profiling, improves KDevelop amongst other things and has been active with all things web it seems. He’s started and is maintaining the qtwebchannel repository which is getting more and more attention lately. He’s great to work with and based in Berlin. I think he makes a great addition to the list of Qt approvers. His submissions: https://codereview.qt-project.org/#/q/owner:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z Cheers, Frederik ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Remove OSX 10.6 Build?
On 2014-07-15, at 04:53 PM, Adam Light acli...@gmail.com wrote: Getting back to a thread from a few months ago On Mon, Mar 24, 2014 at 3:57 PM, Jake Petroules jake.petrou...@petroules.com wrote: Pretty much the only thing you lose with ARC is that it's 64-bit only and thus using it means waving goodbye to 32-bit Qt on OS X completely. I don't know if this is a problem for anyone. There's also a selection of classes to which zeroing weak references cannot be made at all, and this list has changed from release to release. Have any final decisions been made on this matter? Our Qt based application, which we hope to release next year, must be able to be *both* 32 and 64 bit on Macintosh. This isn't due to hardware constraints but because our application allows users to use 3rd party libraries for which they often don't have the source code. Since the version of the application we are currently shipping is 32-bit only on Macintosh, none of these 3rd party libraries will function if we provide only a 64-bit version of our application. This will make it much more difficult for our users to upgrade when we release the new version, and that's something we'd like to avoid. We'd like to plan to use Qt 5 for our application (instead of 4.8) but if it soon won't be possible to build a 32-bit version we might have to stick with Qt 4.8 (of course, that has problems of its own). For what it's worth, we're OK dropping support for OSX 10.6, just not the ability to build a 32-bit application. Thanks Adam ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development As I've mentioned before, I don't think dropping 32-bit support would gain much for Qt. In fact it's more work to drop it than simply keep it around. For qtbase (and other modules probably have less): it's especially not worth it for only 96 Objective-C++ source files (and one Objective-C) comprising barely 29k lines of code (compared to around 5300 files / 2m LOC for C/C++) - and remember, all but one of these files is Objective-C++, not pure Objective-C, so a good chunk of that 29k figure will just be C++, bringing the amount even lower: find . -name '*.m' -o -name '*.mm' ./config.tests/mac/corewlan/corewlantest.mm ./examples/widgets/mac/qmaccocoaviewcontainer/main.mm ./examples/widgets/mac/qmacnativewidget/main.mm ./src/corelib/io/qfilesystemwatcher_fsevents.mm ./src/corelib/io/qstandardpaths_ios.mm ./src/corelib/io/qurl_mac.mm ./src/corelib/kernel/qcore_mac_objc.mm ./src/corelib/tools/qbytearray_mac.mm ./src/corelib/tools/qlocale_mac.mm ./src/corelib/tools/qstring_mac.mm ./src/corelib/tools/qtimezoneprivate_mac.mm ./src/gui/accessible/qaccessiblecache_mac.mm ./src/network/access/qnetworkreplynsurlconnectionimpl.mm ./src/platformsupport/cglconvenience/cglconvenience.mm ./src/platformsupport/clipboard/qmacmime.mm ./src/platformsupport/eventdispatchers/qeventdispatcher_cf.mm ./src/platformsupport/fontdatabases/mac/qcoretextfontdatabase.mm ./src/platformsupport/fontdatabases/mac/qfontengine_coretext.mm ./src/plugins/bearer/corewlan/qcorewlanengine.mm ./src/plugins/bearer/corewlan/qcorewlanengine_10_6.mm ./src/plugins/platforms/cocoa/main.mm ./src/plugins/platforms/cocoa/qcocoaaccessibility.mm ./src/plugins/platforms/cocoa/qcocoaaccessibilityelement.mm ./src/plugins/platforms/cocoa/qcocoaapplication.mm ./src/plugins/platforms/cocoa/qcocoaapplicationdelegate.mm ./src/plugins/platforms/cocoa/qcocoaautoreleasepool.mm ./src/plugins/platforms/cocoa/qcocoabackingstore.mm ./src/plugins/platforms/cocoa/qcocoaclipboard.mm ./src/plugins/platforms/cocoa/qcocoacolordialoghelper.mm ./src/plugins/platforms/cocoa/qcocoacursor.mm ./src/plugins/platforms/cocoa/qcocoadrag.mm ./src/plugins/platforms/cocoa/qcocoaeventdispatcher.mm ./src/plugins/platforms/cocoa/qcocoafiledialoghelper.mm ./src/plugins/platforms/cocoa/qcocoafontdialoghelper.mm ./src/plugins/platforms/cocoa/qcocoaglcontext.mm ./src/plugins/platforms/cocoa/qcocoahelpers.mm ./src/plugins/platforms/cocoa/qcocoainputcontext.mm ./src/plugins/platforms/cocoa/qcocoaintegration.mm ./src/plugins/platforms/cocoa/qcocoaintrospection.mm ./src/plugins/platforms/cocoa/qcocoakeymapper.mm ./src/plugins/platforms/cocoa/qcocoamenu.mm ./src/plugins/platforms/cocoa/qcocoamenubar.mm ./src/plugins/platforms/cocoa/qcocoamenuitem.mm ./src/plugins/platforms/cocoa/qcocoamenuloader.mm ./src/plugins/platforms/cocoa/qcocoamimetypes.mm ./src/plugins/platforms/cocoa/qcocoanativeinterface.mm ./src/plugins/platforms/cocoa/qcocoaprintdevice.mm ./src/plugins/platforms/cocoa/qcocoaprintersupport.mm ./src/plugins/platforms/cocoa/qcocoaservices.mm ./src/plugins/platforms/cocoa/qcocoasystemsettings.mm ./src/plugins/platforms/cocoa/qcocoasystemtrayicon.mm ./src/plugins/platforms/cocoa/qcocoatheme.mm ./src/plugins/platforms/cocoa/qcocoawindow.mm ./src/plugins/platforms/cocoa/qmacclipboard.mm
[Development] Fwd: Nominating Milian Wolff as approver
-- Forwarded message -- From: Richard Moore r...@kde.org Date: 15 July 2014 22:55 Subject: Re: [Development] Nominating Milian Wolff as approver To: Gladhorn Frederik frederik.gladh...@digia.com He isn't already? +1 Rich. On 15 July 2014 21:08, Gladhorn Frederik frederik.gladh...@digia.com wrote: Hi all, it's my pleasure to nominate Milian Wolff as approver. He's a great guy, works for KDAB and has done interesting work on profiling, improves KDevelop amongst other things and has been active with all things web it seems. He's started and is maintaining the qtwebchannel repository which is getting more and more attention lately. He's great to work with and based in Berlin. I think he makes a great addition to the list of Qt approvers. His submissions: https://codereview.qt-project.org/#/q/owner:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z Cheers, Frederik ___ 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] Qt5 QML TouchPoint pressure always return -1, but QWidget tabletEvent works well
Hi Qt developers, In Qt5.3.1 qtdeclarative/examples/quick/touchinteraction, There is MultiPointTouchArea and TouchPoint example, but TouchPoint touch1.pressure, it always print out -1 Why?! because Qt5 removed X11 and Xi relatived part? https://github.com/krre/AprilBrush-Desktop/blob/master/cpp/wacom/wacom_unix.cpp#L31 In Qt5.3.1 qtbase/examples/widgets/widgets/tablet, QTabletEvent event-pressure() print out the value in the [0.0, 1.0] range. So how to get the correct pressure value from MultiPointTouchArea and TouchPoint in QML? please someone give me some advice, thanks a lot! -- Regards Leslie Zhai xiang.z...@i-soft.com.cn a KDE developer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
