Re: [Development] QML and JavaScript extensions
On 16.11.13 00:26, Alan Alpert 4163654...@gmail.com wrote: On Fri, Nov 15, 2013 at 2:17 PM, Kevin Krammer kevin.kram...@kdab.com wrote: [...] Quoting your latest post: I can understand that you'd like to have the same script engine evaluate both types of script, but since the decision was to make an optimized version for QML, you can either try to shoehorn your code into that limited engine or use what you already have. The engine that runs QML implements the ECMAScript standard and it must have all the necessary tools for extending JS with C++. Otherwise, it could be used to implement neither QML, the extensions QML already has added to ECMAScript nor ECMAScript itself. The lack of a public API to these features is the only reason I need to do the shoehorning every time the engine is changed. True. If QJSEngine is defined to be fully ECMA compatible then that is of course possible. I was primarily working under the impression that while QJSEngine was intended to replace QtScriptEngine, the need for V4 made that less likely. V4VM is intended to be a fully ECMAScript compatible JS engine (I think it's there already even, for the first release!). The special needs of QML are either in performance profile, or only in the QML parts of QML/JS. AFAIK, the plan (no more long-term than when we were using V8 ;) ) is still for QJSEngine to expose a full ECMAScript compliant JS engine for application scripting, similar to QtScript but QML integrated and avoiding running a second JS engine. Yes, v4vm in QtQml/5.2 is fully compliant with EcmaScript 5.1. It¹s actually much more standards compliant than QtScript is (QtScript does e.g. Not support strict mode). And yes, the plan is to add APIs to the QJS* set of classes to make it a full replacement for Qt Script in the future. We¹re not there yet. I hope/believe that we can add some of the missing API with 5.3 (as the internal data structures in the JS part of the engine start to settle down). Qt is heading to a JavaScript-based future. Widgets are deprecated and replaced by QML. In this situation, a good extension interface to the JavaScript engine that runs QML is a really important feature. I have to disagree with a couple of items here. Qt has already had JavaScript based scripting support for ages, so it is not heading into using it. As for JS in QML, any sensibly designed application will avoid doing business logic process in the UI. That was already not a good idea when using C++, no need to continue bad practise when the new UI technology hands you a nice way to correct that. In Qt4, widgets were still the main UI technology. Nowadays, widgets are deprecated. (I'm putting quotes due to the comments to my last post, but it is really not hard to see where the development is heading.) Prior to QML apps, JavaScript has been a tool to provide scripting support for C++ applications, but applications were not based on it. Now, the situation has turned around: JavaScript/QML app, C++ extensions. Therefore, I'm sticking to my statement: a good extension interface is an important feature. We will have to disagree there. I consider the UI to be replacable, as free of application logic as possible. In that model QML instantiates objects and connects/binds them. I understand that there is a different approach, basically creating applications like webapps. Do all processing in the UI, only use components for visualization and platform integration. It's more complex than that, because the split between UI logic and application logic can be hard sometimes, especially when the multiple UIs aren't exposing the exact same functionality. (Obviously they expose the same core functionality, but maybe the enterprise edition has more cowbell?) Basically you have the whole range at your disposal. Qt is not there to limit you as an application developer or push you into one way of doing things. While some things could be considered best practice, I believe one of the main strengths of the framework is that application developers have a large degree of freedom and can choose the tools that match the task at hand. So you can do your app fully in C++ using widgets, use QML only as a thing layer on top of C++ app logic, or push a lot or even all of your logic into JS. But as with any tool there are limits. Some things do (and probably always will) require C++, while some others can be most easily achieved through QML. The reason for this is that the problem of creating fluid user interfaces is rather different from the problem of creating the application logic. Cheers, Lars The intended approach, for a JS/QML app with C++ extensions, is that the UI and UI logic are in JS/QML, the application logic is still in C++, but it's exposed through reusable modules. So some stuff that's on the edge moves from application logic to ui logic. As an example, take storing high scores in SameGame. Current model is that it's
Re: [Development] Build errors with raspbian
On Friday, November 15, 2013 01:26:16 Thiago Macieira wrote: On quinta-feira, 14 de novembro de 2013 23:41:12, Stephen Kelly wrote: On Thursday, November 14, 2013 08:49:04 Thiago Macieira wrote: First of all, you seem to be linking statically to glibc. Don't. You seem to start with an assumption that I changed something. Don't. This is using the mkspec for raspberry pi supplied with Qt. I changed nothing. I'm not assuming you changed anything -- I didn't know you had tried before. Although I have built Qt for rasbian before, that's not what I meant. I meant I have not changed any Qt supplied defaults. But you are linking statically, which you should not do. The problem you have is related to the fact that you are statically linking to libc and libdl. That is what you should fix. In that case, one of these must be true: 1) Qt is somehow configured to statically linked to libc and libdl. I see no obvious code doing that in mkspecs/devices/linux-rasp-pi-g++/qmake.conf 2) Everyone else who is building Qt for raspbian has patched but not upstreamed. Unlikely. 3) I somehow have introduced the issue locally. I guess (3) is the most-likely option. The only thing I can think of to cause something like this is a distro upgrade I did to the new ubuntu a few weeks ago. I don't know what to look for though. What can cause static linking to those libs? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] Build errors with raspbian
On segunda-feira, 18 de novembro de 2013 09:57:03, Stephen Kelly wrote: I guess (3) is the most-likely option. The only thing I can think of to cause something like this is a distro upgrade I did to the new ubuntu a few weeks ago. I don't know what to look for though. What can cause static linking to those libs? 1) a linker switch (-static) 2) a compiler setting changing the default switch passed to the linker 3) the absence of libc.so, but presence of libc.a I don't see how a distro upgrade of your host system could have anything to do with the cross-compiling toolchain for the raspberry pi. Unless, of course, the toolchain is provided by ubuntu, in which case they might have broken it. Your initial log is missing important information. There's no full compilation and linker commands, which would allow us to see whether a -static option is present or not. Though you've probably already looked for it and found none. Try to manually compile a simple program that calls dlopen and see if it works. Then check what it got linked against (objdump -p or readelf -l). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Build errors with raspbian
Hi, I've seen this issue before and there it turned out that the sysroot was simply missing the .so files and only the .a versions of the libraries were available. Sounds stupid, but maybe worth double checking :) Simon Fra: Stephen Kelly Sendt: 16:57 mandag 18. november 2013 Til: development@qt-project.org Emne: Re: [Development] Build errors with raspbian On Friday, November 15, 2013 01:26:16 Thiago Macieira wrote: On quinta-feira, 14 de novembro de 2013 23:41:12, Stephen Kelly wrote: On Thursday, November 14, 2013 08:49:04 Thiago Macieira wrote: First of all, you seem to be linking statically to glibc. Don't. You seem to start with an assumption that I changed something. Don't. This is using the mkspec for raspberry pi supplied with Qt. I changed nothing. I'm not assuming you changed anything -- I didn't know you had tried before. Although I have built Qt for rasbian before, that's not what I meant. I meant I have not changed any Qt supplied defaults. But you are linking statically, which you should not do. The problem you have is related to the fact that you are statically linking to libc and libdl. That is what you should fix. In that case, one of these must be true: 1) Qt is somehow configured to statically linked to libc and libdl. I see no obvious code doing that in mkspecs/devices/linux-rasp-pi-g++/qmake.conf 2) Everyone else who is building Qt for raspbian has patched but not upstreamed. Unlikely. 3) I somehow have introduced the issue locally. I guess (3) is the most-likely option. The only thing I can think of to cause something like this is a distro upgrade I did to the new ubuntu a few weeks ago. I don't know what to look for though. What can cause static linking to those libs? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.comhttp://www.kdab.com || 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] http://qt-project.org/wiki/Qt520-RC1-KnownIssues
HI Sze-Howe, As you most probably notice I have seen this issue myself as well. In my opinion it isn't blocking the release: this is p2 issue, it is only in debug build and user can continue by just selecting ignore. I agree it would be nice to get this fixed but still I wouldn't block the release because of this... Br, Jani -Original Message- From: Sze Howe Koh [mailto:szehowe@gmail.com] Sent: 16. marraskuuta 2013 4:48 To: Heikkinen Jani Cc: development@qt-project.org Subject: Re: [Development] http://qt-project.org/wiki/Qt520-RC1- KnownIssues On 15 November 2013 20:49, Heikkinen Jani jani.heikki...@digia.com wrote: Hi all, According to plan we should have Qt5.2 RC1 during next week. So please start updating the known issues page for RC1 And please inform me immediately if you know something is blocking the release and not listed in https://bugreports.qt-project.org/browse/QTBUG-33863 Br, Jani import QtWebKit 3.0 crashes in (some?) Windows machines: https://bugreports.qt-project.org/browse/QTBUG-34066 Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] StereoViewport for Qt3D
On 17 Nov 2013, at 11:11 PM, Svenn-Arne Dragly wrote: I hope so too, but if I don't hear anything I'll just try pushing it to gerrit and see how it goes. Sounds good. I could conceivably test it at home; just got a 3D TV and haven't used it for anything more than movies yet. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QInotifyFileSystemWatcherEngine might have incomplete data?
On Sun, Nov 17, 2013 at 9:23 PM, Mark Gaiser mark...@gmail.com wrote: On Sun, Nov 17, 2013 at 9:20 PM, Mark Gaiser mark...@gmail.com wrote: On Sun, Nov 17, 2013 at 8:03 PM, Olivier Goffart oliv...@woboq.com wrote: On Sunday 17 November 2013 19:07:48 Mark Gaiser wrote: 4. GDB (or whatever you used) should hit the bearkpoint. Now inspace the event members (name specifically). It's empty while it shouldn't be. Hi, I'd add a qDebug() to be sure. Maybe it's just GDB giving wronf information. Perhaps the data as been optimized. Perhaps gdb think the name has lengh 0 because it is declared as a char[]. Hi Oliver, I tried your suggestion and that indeed works though not as i would expect it. Yes, it does get printed on screen when i put event.name in a qDebug line. However, none of the emit signals in that function (readFromInotify) work anymore when i use event.name there. Anywhere! I just tried that out since you've had send the reply. You can find the diff of the stuff that's i've done thus far. Just adding this to your code breaks all the emits and i have no clue as to why that happens or how it's even possible. If you have any clue.. please do tell. Sorry, forgot the diff: http://pastebin.kde.org/pzqb2jph6 Lifetime of 30 days. Nevermind thiis issue. It works just fine now. I had - shamefully - copied the part the checks if the emitted folder is in face being watched. Then i had changed it's value without changing the check so i ended up in this case that didn't made sense at the time. Now it does :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Backporting QTextLayout Performance Improvements to Qt4
Hey all, I'd like to ask again whether I could backport some performance improvements in QTextLayout/QTextEngine from Qt5 to Qt4. Most notably there is https://codereview.qt-project.org/#change,34112 which effects us in Kate/KDE as outlined here: https://bugs.kde.org/show_bug.cgi?id=225228 The changeset above was merged in Qt5 and matured there, see https://codereview.qt-project.org/#change,34118 What I propose is to sync the current status of QTextLayout/QTextEngine from Qt5, put it into a patchset for Qt4 and get it into the next Qt4 release. Would this be accepted? Or is there still a policy which forbids performance improvements to be merged into Qt4? Considering that the above makes the Kate editor practically useless for some files (freezes for multiple minutes), I personally see this as a bug fix anyways... 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] Backporting QTextLayout Performance Improvements to Qt4
Yes, once the patch is in 5.x and it affects 4.8 as well, it¹s usually ok to back port. Cheers, Lars On 18.11.13 11:06, Milian Wolff m...@milianw.de wrote: Hey all, I'd like to ask again whether I could backport some performance improvements in QTextLayout/QTextEngine from Qt5 to Qt4. Most notably there is https://codereview.qt-project.org/#change,34112 which effects us in Kate/KDE as outlined here: https://bugs.kde.org/show_bug.cgi?id=225228 The changeset above was merged in Qt5 and matured there, see https://codereview.qt-project.org/#change,34118 What I propose is to sync the current status of QTextLayout/QTextEngine from Qt5, put it into a patchset for Qt4 and get it into the next Qt4 release. Would this be accepted? Or is there still a policy which forbids performance improvements to be merged into Qt4? Considering that the above makes the Kate editor practically useless for some files (freezes for multiple minutes), I personally see this as a bug fix anyways... Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ 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] Javascript exceptions from QML plugin
Hi, is there a way to emit Javascript exceptions from a C++ QML plugin or more general: what is the best way to indicate errors to QML from within a QML plugin? The reason I ask, is because I am implementing the W3C WebSocket API (see http://www.w3.org/TR/websockets). In several circumstances, the standard says to throw javascript exceptions. Maybe an elegant solution could be to just expose an exception signal, and use that instead. Any advice is welcomed. Cheers, Kurt This message is subject to the following terms and conditions: MAIL DISCLAIMERhttp://www.barco.com/en/maildisclaimer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backporting QTextLayout Performance Improvements to Qt4
On Monday 18 November 2013 10:11:40 Knoll Lars wrote: Yes, once the patch is in 5.x and it affects 4.8 as well, it¹s usually ok to back port. I ask b/c back then Eskil wrote: Eskil Abrahamsen BlomfeldtSep 5, 2012 Patch Set 4: Do not submit I don't think these P3 optimizations should be back-ported to a patch release. Patch releases exist only to increase stability, and that's why we have the commit policy of only allowing critical fixes (regressions, crashes, blatant drawing errors, security). There's already some indication that an earlier optimization for this same bug has introduced a crash which is triggered by Qt Creator (see QTBUG-27140). I'm working to verify it now, but please be conservative when committing to a patch release branch, since that's the only way to avoid destabilization. So just to clarify once more, backporting the changes now from Qt5 is OK? I'd be OK with only backporting the changes from Qt 5.1 or a similar stable branch. Thanks On 18.11.13 11:06, Milian Wolff m...@milianw.de wrote: Hey all, I'd like to ask again whether I could backport some performance improvements in QTextLayout/QTextEngine from Qt5 to Qt4. Most notably there is https://codereview.qt-project.org/#change,34112 which effects us in Kate/KDE as outlined here: https://bugs.kde.org/show_bug.cgi?id=225228 The changeset above was merged in Qt5 and matured there, see https://codereview.qt-project.org/#change,34118 What I propose is to sync the current status of QTextLayout/QTextEngine from Qt5, put it into a patchset for Qt4 and get it into the next Qt4 release. Would this be accepted? Or is there still a policy which forbids performance improvements to be merged into Qt4? Considering that the above makes the Kate editor practically useless for some files (freezes for multiple minutes), I personally see this as a bug fix anyways... 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] http://qt-project.org/wiki/Qt520-RC1-KnownIssues
Ah, I didn't realize it was safe to ignore that assertion. Agreed; it shouldn't block the release then. Thanks for clarifying! Regards, Sze-Howe On 18 November 2013 17:27, Heikkinen Jani jani.heikki...@digia.com wrote: HI Sze-Howe, As you most probably notice I have seen this issue myself as well. In my opinion it isn't blocking the release: this is p2 issue, it is only in debug build and user can continue by just selecting ignore. I agree it would be nice to get this fixed but still I wouldn't block the release because of this... Br, Jani -Original Message- From: Sze Howe Koh [mailto:szehowe@gmail.com] Sent: 16. marraskuuta 2013 4:48 To: Heikkinen Jani Cc: development@qt-project.org Subject: Re: [Development] http://qt-project.org/wiki/Qt520-RC1- KnownIssues import QtWebKit 3.0 crashes in (some?) Windows machines: https://bugreports.qt-project.org/browse/QTBUG-34066 Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backporting QTextLayout Performance Improvements to Qt4
On Monday 18 November 2013 11:06:57 Milian Wolff wrote: Hey all, I'd like to ask again whether I could backport some performance improvements in QTextLayout/QTextEngine from Qt5 to Qt4. Most notably there is https://codereview.qt-project.org/#change,34112 which effects us in Kate/KDE as outlined here: https://bugs.kde.org/show_bug.cgi?id=225228 The changeset above was merged in Qt5 and matured there, see https://codereview.qt-project.org/#change,34118 What I propose is to sync the current status of QTextLayout/QTextEngine from Qt5, put it into a patchset for Qt4 and get it into the next Qt4 release. Would this be accepted? Or is there still a policy which forbids performance improvements to be merged into Qt4? Considering that the above makes the Kate editor practically useless for some files (freezes for multiple minutes), I personally see this as a bug fix anyways... Don't forget that if you want to backport this patch, you also need at least to backport https://codereview.qt-project.org/31089 https://codereview.qt-project.org/31090 and https://codereview.qt-project.org/34288 As a KDevelop/Kate user, i would be pleased to be able to open files with long lines without the current kate workaround to force a wrapping. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backporting QTextLayout Performance Improvements to Qt4
On Monday 18 November 2013 12:46:24 Olivier Goffart wrote: On Monday 18 November 2013 11:06:57 Milian Wolff wrote: Hey all, I'd like to ask again whether I could backport some performance improvements in QTextLayout/QTextEngine from Qt5 to Qt4. Most notably there is https://codereview.qt-project.org/#change,34112 which effects us in Kate/KDE as outlined here: https://bugs.kde.org/show_bug.cgi?id=225228 The changeset above was merged in Qt5 and matured there, see https://codereview.qt-project.org/#change,34118 What I propose is to sync the current status of QTextLayout/QTextEngine from Qt5, put it into a patchset for Qt4 and get it into the next Qt4 release. Would this be accepted? Or is there still a policy which forbids performance improvements to be merged into Qt4? Considering that the above makes the Kate editor practically useless for some files (freezes for multiple minutes), I personally see this as a bug fix anyways... Don't forget that if you want to backport this patch, you also need at least to backport https://codereview.qt-project.org/31089 https://codereview.qt-project.org/31090 and https://codereview.qt-project.org/34288 Yep, I'd ensure that everything is backported until the current state in Qt5 is reached. 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] Backporting QTextLayout Performance Improvements to Qt4
On 18.11.13 11:49, Milian Wolff m...@milianw.de wrote: On Monday 18 November 2013 10:11:40 Knoll Lars wrote: Yes, once the patch is in 5.x and it affects 4.8 as well, it¹s usually ok to back port. I ask b/c back then Eskil wrote: Eskil Abrahamsen Blomfeldt Sep 5, 2012 Patch Set 4: Do not submit I don't think these P3 optimizations should be back-ported to a patch release. Patch releases exist only to increase stability, and that's why we have the commit policy of only allowing critical fixes (regressions, crashes, blatant drawing errors, security). There's already some indication that an earlier optimization for this same bug has introduced a crash which is triggered by Qt Creator (see QTBUG-27140). I'm working to verify it now, but please be conservative when committing to a patch release branch, since that's the only way to avoid destabilization. So just to clarify once more, backporting the changes now from Qt5 is OK? I'd be OK with only backporting the changes from Qt 5.1 or a similar stable It’s ok, as long as it fits the policy for patch level releases. Larger performance issues can fit into that category, but you would need to find someone to take the time to thoroughly review and test the code on 4.8. Having the code tested and in released version of 5.x helps with that, but is probably not enough in itself. Cheers, Lars branch. Thanks On 18.11.13 11:06, Milian Wolff m...@milianw.de wrote: Hey all, I'd like to ask again whether I could backport some performance improvements in QTextLayout/QTextEngine from Qt5 to Qt4. Most notably there is https://codereview.qt-project.org/#change,34112 which effects us in Kate/KDE as outlined here: https://bugs.kde.org/show_bug.cgi?id=225228 The changeset above was merged in Qt5 and matured there, see https://codereview.qt-project.org/#change,34118 What I propose is to sync the current status of QTextLayout/QTextEngine from Qt5, put it into a patchset for Qt4 and get it into the next Qt4 release. Would this be accepted? Or is there still a policy which forbids performance improvements to be merged into Qt4? Considering that the above makes the Kate editor practically useless for some files (freezes for multiple minutes), I personally see this as a bug fix anyways... Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ 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.2 RC1
Hi all, As most of you most probably know we have had problems to get changes into the packages. That's why there is quite much changes pending integration to qt5.git at the moment. We should now have fixes available for known integration issues and we are really hoping we could get qt5.git integrated today. So let's hope we will have new snapshot available tomorrow with updated content and you can start testing verification of your fixes... Unfortunately this all means we cannot release Qt 5.2 RC1 tomorrow. I am hoping we could do it later this week but it can be seen only after we manage to get packages with new content under testing. I will inform you tomorrow about the situation with packages etc. Let's all do our best to get RC1 out as soon as possible Br, Jani -- Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] StereoViewport for Qt3D
On Sunday 17 November 2013 23:11:32 Svenn-Arne Dragly wrote: On Wed 06 Nov 2013 12:54:07 PM CET, Rutledge Shawn wrote: On 28 Oct 2013, at 10:35 PM, Svenn-Arne Dragly wrote: Secondly, I was missing a stereo option for the default QML Viewport element, and decided to have a look at the implementation in QGLView to see if I could port that to the QML Viewport element. Luckily this was quite easy (thanks to Qt3D being well designed) and I have uploaded the resulting StereoViewport element to a GitHub repository: https://github.com/dragly/stereoviewport This should compile with Qt5.1.1 and the latest master branch of Qt3D. Cool. Are you using it with an Oculus Rift, 3D TV or something else? Both and Oculus Rift and a 3D TV, actually. I have tested the stereo mode where the viewport is split in two thoroughly, with one half of the screen for the left eye and the other for the right. It works quite well and seems to be stable. Now, I'm wondering if this feature should be a part of the original Viewport element. Should I contribute this into the main Qt3D repository? If so, what steps should I take before doing this, apart from those listed in the Qt Contributing Guidelines? I'm for instance not sure if I might have introduced some bugs or damaged any features of the original Viewport element. How should I verify that I haven't done so? I don't know much about that but I'm sure you will get a reply from someone who does. But it sounds like a good feature to have. I hope so too, but if I don't hear anything I'll just try pushing it to gerrit and see how it goes. Apologies, I missed this thread. Yes, please submit the patch to gerrit. We're not allowed to accept patches any other way. I don't have any 3D stereoscopic devices to try it on yet so I'll have to take your word for that part. Many thanks, 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
[Development] ChangeLog updated for 5.2.0
I've just updated the Changelog for 5.2.0 with the output from the script that I've just uploaded at https://codereview.qt-project.org/71641. The changelog update is at https://codereview.qt-project.org/71642. There were exactly 31 commits with [ChangeLog]. Please start using it more. Here's the raw output before I manually merged and fixed mistakes: $ perl qtsdk/packaging-tools/create_changelog.pl . v5.1.0..origin/release Important Behavior Changes -- - The supported date range in QDateTime has been reduced to about +/- 292 million years, the range supported by the number of msecs since the Unix epoch of 1 Jan 1970 as stored in a qint64, and as able to be used in the setMSecsSinceEpoch() and toMSecsSinceEpoch() methods. - QUrl and QUrlQuery: * [QTBUG-31660] QUrl no longer considers all delimiter characters equivalent to their percent-encoded forms. Now, both classes always keep all delimiters exactly as they were in the original URL text. * QUrl no longer supports QUrl::FullyDecoded mode in authority() and userInfo(), nor QUrl::DecodedMode in setAuthority() and setUserInfo(). * [QTBUG-31945] QUrl no longer decodes %23 found in the fragment to # in the output of toString(QUrl::FullyEncoded) or toEncoded() * QUrl now defaults to decoded mode in the getters and setters for userName, password, host, topLevelDomain, path and fileName. This means a '%' in one of those fields is now returned (or set) as '%' rather than %25. In the unlikely case where the former behavior was expected, pass PrettyDecoded to the getter and TolerantMode to the setter. * QUrl now normalizes the path given in setPath, removing ./ and ../ and duplicate slashes. QtCore -- - QDateTime: * [QTBUG-26161][QTBUG-29666] Fully implement support for Qt::TimeSpec of Qt::OffsetFromUTC, added new methods for offsetFromUTC(), toTimeSpec(), and toOffsetFromUTC(). * Added convenience methods for fromMSecsSinceEpoch() and fromTime_t() to take time spec to be used in returned datetime. * Add method timeZoneAbbreviation() to return effective time zone abbreviation. * The debug datastream is now an ISO-like format instead of Qt::TextDate * The Standard Time to Daylight Time transition for Qt::LocalTime is now handled correctly. Any date set in the missing hour is now considered invalid. All date math results that fall into the missing hour will be automatically adjusted to a valid time in the following hour. * Added new method isDaylightTime() to return if the datetime is in Daylight Time or not. * Add support for a new Qt::TimeZone spec to be used with QTimeZone to define times in a specific time zone. - QJsonValue: * Added QJsonValue::toInt(). - QStandardPaths: * QStandardPaths::enableTestMode is deprecated and is replaced by QStandardPaths::setTestModeEnabled. - QTime: * Added new methods fromMSecsSinceStartOfDay() to create a new QTime from an msecs value, and msecsSinceStartOfDay() to return the QTime as the number of msecs since the start of the day. - QTimeZone: * Added new QTimeZone class to support time tone calculations using the host platform time zone database and the Olsen time zone ID's. - QUtf8: * [QTBUG-33229] UTF-8 now accepts non-character unicode points; these are not replaced by the replacement character anymore - QVariant: * Fixed QVariant::canConvert with longlong * Variant containing enum types can now be converted to integer QtDeclarative - - ColorDialog: * Added currentColor property. QtGui - - QPolygonF: * When a QVariant holds a QPolygonF() then it will be correctly seen as a null QVariant. QtPrintSupport -- - QPrintDialog: * Added support for setting CUPS job options in the print dialog. * Added support for setting CUPS Banner pages in the print dialog. * Added support for setting CUPS Page Set (even/odd pages only) in the print dialog. * Added support for setting CUPS Pages Per Sheet and Pages Per Sheet Layout options * Added CUPS server-side print range support for apps that can't support print range option themselves QtWidgets - - QAbstractItemView: * [QTBUG-7232] QTBUG-7232 - In ItemViews scrollbars will now by default only scroll 1 pixel when scrollMode is set to scrollPerPixel. That is it will (when scrollMode is scrollPerPixel) do what is stated in the documentation, and no longer automatically adjust the scrollbars singleStep. The user can now control that value. - QHeaderView: * [QTBUG-4346] A maximumSize for sections has been introduced. The maximum section size is by default the largest possible section size which in Qt 5.2 has been limited to 1048575 pixels. - QTBUG-1180: * [QTBUG-1180] Dragging an item outside the QListView in icon mode
[Development] Qt5.2 RC1 snapshot
Hi all, Unfortunately there were again some issues with qt5.git integration: openSSL -folder was missing in (one) CI machine and that's why integration failed :( Why it was missing is totally unclear, same stage was executed in that same machine couple of days ago without problems... Folder is now added and integration restarted. But that means we don't have packages for testing and verification this morning. Hoping everything goes OK now and we could have new packages with new content later today... We will keep you informed... Br, Jani -- Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt5.2 RC1 snapshot
Hi all, Unfortunately there were again some issues with qt5.git integration: openSSL -folder was missing in (one) CI machine and that's why integration failed :( Why it was missing is totally unclear, same stage was executed in that same machine couple of days ago without problems... Folder is now added and integration restarted. But that means we don't have packages for testing and verification this morning. Hoping everything goes OK now and we could have new packages with new content later today. We will keep you informed Br, Jani -- Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
