Re: [Development] Future of Qt Quick 1 in Qt 5
Hi, On 11.05.2015 12:00, André Somers wrote: Simon Hausmann schreef op 11-5-2015 om 09:21: On Saturday, May 09, 2015 09:59:18 PM Andre Somers wrote: On 8-5-2015 18:47, Hausmann Simon wrote: If the public API would allow you to implement what the folks at KDAB did at http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ , would that help your use case? What they basicaly did was reimplement the Quick elements they were using, if I understood it right from an earlier time I read that blog, and then solve all kinds of issues with rendering that were already solved inside Qt itself... So, it comes down to implementing the elements of Quick 1 on your own again for the elements you need, or something close to it. It is what I called "major work" in my first reply. And indeed: I guess doing this requires heavy use of private API. So far, QML and Quick are not all that friendly for C++-side extensions... This doesn't match my understanding of what they have done at all. I understand their article as having basically "visited" all items in the scene and having had to use private API to access the data so that they can implement printing outside of Qt Quick, but still using standard Qt Quick elements. But perhaps I misread it. What is your understanding after re-reading it? Ok, indeed, you're right. They didn't re-implement the actual items, they "just" reimplemented everything needed in those items to render them. Indeed: visiting each item and then figuring out how to render it completely from scratch. But they only did that for a handfull of items, and not taking into account all possibly relevant properties because they didn't use them as much. Yep, correct. We pretty much only needed Text, Rectangle and Image for our usecase, and indeed didn't bother with many properties such as Image.TileMode. Certainly not a very general solution, though it works nicely for us. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH & Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On 13.10.2014 13:46, André Somers wrote:
Milian Wolff schreef op 11-10-2014 16:44:
On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote:
On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote:
On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote:
Em 10/10/2014 06:18, "Oswald Buddenhagen" <
oswald.buddenha...@theqtcompany.com> escreveu:
On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
may I ask why you don't simply copy KConfig? It's API design has
proven to be extremely versatile and efficient over the years.
actually, it has proven horrible and is slated for a rewrite for a
decade. the only thing it does right is what tomaz copied to his api.
(still sleeping, só I will write better latter) I used kconfig and I
tougth it was terrible to use, that why I came to thiago and hélio
Castro
asking if I could try a new one.
I'll read the emails on this thread and change the code accordingly.
Please double-check the KConfig API and copy more of its behavior. Some of
that stuff was also mentioned by Thiago, Bo and Kai:
QConfig("identifier_or_filename"); // this should also be the root group
config.setValue("bla", 123); // would set a global config value, with
multiple
overloads or template functions
QConfigGroup group = config.group("something"); // smart handle with
reference
semantics
group.readValue("blub", /* default value */); // read value in group, also
overloads and/or template function
foreach (QConfigGroup subGroup, group.groups()) // or similar
qDebug() << subGroup.name();
I still think that KConfig, API-wise, is extremely convenient and haven't
seen
anything better so far. The internals and performance is a bit lacking,
but
usually not a problem and definitely not related to the API.
It's too error prone regarding typos.
// main.cpp
KConfig c;
KConfigGroup g = c.group("blah");
g.setValue("width", 10);
// otherfile
Kconfig c;
KConfigGroup g = c.group("blah");
g.value("widht"); // <- no error is issued, this is something that I wanna
have it fixed.
How do you intend to fix it? Esp. when looking at what Rafael proposes? If you
declare any other class to be used instead of a string, the user can still mix
two variables up.
I don't see what that has to do with KConfig/QConfig, really.
Bye
We're moving away from using these keys directly at all. Instead, we
only use a real, type safe interface anymore for settings. That is:
every setting gets a real getter and setter in a Settings class. That
class is responsible for storing and retreiving the setting from the
backend (which, in our case, has several levels now). If needed, there
is not only a getter and a setter, but also a corresponding changed
signal, but that changed signal currently only works if the setting is
changed from inside the application itself (good enough for us).
Personally, I think that using string-based key-value pairs (whether the
key has grouped semantics or not) and then manually casting the value to
the needed everywhere you need it simply has no place in application
code in all but the simplist applications. API's need to be type-safe if
at all possible, and if not, the exposure to the non-type safe API
should be kept to a minimum. Further more: default values need to be
consistent. Allowing the application to access the backend from more
than one place, also means having the specify the default value for
settings in more than one place. That *will* lead to inconsistencies. In
our case, that means that there is only one class where there is
exposure to the non-type safe QVariant-based API of Qt, and that is the
settings class itself. The rest of the application has no clue, nor
needs to have any clue, on how the settings are stored: they are just
using type-safe properties with clearly defined default values.
I would like to see some (modular) kConfig XT-like settings
specification that results in type save code within Qt though.
Preferably with a nice editor-plugin inside Creator. Or, perhaps based
on the Q_PROPERTIES or something similar allowing you to use a default
getter/setter implementation for simple cases, and add your own for more
complex ones. That would already save a lot of boilerplate code. I don't
believe in auto-generating configuration dialogs, though a tree
representation would be useful for advanced editing and developer settings.
+1, something like KConfigXT that auto-generates QObjects with
appropriate getters, setters and Q_PROPERTIES would be very useful. Not
just for type safety - also for exporting settings objects directly to
the QML world, which otherwise is a lot of boilerplate code to write.
Regards,
Thomas
--
Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-
Re: [Development] Some more maintainer nominations
Hi, On 13.10.2014 13:36, Knoll Lars wrote: I’d like to nominate a few more maintainers. Most of the below should be simply about making the de-facto status official, ie. Putting the person that does most of the work on the module in charge. Qt WebChannel: Milian Wolff Having worked together with Milian on this project before, I can attest that he also has a great understanding of the JS world, in addition to the Qt world. So I think Milian will make a good maintainer and fully support the nomination. Disclaimer: We both work at the same company. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Harmonizing the Qt 5.x Documentation
Hi, On Thursday 03 April 2014 08:02:16 Rutledge Shawn wrote: > On 2 Apr 2014, at 6:07 PM, Ariel Molina wrote: > > The current state of Qt docs is very sad, making online searches near to > > useless. All Google searches refer either to broken pages, to 4.x doc > > pages, to incomplete 5.0 unstables or even to 3.3 documentation. What's > > the point on having 5.x (or any) docs if you keep moving them around > > hiding it from search engines and breaking links on every site that > > links to you? > > > > You might point a root folder, but, let's be honest, none uses any root > > folder to search, everyone uses Google or another search engine. > > > > Please whatever you do, do not break this anymore, the current state is > > already messed up. > > I agree. But I think the idea was to change it one last time and then > never change it again, and the docs that google finds should be always the > latest rather than a particular version. I hope that goal is achieved... Moving around is fine, but please make sure old links redirect to the new places. It is not just Google results affected by moving around docs, it is also links in other places like answers in Stackoverflow questions. And yes, the fact that Google finds old versions is a problem. For example a search for "qprocess setreadchannel" will give the 4.8 version as the first result. How about adding a "Versions" box to the sidebar that gives convenient links to all other versions of the QProcess documentation? Then even if Google finds an old version first, the user can quickly jump to the newest. Btw, any idea why Google prefers the 4.8 version? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Join us in October at Qt Developer Days 2014! - https://devdays.kdab.com smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
Hi,
On Wednesday 04 December 2013 11:47:29 Sletta Gunnar wrote:
> If we added conversion functions for inch(), cm(), mm(), points() to
> QQuickItem, it could look up its current window/screen object and figure
> out the relationship between each unit for the screen the item is on and
> just set that. The app can then layout in the unit space it prefers with
> information readily available.
>
> Text {
> font.pixelSize: cm(0.5);
> anchors.left: parent.left
> anchors.margins: cm(0.25);
> }
>
>
> Making them functions makes it impossible to listen for screen changes
> which in turn trigger dpi changes so they would have to be properties...
>
> Text {
> font.pixelSize: 0.5 * cm;
> anchors.left: parent.left
> anchors.margins: 0.25 * cm;
> }
Interesting, the cm() function is another example that shows the need for
functions having NOTIFY signals.
The other example is qsTr(), since you want to have updates when the language
changes. Although for qsTr(), there is a patch somewhere that adds support for
just that in the QML engine, a generic mechanism for NOTIFY support in
functions would be nice.
Regards,
Thomas
--
Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. 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] Nominating Fabian Bumberger for Approver Status
Hi, On Tuesday 19 November 2013 11:41:52 Blasche Alexander wrote: > I'd like to nominate Fabian Bumberger for approver status in the Qt > Project. > > Fabian has been contributing to QtNfc, QtBluetooth, QtLocation and many > more Blackberry specific topics such as the platform plug-ins. His track > record can be found under: > > https://codereview.qt-project.org/#q,owner:fbumberger,n,z > https://codereview.qt-project.org/#q,reviewer:fbumberger,n,z > > >From my perspective QtBluetooth and QtNfc wouldn't be the same without his > >help. > > I am convinced he will make en excellent approver. I support this. I have worked together with Fabian on the QNX QPA plugin, where he did good work. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Spring-cleaning the Gerrit dashboards, again
Hi, On Wednesday 20 March 2013 19:31:17 Thiago Macieira wrote: > Can we please agree on cleaning the dashboards up? Or, if we've agreed, > can we do it? > > My dashboard is unusable. For a few months now, I have stopped my daily > look at the "Review Requests" section. As a result, I have missed > important reviews of new features that should maybe be in 5.1, but will > probably miss the deadline because my comments come in too late. Tough > luck if you were affected. > > I don't care how we're going to solve this, but can we please agree that > we need to solve it and do solve it? To be frank, I really don't care if > people feel offended that their patch that they haven't updated for 4 > months gets "abandoned". If someone can find a better word, say so. If > someone knows whether it's possible to create a separate state in Gerrit > and this person can do it in our Gerrit installation within two weeks, say > so. +1, agree completely. Let's just abandom them. It is not like the patch is shredded and lost. The cluttered dashboards are a real problem. In the past, I have removed myself from old reviews, with all the drawbacks that this brings, which we discussed earlier. And I am not even added to many reviewers, I can only imagine how Thiago's situation might look like. So yes, we really need a technical solution for this. Auto-abandoning stale reviews seems to be the easiest short-term solution. A seperate Gerrit state would be an improvement on that. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Starting preparations for Qt 5.1
Hi, On Monday 18 March 2013 16:18:07 Knoll Lars wrote: > >On Mon, Mar 18, 2013 at 10:24:23AM +, Ahumada Sergio wrote: > >> Hi, > >> > >> > >> > >> Making of Qt 5.1 minor release will soon start: > >> > >> > >> - Plan is to move 'dev' into 'stable' branch on March 19th. > >> > >> > > > >i'd like to raise a formal objection. > > > >CI was virtually unusable for two weeks now. > >due to that there is a completely unreasonable backlog of changes meant > >for 5.1 now. it makes no sense to re-target (or even deny them) due to > >infrastructure problems. > > We have said that we'll move to time based releases. Should we stop this > because we aren't yet good enough in controlling our systems? I don't > think so. It might feel unfair to some people, but we've had these > discussions about some features missing the deadline every single minor > release. > > Now if there are one or two features that are vital to make Qt 5.1 > possible, we can discuss exceptions for those. QtSensors needs to be added to qt5.git, but couldn't yet, due to CI failures. See https://codereview.qt-project.org/#change,48905. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Qt 5.1 feature set and freeze date
Hi, On Monday 25 February 2013 17:11:53 Pasion Jerome wrote: > > > I would like to start the feature freeze Qt 5.1 middle of March. [..] > > > > > > Quite a bit of new functionality has made it into the dev branch, but > > > I'd also like to add a few of the modules left out in 5.0 to the > > > release. The candidates I can see so far are: > > > > > > * Qt X11 Extras > > > * Qt Mac Extras > > > * Qt Sensors > > > * Qt Serial Port > > > * Qt Quick Controls (formerly known as desktop components) > > > > Great to see QtSensors back in. > > I am about to create a patch to include it in qt5.git. What else needs to > > be done so that its documentation shows up in > > http://doc-snapshot.qt-project.org/? > > The main requirements are: > -the docs are modularized and conform to the Qt 5 documentation structure: > http://qt-project.org/wiki/Qt5DocumentationProject -the docs compile > readily using "make docs" Yep, works. Created a patch that fixes the doc configuration a bit: https://codereview.qt-project.org/#change,49058 > It would be helpful if Qt Sensors are in qt5.git as well. Patch available at https://codereview.qt-project.org/#change,48905 Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Qt 5.1 feature set and freeze date
Hi, On Wednesday 13 February 2013 09:49:56 Knoll Lars wrote: > Hi everybody, > > I would like to start the feature freeze Qt 5.1 middle of March. This is a > bit later then I originally proposed in December. There's two reasons for > this. First of all it'll reduce some of the integration pressure for the > Android ports as well as the Qt Quick Controls. Secondly, the release team > will be busy to get 5.0.2 out by by that time and won't have time to focus > on the 5.1 branch before middle of March. > > The freeze will be done by merging dev back into stable, and then working > mainly on stable for a while to get a 5.1 beta and then 5.1.0 out. The > beta should happen as soon as possible after the feature freeze, and I'd > like to aim for 5.1.0 final by end of April. > > Quite a bit of new functionality has made it into the dev branch, but I'd > also like to add a few of the modules left out in 5.0 to the release. The > candidates I can see so far are: > > * Qt X11 Extras > * Qt Mac Extras > * Qt Sensors > * Qt Serial Port > * Qt Quick Controls (formerly known as desktop components) Great to see QtSensors back in. I am about to create a patch to include it in qt5.git. What else needs to be done so that its documentation shows up in http://doc-snapshot.qt-project.org/? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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 faild on Ubuntu 12.04
Hi, bug in the dbus library headers, they don't compile in C++11 mode. Either update dbus, disable dbus in Qt or disable C++11 in Qt. See https://bugs.freedesktop.org/show_bug.cgi?id=46147. Regards, Thomas On Wednesday 13 February 2013 16:59:53 Дмитрий Волосных wrote: > It fails at this step: > > g++ -c -m64 -pipe -I/usr/include/dbus-1.0 > -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -g -std=c++0x > -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall > -W -D_REENTRANT -fPIC -DQT_NO_LIBUDEV -DDBUS_API_SUBJECT_TO_CHANGE > -DQT_BUILD_DBUS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII > -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER > -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 > -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE > -DQT_CORE_LIB -I../../mkspecs/linux-g++-64 -I. -I../../include > -I../../include/QtDBus -I../../include/QtDBus/5.0.1 > -I../../include/QtDBus/5.0.1/QtDBus -I../../include/QtCore > -I../../include/QtCore/5.0.1 -I../../include/QtCore/5.0.1/QtCore > -I.moc/debug-shared -o .obj/debug-shared/qdbusabstractinterface.o > qdbusabstractinterface.cpp > g++ -c -m64 -pipe -I/usr/include/dbus-1.0 > -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -g -std=c++0x > -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall > -W -D_REENTRANT -fPIC -DQT_NO_LIBUDEV -DDBUS_API_SUBJECT_TO_CHANGE > -DQT_BUILD_DBUS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII > -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER > -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 > -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE > -DQT_CORE_LIB -I../../mkspecs/linux-g++-64 -I. -I../../include > -I../../include/QtDBus -I../../include/QtDBus/5.0.1 > -I../../include/QtDBus/5.0.1/QtDBus -I../../include/QtCore > -I../../include/QtCore/5.0.1 -I../../include/QtCore/5.0.1/QtCore > -I.moc/debug-shared -o .obj/debug-shared/qdbusinternalfilters.o > qdbusinternalfilters.cpp > qdbusinternalfilters.cpp: In function ‘QString > qDBusIntrospectObject(const QDBusConnectionPrivate::ObjectTreeNode&, > const QString&)’: > qdbusinternalfilters.cpp:126:36: error: inconsistent user-defined > literal suffixes ‘DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER’ and > ‘DBUS_INTROSPECT_1_0_XML_SYSTEM_IDENTIFIER’ in string literal > qdbusinternalfilters.cpp:126:36: error: unable to find string literal > operator ‘operator"" DBUS_INTROSPECT_1_0_XML_PUBLIC_IDENTIFIER’ -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reviews needed before android integration in two weeks
Hi, On Wednesday 06 February 2013 13:05:33 Paul Olav Tvete wrote: > On Wednesday 6 February 2013 09:41:46 Paul Olav Tvete wrote: > > On Wednesday 6 February 2013 09:00:41 Thomas McGuire wrote: > > > A workaround would be to squash all commits of the branch together into > > > a single patch and then upload that to Gerrit for review. Now, > > > actually pushing the single patch would lose history, so we'd instead > > > manually do a > > > proper merge of the branch. How about we do that for the Android merge? > > > > That's a great idea! We can push a squashed commit as a WIP to gerrit. I > > think we should do a preliminary one this week. (And yes, this is a "we > > should" that means "I will" in the old Trolltech tradition :) > > Here is a squashed commit of all changes to qtbase, for those who like to > see everything in one place: > https://codereview.qt-project.org/#change,46976 > > qtdeclarative: https://codereview.qt-project.org/#change,46983 > qtsensors: https://codereview.qt-project.org/#change,46984 Thanks, that is quite helpful. Discovered some more things during the review on Gerrit. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Reviews needed before android integration in two weeks
Hi, On Tuesday 05 February 2013 14:22:47 Thomas McGuire wrote: > On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote: > > One of the major features for Qt 5.1 is Android support. We have been > > doing the work in a feature branch, and are now getting ready to > > integrate to the dev branch. To beat the rush of integrations before > > feature freeze, we aim to start the integration in two weeks time. > > > > Most of the changes are android-specific, but there are a few changes > > touching cross-platform code. To make the integration go smootly, we ask > > approvers and maintainers to check the android changes in their areas > > now, so we can fix any problems before the merge. To see the changes, > > check out (or diff against) the "wip/android" branch. > > > > I have appended a list of changed files for the following repositories: > > qtsensors > > Another thing: [...] And another one: Please add the Android platform to the compatibility table in the docs, which shows what sensors are available for each platform. It is the file src/sensors/doc/src/compatmap.qdoc. Also, if there are any Android- specific gotchas, they should go to the "Platform-specific Information" section in qtsensors.doc. As I side note, I find this reviewing-by-email quite inconvenient. It doesn't give anyone the chance to -1 properly, and comments per email are less than convenient. All this increases the risk of changes getting merged without a proper review, and consequently is bad for the quality of Qt at large. I expect we'll have the same kind of issues when we merge other branches like the winrt one. A github-style review of the complete branch before merging would really be nice and solve all these issues. I guess this is not yet supported by Gerrit? A workaround would be to squash all commits of the branch together into a single patch and then upload that to Gerrit for review. Now, actually pushing the single patch would lose history, so we'd instead manually do a proper merge of the branch. How about we do that for the Android merge? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] CI system is temporarily down
Hi, On Tuesday 05 February 2013 12:58:21 Fält Simo wrote: > Huh, > CI is up and running normally again. I am getting weird errors when trying to get a QtSensors patch merged: A crash on exit of the unit test, with an assert: ASSERT: "lib->pHnd" in file plugin/qlibrary.cpp, line 376 The patch is quite trivial and should not cause any issues, the patch just removes an unused variable: https://codereview.qt-project.org/#change,46462 In addition to the patch being trivial, the auto tests runs here and shows no (significant) valgrind errors. Any idea what the reason for this CI failure can be? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Reviews needed before android integration in two weeks
On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote: > One of the major features for Qt 5.1 is Android support. We have been > doing the work in a feature branch, and are now getting ready to > integrate to the dev branch. To beat the rush of integrations before > feature freeze, we aim to start the integration in two weeks time. > > Most of the changes are android-specific, but there are a few changes > touching cross-platform code. To make the integration go smootly, we ask > approvers and maintainers to check the android changes in their areas now, > so we can fix any problems before the merge. To see the changes, check out > (or diff against) the "wip/android" branch. > > I have appended a list of changed files for the following repositories: > qtsensors Another thing: I had a look at the diff, and saw that it renames the plugin interfaces from com.nokia to org.qt-project. However this change is incomplete, as it misses the examples, tests and doc snippets. I'd prefer if you revert that change in the branch. Lorn is already working on the same renaming at https://codereview.qt- project.org/#change,45288, and that patch seems to rename all instances. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Reviews needed before android integration in two weeks
Hi, On Tuesday 05 February 2013 11:33:29 Paul Olav Tvete wrote: > One of the major features for Qt 5.1 is Android support. We have been > doing the work in a feature branch, and are now getting ready to > integrate to the dev branch. To beat the rush of integrations before > feature freeze, we aim to start the integration in two weeks time. > > Most of the changes are android-specific, but there are a few changes > touching cross-platform code. To make the integration go smootly, we ask > approvers and maintainers to check the android changes in their areas now, > so we can fix any problems before the merge. To see the changes, check out > (or diff against) the "wip/android" branch. > > I have appended a list of changed files for the following repositories: > qtsensors I had a very quick look at QtSensors, and there are some inconsistency with units. For example, according to https://developer.android.com/reference/android/hardware/SensorEvent.html#values, the Android API reports magnetic field values in microteslas, whereas the units of QMagnetometerReading are teslas. There doesn't seem to be a conversion in AndroidMagnetometer::onSensorChanged(), so the reported units in QtSensors will be off by a factor of 1000. This should be fixed for several reasons, like portability, documentation being wrong and to have proper functioning sensor gestures, which rely on correct units. I'd advise you to check the other sensors as well, there is no conversion anywhere, that seems too easy to be true to me. Also, please double-check if the axes are correct. Many sensors like the accelerometer have a x, y and z axis. Do these have the same coordinate system as in QtSensors? Do these have the same angle representation (radians vs degrees)? Also, my most beloved sensor, the rotation sensor, uses euler angles (Tait– Bryan, to be exact, IIRC). For euler angles, the order or rotation matters(!). Is that the same in Android? is the unit range the same (for example QRotationReading's y goes from -180 to +180, whereas x goes from -90 to 90)? For the Blackberry backend, I had to convert from the OS sensor service's Z- Y'-X'' system to QtSensor's Z-X'-Y'' system, for example. The documentation of the reading classes in Qt, for example QRotationReading, have quite informative pictures, and in the case of QRotationReading, are even animated, to understand things better. This needs testing. I tested by waving/rotating my phone around (to the amusement of the rest of the office) and comparing the reading values to what the documentation tells they should be. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. 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] Moving Qt 4 mobility and qt-labs to gerrit
Hi, On Thursday 01 November 2012 09:02:44 Knoll Lars wrote: > As part of the transfer from Nokia to Digia, we've also inherited the > rights to Qt mobility (4.x), as well as the content of qt-labs > (http://qt.gitorious.org/qt-labs/). We want to start moving these projects > over to gerrit/codereview in the next days, so that they have a new home > where people can contribute to them again (the gitorious mainlines are > read-only currently). Great news, thank you for pushing this forward! Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8 CI problems
Hi Janne, thanks a lot about the update, good to know why it was failing and that it is going to be resolved. Keep up the good work. Regards, Thomas On Monday 29 October 2012 14:29:53 Anttila Janne wrote: > Hi, > > There have been various problems on Qt 4.8 CI since we moved that project > from Nokia to Digia hosting - I'm sorry that those problems have been > preventing you to get anything in to Qt 4.8 since last Thursday. > > Apparently I made wrong decision to move 4.8 CI from Nokia hosting to Digia > hosting before build succeeded on Digia hosting. I made my decision > based on false assumption that 4.8 CI should pass in our machines because > all Qt5 modules were passing. > > As a latest (hopeless) action we decided to make autotests results > temporarily insignicant for Windows configurations with Qt 4.8 CI. > This _should_ now make 4.8 CI passing again. Once we get complete list of > failing autotests we will go them through one by one and fix them in > order to get tests significant again. > > === > > Summary about the problems for those interested: > > 1. Digia hosted environment had newer version of Curys installed > on auto test server, which made many network auto tests to fail: > https://codereview.qt-project.org/37849 > > 2. Microsoft DNS server used in Digia hosted Qt-Project CI system did not > respond as expected by one of the network autotest: > https://codereview.qt-project.org/37853 > > 3. QHttp autotest failed because expected 200 OK from qt.nokia.com, > but the server had redirect activated to qt.digia.com and returned 301: > https://codereview.qt-project.org/37858 > > Fixes for these were implemented and initially run through Nokia hosted > 4.8 CI but unfortunately these builds failed due flaky tests. To avoid > these failures on Digia hosted system, the following additional change was > made before 4.8 CI Project was moved to Digia hosting: > > 4. Marked flaky tst_qlocalsocket autotest insignificant: > https://codereview.qt-project.org/38137 > > Then CI builds and testing proceeded further under Digia hosting and it was > found out that: > > 5. QEXPECT_FAIL in tst_qaccessibility::textEditTest test started to pass on > Digia hosted Ubuntu 10.04 machines: > https://codereview.qt-project.org/38221 > > 6. Digia hosted Windows CI testers did not have OpenSSL installed and > tst_qsslsocket failed to compile when OpenSSL was not available: > https://codereview.qt-project.org/38263 > > Builds/testing got a bit further again and it was found out that also: > > 7. Network selftest started to fail on Windows because OpenSSL was not > installed: https://codereview.qt-project.org/38363 > > 8. Execution of tst_qthread and tst_qxmlquery timed out after 450 seconds > in Digia hosted environment: https://codereview.qt-project.org/38363 > > Once all of these changes were in Gerrit, approved and staged; the Gerrit > bug https://bugreports.qt-project.org/browse/QTQAINFRA-509 stepped in and > prevented 4.8 CI to run during Sunday. The change I6ffa96a was manually > changed back to integrating state and 4.8 CI restarted this morning. > > Then we faced the next error in tst_QHttpNetworkConnection::nossl autotest, > and made a decision to mark all autotests on Windows temporarily > insignificant for 4.8 CI. All these problems compined with quite long turn > around time of Qt 4.8 CI, made CI to be broken as long as it has been. > > Next steps: > > OpenSSL will be installed to Digia hosted Windows CI testers soon, > but tst_networkselftest probably need to stay insignificant until the > reason for this is found: > https://bugreports.qt-project.org/browse/QTBUG-27571. > > The reason for tst_qthread and tst_qxmlquery time out; and flakiness of > tst_qlocalsocket and failures of other autotests will be investigated and > tests reverted back to significant when the root cause(s) for failures > is found and fixed. > > Br, > -- > Janne Anttila > Senior Architect - Digia, Qt > Visit us on: http://qt.digia.com > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QtMobility to qt-project.org
Hi, On Monday 15 October 2012 14:21:18 Sze Howe Koh wrote: > Pardon my ignorance; before reading this I thought that QtMobility had been > merged into Qt 5 as add-on modules. May I ask why functionality is still > being kept duplicated? Right, all of qtmobility has been split up for Qt5, as different add-on modules like QtSensors and QtMultimedia. This is about bringing qtmobility, the Qt4 version, to qt-project.org. Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Moving QtMobility to qt-project.org
Hi, I'd like to propose to move QtMobility to the qt-project.org. The main reason I am proposing this is that we (RIM + KDAB) right now have a fork of QtMobility living on Gitorious [1]. This fork contains backends for sensors and multimedia for the new BB10 mobile OS, and will likely gain support for NFC and Bluetooth as well. It contains some API additions too. In addition to BB10, the Mer project also has patches for QtMobility [2], and the Android port has a backend [3]. Lorn Potter is working on backporting sensor gestures to QtMobility [4]. As you can see, there is still interest in QtMobility. Having it on qt- project.org would potentially reduce the number of forks and patches that are around. At least we are committed to properly upstream all patches of the BB10 fork. There are multiple advantages of making qt-project.org the home for QtMobility. First of all, we'd gain a proper review process through Gerrit. The docs would live on qt-project.org as well, which is naturally the first place people look for documentation. Right now the documenation for the API additions for BB10 are hard to find, for example. In general, getting rid of a fork is almost always a good idea. Any objections to this? How can we make this happen? The first steps would be to set up Gerrit for QtMobility and make sure commits to Gerrit end up on Gitorious. After that, we'd upstream the BlackBerry backend and the new API via Gerrit and get rid of the forked repository. There is already documentation at [5]. Is that auto-generated from the Gitorious repository automatically? If so, there is nothing to do in that area, hopefully. Eventually, we'd create a new 1.3 release with the BlackBerry backend and the new API (or maybe a 2.0 release even). Any thoughts? Regards, Thomas [1] https://gitorious.org/+kdab-developers/qt-mobility/qnx-qt-mobility [2] http://gitweb.merproject.org/gitweb?p=mer-core/qt-mobility.git;a=summary [3] http://quickgit.kde.org/?p=android-qt-mobility.git [4] https://qt.gitorious.org/~lpotter/qt-mobility/lpotters-qt- mobility/commit/2fd397a87e567dad8c48e2d7c1d35050a569d160 [5] http://doc.qt.digia.com/qtmobility/index.html -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, v8 and freezing the global object
Hi, On Friday 12 October 2012 13:30:57 Thomas McGuire wrote: > I've also been thinking about adding the frozen global object to the > snapshot, but I think that will not work. Qt changes the global object, for > example by adding the qsTr() function, so freezing would have to happen > after Qt is done modifying the object. This is however not possible > because the global object then refers to the address of the C++ function > for qsTr(). That address can change on each invocation due to address > space randomization and other factors, so it is not possible to keep a > persistent snapshot. Snapshotting in v8 works because AFAIK the built-in > functions there are all pure JS. after investigating this, it turns out to not be JS all the way down. Instead, JS code can call into built-in runtime functions. These functions are static and listed in a big table. When serializing and deserializing the snapshot, references to built-in runtime functions are taken into account and encoded as an ID that is persistent across restarts. So one idea to avoid the 100ms penalty of freezing the global object is to create the v8 snapshot after we've modified the global object and frozen it. That means we need add hooks in v8 that allow extending the built-in runtime function table with the functions we add to the global object. Once that is done, creating a snapshot with the extended and frozen global object could work. Just an idea, don't know how feasible that is. Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, v8 and freezing the global object
Hi, On Thursday 11 October 2012 17:36:55 Harri Porten wrote: > On Thu, 11 Oct 2012, Thomas McGuire wrote: > > Could we maybe simple get rid of object freezing, and not freeze the > > global object? > > What would the consequences of that be, anything bad? I am the opinion > > that if the user wants to override the "console" object, let him. Maybe > > there were other reasons for freezing the global object though? > > My guesses for a possible difference: performance of script execution. > Once the global object is frozen the JIT compiler can make certain > assumptions that otherwise are not possible. Seems that in v8, the exact opposite will happen, and property lookup is actually 94% slower, according to http://jsperf.com/prototype-property-lookup-frozen Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, v8 and freezing the global object
Hi, On Friday 12 October 2012 12:16:26 aaron.kenn...@nokia.com wrote: > On 11/10/2012, at 3:04 PM, ext Thomas McGuire wrote: > > the QML engine "freezes" the global JS object. This is apparently(?) to > > prevent accidental writes to the global object. For those who don't know, > > the global object in JS provides objects and properties available in > > global scope, such as "console" (for console.log) or "qsTr". > > In addition preventing the common errors that a mutable global object > causes (try running common JS libraries and see how many of them > accidentally modify the global object because they forgot to put a "var" > somewhere), Ah, I see, I didn't know enough about JS to know that this would create a global variable/property. > a mutable global object would prevent QML from optimising any > bindings as it cannot be sure of the names in any given scope. You mean v4 optimizations? Isn't the global object last in the scope lookup, so this doesn't matter? Anyway, I can see why the global objects is frozen, I just wish there'd be some way to get rid of the 100ms penalty of this. Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML, v8 and freezing the global object
Hi, On Friday 12 October 2012 10:17:20 Jedrzej Nowacki wrote: > On Thursday 11. October 2012 16.04.04 Thomas McGuire wrote: > > Could we maybe simple get rid of object freezing, and not freeze the > > global object? > > What would the consequences of that be, anything bad? I am the opinion > > that if the user wants to override the "console" object, let him. Maybe > > there were other reasons for freezing the global object though? > Freezing global object was a language design decision. The problem was > that in QML it would be much easier accidentally add a property to the > global object then in JS. Such mistakes would be quite difficult to debug > in QML. Do you have an example of that? I'd like to see how this can happen, out of interest (and what consequences that would have). > As a side effect there is a few optimizations in declarative > engine that assume frozen global object. As far I remember they speedup > property lookup. Ah, interesting. Does anyone know where in the engine that property lookup optimization takes place? > Algorithm for freezing an object, was never benchmarked. Probably you can > optimize it. You my also try to enable v8 snapshots, if it is not enabled > on your configuration. According to our test it may increase qml boot time > about 5x. I've already enabled snapshots when testing this, and it indeed helps a lot. Pity that v8's simulator doesn't work if the pointer size for host and target is different, therefore I had to manually create a snapshot. > I do not know if it is already done but, maybe you can create a > snapshot with frozen global object, that could solve your problem. I've also been thinking about adding the frozen global object to the snapshot, but I think that will not work. Qt changes the global object, for example by adding the qsTr() function, so freezing would have to happen after Qt is done modifying the object. This is however not possible because the global object then refers to the address of the C++ function for qsTr(). That address can change on each invocation due to address space randomization and other factors, so it is not possible to keep a persistent snapshot. Snapshotting in v8 works because AFAIK the built-in functions there are all pure JS. Startup time of QQmlEngine compared to QDeclarativeEngine is slower, and the biggest contributer there is the object freezing with 100ms. Getting rid of object freezing would be the easiest to fix that. Making object freezing faster in v8 might be possible, but that requires a complete understanding of the v8 engine, which is quite complex. Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QML, v8 and freezing the global object
Hi, the QML engine "freezes" the global JS object. This is apparently(?) to prevent accidental writes to the global object. For those who don't know, the global object in JS provides objects and properties available in global scope, such as "console" (for console.log) or "qsTr". Now, it turned out that freezing the global object takes a lot of time with v8 on BB10 devices. Even in release mode, just the call to freeze the global object makes the startup time 100ms longer. v8 seems to have an implmentation of freezing that is suboptimal, see for example the benchmark at http://jsperf.com/performance-frozen-object. Note this benchmark is for iterating over properties of frozen objects, not freezing an object, though likely freezing an object would get similar benchmark results. Could we maybe simple get rid of object freezing, and not freeze the global object? What would the consequences of that be, anything bad? I am the opinion that if the user wants to override the "console" object, let him. Maybe there were other reasons for freezing the global object though? Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Integration system problems
Hi, On Tuesday 09 October 2012 13:28:01 Peter Varga wrote: > I've noticed that merging patches into QtDeclarative repository doesn't > really work, see https://codereview.qt-project.org/#change,36116 > I suppose that the problem is in the integration system. There seems to be another problem with the qtdeclarative repository: The sanity bot doesn't review patches anymore. See for example https://codereview.qt-project.org/#change,36735. I had to add the sanity bot manually to the reviewers list, but even then it doesn't actually review the patch. Is there a way to work around this? Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Thomas McGuire for Approver
Hi, On Monday 24 September 2012 20:23:02 Lorn Potter wrote: > On 04/09/12 04:43, Lorn Potter wrote: > > I would like to nominate Thomas McGuire as an Approver for Qt Project. > > > > https://codereview.qt-project.org/#q,owner:thomas.mcguire%2540kdab.com,n, > > z https://codereview.qt-project.org/#dashboard,1000762 > > > > He has done quite some work bringing the blackberry backend to QSensors, > > as well as other areas, such as fixing my long standing grievance with > > qml not calling connectNotify. :) > > It's been 15 work days since this nomination with no objections. > Welcome Thomas! > > I've adding Thomas to Approvers in Gerrit, and raised a JIRA issue to > add him there. > https://bugreports.qt-project.org/browse/QTJIRA-185 Thanks, Lorn and everyone else. Looking forward to continue improving Qt. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-messifying Qt Quick
Hi, On Monday 24 September 2012 15:50:54 Thiago Macieira wrote: > On segunda-feira, 24 de setembro de 2012 15.38.46, Thomas McGuire wrote: > > Well, in Qt5, QtQuick has been split up into libQtQml and libQtQuick, so > > it can't just be renamed back to libQtDeclarative. > > Why not? Oh, my mistake, you proposed to rename the stuff from the qtquick1 repo only, not from the qtdeclarative repo. That is fine with me and makes a lot of sense. Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-messifying Qt Quick
Hi, On Monday 24 September 2012 15:07:06 Thiago Macieira wrote: > [Related to the co-installation and hierarchy discussions] > > Through a series of well-intentioned decisions, we ended up having: > > Qt Quick 1 (Qt4)Qt Quick 1 (Qt 5) Qt > Quick 2 > QT += declarative quick1 > quick > library libQtDeclarativelibQtQuick1 > libQtQuick > include QtDeclarative/ QtQuick1/ > QtQuick > QDeclarativeXxx QDeclarativeXxx > QQuickXxx > import$prefix/imports $prefix/imports > $prefix/imports > QtQuick 1.[01] QtQuick 1.[01] QtQuick > 2.0 > Git repo qt qtquick1 > qtdeclarative > > The Git repository is a completely internal implementation detail and > irrelevant to our users. Therefore, we don't need to change anything. > > The library name is often not used directly, but I'd like to include it in > the discussion. > > All the rest of the settings are user-visible and any change is a source- > incompatible change. I'd like to propose very simply that: > > Qt Quick 1 has the same source settings in both Qt 4 and Qt 5 > > Concretely: > 1) rename the library back to libQtDeclarative Well, in Qt5, QtQuick has been split up into libQtQml and libQtQuick, so it can't just be renamed back to libQtDeclarative. Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About QML depends on opengl
Hi, On Friday 10 August 2012 10:56:27 song.7@nokia.com wrote: > >From the code, it seems that QML will depend on the opengl, but is there a > >way to remove such dependency ? > > Because our platform doesn't support opengl yet. It is not possible to remove the OpenGL dependency, the scenegraph code is quite deeply integrated into the QtQuick UI elements. What you can do is use llvmpipe + mesa to get somewhat faster software rendering. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Move math3d from QtGui to QtCore
Hi, On Wednesday 04 July 2012 20:33:03 Thiago Macieira wrote: > On quarta-feira, 4 de julho de 2012 18.27.19, Laszlo Papp wrote: > > I would like to propose to move the math3d folder with all the > > portings of course to QtCore from QtGUI in Qt5. The reason is simple: > > I have recently started to work again on QtAudio3D, and I realized > > that, I would need such things like QVector3D. Surely, an 3D audio Qt5 > > add-on should not depend on QtGui since wrapping coordinates and so > > forth are basically a core feature to me. I have already started > > writing the change, but it is unfinished yet. > > > > As far as I can tell, the codebase is almost pure core construction, > > except the toTransform(), toAffine() and so forth helper methods. > > Those would need to be ported on top of the simple moving. I do not > > expect that a very hard job. It is probably mostly historical reason > > as how that was born with OpenGL in mind (just clearly speculating > > though), but the need is now just arising for doing this more > > accessible. > > > > Please share your concerns! Thank you in advance. > > My concern is that QtCore is not a dumping ground for "everything non-GUI > that some library or app might need". We now have two discussions about > moving classes into QtCore. > > I want to see a good argument of why it should be in QtCore, as opposed to > why it shouldn't be in QtGui. 99% of the applications link to QtGui > anyway, so I'm not convinced the move would gain anything in any way. > > And you also need to tell me that the classes are generally useful, even > outside of any relation to OpenGL (which was their original goal). One place outside of OpenGL were I'd like to use the math3d classes is in QtSensors, which has a class QRotationReading to represent device rotation. Right now the rotation is represented by 3 floats as euler angles, but we'd like to add other representations such as matrix or quaternion. The math3d classes would fit quite well for that. We'd like to avoid a QtGui dependency there, and those math3d classes would fit right along QPoint, QRect etc. Long term I also think we need to watch out for QtCore becoming a dumping ground. QtCore used to be the library that contained only the essentials to get an application running. With the modularization of Qt5, it might get a different role - every non-UI class that is not worth a seperate library. If we want to avoid that, we need to think of another convenient place to add these kind of non-UI classes, currently there is nowhere else to put them. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QFuture from QtConcurrent to QtCore
Hi, On Thursday 05 July 2012 08:01:43 Thiago Macieira wrote: > On quinta-feira, 5 de julho de 2012 04.46.22, lorn.pot...@nokia.com wrote: > > On 05/07/2012, at 2:16 PM, ext Thiago Macieira wrote: > > > There are no plans to write any class to replace QFuture. However, > > > renaming > > > the class right now is close to impossible due to source-compatibility > > > requirements. > > > > What are our source compatibility requirements in regards to modules that > > came from QtMobility? Are there any at this time? Does this even matter, > > really? The blackberry guys would like to add more QSensor's. > > As far as I understand, adding new sensors does not break source or even > binary compatibility. The would break feature freeze at this time, though. There are two cases: Adding new backend implementations of sensors, which indeed does not change SC or BC, and adding new frontend classes for completely new sensor types, which adds API but does not break SC. It would be nice to get new frontend classes in, otherwise I'll just have to carry those patches to Qt 5.1 and occasionally rebase them. > All modules should be maintaining source compatibility as closely as > possible with Qt 4. I don't know how that instruction has translated to > practical terms for the formerly Mobility modules. I do know that all the > Qt Quick 1 plugins are gone, replaced with QtQuick2 plugins, so there's a > major source compatibility break there. So far the QML side of QtSensors has been the same as in QtMobility.sensor, no compatibility break there. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] "Native event" filter
Hi,
On Tuesday 26 June 2012 12:48:56 David Faure wrote:
> ... but actually neither of these was working, except for the dispatcher
> one on Windows.
> The port to QPA broke the sending of native events, in particular.
>
> So I looked further into this, and discussed it with several people at
> QtCS, and decided that not only the implementation needed fixing, the API
> too. The current API can lead to crashes if removing install event filters
> in a different order than the reverse-order-of-setting, and leads to ugly
> code (global C function, which basically requires having a singleton).
>
> In https://codereview.qt-project.org/#change,29260 I'm proposing a new API:
>
> QCoreApplication::instance()->installNativeEventFilter(obj);
>
> with obj deriving from this interface:
>
> class QAbstractNativeEventFilter
> {
>virtual bool nativeEventFilter(const QByteArray &eventType, void
> *message, long *result) = 0; };
>
> This allows to provide removeNativeEventFilter(obj) as well.
>
> I thought making the change request was enough, but I was asked to post
> here in order to get approval for the SIC change (replacing the old
> setEventFilter with the above API).
I very much support this change and hope it will get into Qt 5.0. Currently
the system is very brittle once you try to install more than one EventFilter,
as the filters are chained, and the user of the API needs to remember to call
the previous filter in the chain, or everything breaks. In addition, if one of
the filters in the chain gets deleted, there are dangling pointers and again
the whole chain is broken. Yet using EventFilters is unavoidable, for example
the Blackberry QtMultimedia backend needs it to get multimedia update events.
As this API solves all this, I'd really like to see that in Qt.
Regards,
Thomas
--
Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
