Re: [Development] QtScript vs Qml/QJsEngine ?
Hi,
Den 30. mai 2012 15:23, skrev ext Diego Iastrubni:
On Wed, May 30, 2012 at 4:11 PM, Olivier Goffart oliv...@woboq.com
mailto:oliv...@woboq.com wrote:
On Saturday 26 May 2012 12:51:23 Stephen Kelly wrote:
Hi,
There is a discussion on a kde list touching on whether there is a
replacement for QtScript in Qt 5.
http://thread.gmane.org/gmane.comp.kde.devel.kwrite/32993/focus=75079
Is the QJSEngine the start of public API providing a replacement for
QtScript?
So as an application developer, which wants to add JS scripting
capabilities to JavaScript code (so user can extend my application).
What are my options?
How can I load JS files, and call some specific functions defined
internally in those JS? I will also need to expose some API of mine to
those JS files.
(Note: I am not talking about QML at all)
The QJSEngine/Value API already supports that use case. The code would
be 99% the same as with QtScript, if you're familiar with that.
QJSEngine engine;
engine.evaluate(function add(a, b) { return a+ b; }); // contents of
some file
QJSValue addFun = engine.globalObject().property(add); // get the
function from the script
qDebug() addFun.call(QJSValueList() 1 2).toNumber();
Exposing a QObject is also similar to QtScript:
MyQObject *obj = ...;
engine.globalObject().setProperty(myQObject, engine.newQObject(obj));
engine.evaluate(myQObject.someSlot());
What's missing is the more low-level API, like QScriptContext that
Olivier mentioned. There's currently no API for exposing a plain C
callback with QJS; everything has to go through the QObject binding.
You can provide individual functions to JS by only exposing a particular
QObject wrapper function, e.g.:
engine.globalObject().setProperty(myGlobalFunction,
engine.newQObject(obj).property(someSlot));
There's currently no API for dealing with exceptions. QtScript had
uncaughtExceptionBacktrace() and friends; in QJS there is only
QJSValue::isError() as of yet. You can get error messages, stack trace
etc. by querying properties of error objects.
QJS has no debugging API or tools. V8 provides a public debugging API,
but we'd have to be very careful if QJS were to wrap that (again, to
avoid leaking back-end details).
Also worth mentioning is the quirky
QScriptEngine::setProcessEventsInterval(), which was annoying to support
with both JSC and V8 (and didn't ever work reliably even with the
original back-end, because the engine could potentially call into a
long-running C++ function, which invalidated the promise of respecting
the user-specified interval). If you need to execute potentially
long-running JavaScript, you'll need to do it from a separate thread
with QJS.
Best regards,
Kent
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtScript vs Qml/QJsEngine ?
Hi Stephen, Den 26. mai 2012 12:51, skrev ext Stephen Kelly: Hi, There is a discussion on a kde list touching on whether there is a replacement for QtScript in Qt 5. http://thread.gmane.org/gmane.comp.kde.devel.kwrite/32993/focus=75079 Is the QJSEngine the start of public API providing a replacement for QtScript? Yes, QJS will be a public API in Qt5. It's not a full-fledged replacement for QtScript, though. QJS currently provides a subset of QtScript API/features. We've been careful to avoid introducing API that leaks back-end-specific details. While QJSEngine can be used alone, the primary use case of QJS is QML integration (i.e., using QJSValue to bridge between C++ and JS). There's no plan to update QtScript to use a newer version or JavaScriptCore, or to use V8 as the back-end (because of the aforementioned implementation leaks in the API, which made it too costly/risky to maintain). The module is Done(tm). Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On QML, ownership, QObject-trees and QSharedPointer
Den 25. mai 2012 02:35, skrev ext christopher.ad...@nokia.com:
Hi,
In QtQuick 2.0 (ie, Qt 5.0), we are thinking about using property var
more often in the implementation (eg, of qobject-derived-type
properties) to avoid some of those edge-cases, and providing more
consistent (and useful) referencing semantics.
Can you say what 'var' is and why it would help?
In QtQuick 1.x, you could not define a JavaScript var-type property in a
QML item. The closest thing provided was property variant which,
internally, is a QVariant. Assigning a JavaScript object to that property
would result in it being converted to a QVariantMap. Accessing that property
from JS would result in that QVariantMap being converted back into a JS
object. You could not store a JS function reference, or any other special
JS value in a property variant property (eg, null, undefined).
In QtQuick 2.0, we deprecated property variant and added property var.
Internally, property var properties are JS values. Thus, you can store
anything created in JS, including JS function references. This allows
greater dynamicity and flexibility. Only when you access that property from
C++ (via QObject::property() or QQmlProperty::read()) will it be converted to
a QVariant (following the same conversion rules as for any other JS value to
QVariant conversion).
Also note that when you implement types on the C++ side, you can use the
QJSValue class as a property or method parameter to transfer values
between C++ and QML/JS without type/data loss. This also includes JS
functions; for example, you can assign a function to a property from QML
and call it later from C++ using QJSValue::call().
There's also QJson{Value,Object,Array} integration.
Best regards,
Kent
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Peter Varga for approver status
Hi, Den 23. mai 2012 09:02, skrev ext Simon Hausmann: Hi, I would like to nominate Peter for approver status. As part of the team in the University of Szeged he has completed the past few rebases of V8 in the qtjsbackend module, a task that is anything but easy, with a fast moving upstream and a very complex patch set on our side. Based on his contributions he has clearly shown an understanding of V8 and the way QML is using it. An understanding that I believe is deep enough for him to easily review and approve contributions. I trust him to follow the process and I trust him to review only patches he's comfortable reviewing. Seconds? :) Yes. Peter has been doing great work with preparing and testing the V8 updates, and keeping our patch set clean. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 API change coming up: QObject::connectNotify(const char *) -- connectNotify(QMetaMethod)
Hi, The const char *-based API is now gone (https://codereview.qt-project.org/#change,24426). Thanks to all who helped get the qt5 submodule porting changes through. Best regards, Kent Den 30. april 2012 14:14, skrev ext Kent Hansen: Hi all, Quick links: https://bugreports.qt-project.org/browse/QTBUG-25541 and https://codereview.qt-project.org/#change,24282 (TL;DR; skip down to IMPACT ON EXISTING connectNotify() REIMPLEMENTATIONS) Yes, it's late, but it's also one of the final nails in the const char *-based Q(Meta)Object introspection API coffin. We've had a nice template-based connect() in Qt for some time already. But the old connectNotify() hook was biased towards the original string-based connect(). To get connectNotify() to be called as expected by client code, the template-based connect() had to reconstruct the signal signature string (and prepend the darn QSIGNAL_CODE+'0' character). In Qt5, this is an even costlier operation, since the method signature is no longer stored verbatim in the QMetaObject data; it must be dynamically constructed from the name and parameter type information. Constructing a QMetaMethod, however, is very cheap; it's just a wrapper around a QMetaObject* and an index (which the QObject implementation has readily available when making/breaking connections). Once you have the QMetaMethod, you can also query all aspects of the method (such as the name, and parameter count), including its full signature (QMetaMethod::methodSignature()). The other (public) shortcoming of the const char *-based connectNotify() is that if you were comparing the signal string to something else, you had to ensure that that something else was fully normalized. Otherwise the string comparison would fail (due to an extra space character, for example). In Qt5, there is an operator== for QMetaMethods, and there is the new QMetaMethod::fromSignal() function to get a QMetaMethod that corresponds to a C++ signal function. So you can easily compare methods without resorting to fragile, raw string comparisons. This is why we're migrating away from the const char *-based API (yes, I'm also looking at you, QObject::receivers(const char *) ;-) ). IMPACT ON EXISTING connectNotify() REIMPLEMENTATIONS Existing reimplementations must be ported over to the new API in order to build with Qt5. I'm preparing patches for the places in Qt that I'm aware of. For a basic example, you can have a look at the QBuffer patch: https://codereview.qt-project.org/#change,24284. For modules like qtsystems, which has dozens of connectNotify() reimplementations and performs signal proxying, it's more involved (WIP qtsystems patch: https://codereview.qt-project.org/#change,24817). However, we are keeping support for the old API for some time (obviously it will have to be removed before Qt5.0 final), to allow places outside of qtbase to be ported incrementally. If there are places outside of the qt5 modules that need to be ported, I can help you with that. IN RELATED NEWS... In addition to the API change itself: We now call (dis)connectNotify() directly from the internal index-based QMetaObjectPrivate::(dis)connect() function. The nice thing about this is that connectNotify() reimplementations are called consistently out of the box (e.g., when you call connectSlotsByName(), or when QML connects to your signals -- and we could get rid of the hack that calls it from qtscript: https://codereview.qt-project.org/#change,24558). So the only remaining bug is that, as with the old API, disconnectNotify() is not called when the receiver is destroyed. But I'll propose a patch for fixing that (we will need to store the signal index in the internal Connection object, for fast retrieval of the QMetaMethod). Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notice: QtDeclarative compatibility module about to be removed
Hi, It's removed now. Kent Den 11. mai 2012 09:50, skrev ext Kent Hansen: Hi, See https://codereview.qt-project.org/#change,25891 In short, QT += declarative and the QtDeclarative headers/classnames will no longer work (i.e., code that use them won't compile). I went through the qt5.git submodules and ported the last stuff (hopefully) over to the QtQml names. Once those changes have been merged, I'll stage the above change. If you still have code using the old QtDeclarative headers/classnames, now would be an excellent time to port to the QtQml names. If in doubt, try running the qtdeclarative/bin/rename-qtdeclarative-symbols.sh script over your code and check the results. (Note that the script can be a bit eager, e.g. references to module-local paths like examples/declarative/foo and SUBDIRS += declarative will be replaced by examples/qml/foo and SUBDIRS += qml, which you maybe don't want -- at least not without also renaming those folders. ;) ) Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtV8: Order of arguments on Runtime::kResolvePossiblyDirectEval inconsistent
Hi Holger, Den 08. mai 2012 23:04, skrev ext Holger Hans Peter Freyther: Hi, I am looking into why QtV8 stopped working for MIPS (the obvious candidate is that there is lithium support now). While doing this I noted that in FullCodeGenerator::EmitResolvePossiblyDirectEval the following is not consistent: ARM: 1.) language_mode 2.) is_qml_mode 3.) start_position ia32, mips, amd64: 1.) language_mode 2.) start_position 3.) is_qml_mode the ResolvePossiblyDirectEval is shared across all implementations. So is the ARM code wrong? Well spotted. Looks like a regression that was introduced in the QML mode patch when we updated to V8 3.10.1. I'll make sure we have sufficient test coverage so this won't regress again. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] api_changes merged back to master
qtdeclarative/api_changes got merged, and now several others after that. qtpim, qtsensors and qtsystems still remaining (merge attempts are all in progress). Best regards, Kent Den 18. april 2012 00:29, skrev ext Donald Carr: yetch, and again, sorry Kent Were I but a beautiful woman, I would lend you a hug to give you the power to put this turkey down, once and for all. KO On Tue, Apr 17, 2012 at 8:36 PM,kent.han...@nokia.com wrote: Hi, The qtdeclarative merge (https://codereview.qt-project.org/#change,23550) still hasn't gone through; tests are crashing in the latest attempt. Modules that depend on qtdeclarative won't be able to merge any changes until the above merge is completed. Kent From: development-bounces+kent.hansen=nokia@qt-project.org [development-bounces+kent.hansen=nokia@qt-project.org] on behalf of Knoll Lars (Nokia-MP/Oslo) Sent: Tuesday, April 17, 2012 4:52 PM To: development@qt-project.org Subject: [Development] api_changes merged back to master Hi everybody, the merge of api_changes back into master for qtbase finally made it's way through the CI system. I'm currently in the process of merging declarative back and Kent is staging all the changes required to fix compilation of the other modules. From now on most changes should go to master. I'll keep api_changes around for another little while as there are still some changes in gerrit against it, but I would like to empty this queue now and then remove the api_changes branch soon. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Den 12. mars 2012 23:45, skrev ext Rohan McGovern: Richard Moore said: On 12 March 2012 17:56,kent.han...@nokia.com wrote: Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Do you have any idea of how many of these were due to QtDeclarative making assumptions that aren't part of the defined API, vs how many were changes in expected behaviour? Here's the commits which were needed: Thanks for the overview, Rohan. http://codereview.qt-project.org/18909 - 16e29f3 Remove unneeded dependencies to QtWidgets and QtOpenGL - I don't think this one resolves any test failures. It does; by switching to using QGuiApplication for those tests, we effectively sidestep a change in QApplication font loading behavior due to http://codereview.qt-project.org/#change,18621, which broke a test on Mac. http://codereview.qt-project.org/19656 - c787809 Mark presumed unstable test as insignificant. - marks tst_qquickpixmapcache as insignificant, doesn't actually resolve the problem, so the real issue may not yet be understood Yep, it's still not understood. I added a comment to the change about the symptom, but I don't know how to reproduce it. http://codereview.qt-project.org/19552 - dda130f Fix MouseArea autotest. http://codereview.qt-project.org/19534 - 6cf36b2 Fix tst_qquicktextedit. http://codereview.qt-project.org/19427 - cb1ff7a Fix double click handler in QQuickItem. - all of these were failing due to changes in double-click semantics, apparently a bug fix: commit b371f3f943703840d0dfbe30505018bcca06e260 Author: Laszlo Agocslaszlo.p.ag...@nokia.com Date: Tue Mar 6 16:09:09 2012 +0200 Fix double click handling. Yes, the mouse event handling change was the most serious source of failures. In addition, there was a change in QtNetwork last week that I reverted because it caused qtdeclarative autotests to crash. That one is being reapplied again in http://codereview.qt-project.org/#change,19591, hopefully with the crashes gone. http://codereview.qt-project.org/19598 - cbb7f8b Skip test that accesses deleted QML engine - apparently the test reads invalid memory, but doesn't actually crash on most platforms. It might be that the qtbase changes, due to changing the layout of a few things in memory, caused it to start crashing on at least one platform. It turned out that valgrind was already complaining about this on platforms where it didn't crash. Would be good if there were a CI that ran the tests through valgrind, maybe once a week or so. In the qtbase/api_changes branch, there was a change in QString::mid() (the handling of a negative position argument) that caused tst_qquicktextinput::getText to fail. It's difficult to know which type of changes can break stuff in other modules, but things like - QtCore/Gui event/timer handling - Gui text/font changes - Network changes (declarative uses networking extensively) - Changing the semantics of input arguments of public functions might be worth validating against dependent modules. By doing so we can save a lot of time we otherwise have to spend on failed CI rounds and tracking down changes that broke other modules. Regarding flaky tests: This is a nightmare right now since it makes _any_ integration so darn unpredictable. The CI takes ~1.5 hours to build qtdeclarative and run tests on all platforms. Everything might look green and dandy on the seven first machines, but then the last one gets to 99% before failing some test. Then we need to investigate whether that failure is due to a new change in e.g. qtbase, or whether it's flaky, apply some fix (e.g. mark the test as insignificant), and do a whole new round of CI. So please, be careful when adding new tests that rely on timing/event loop specifics. Due to the very nature of QtQuick (interaction tests, networking), I guess it has a higher likelyhood of having flaky tests than other modules. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Den 13. mars 2012 12:08, skrev ext Kent Hansen: It's difficult to know which type of changes can break stuff in other modules, but things like - QtCore/Gui event/timer handling - Gui text/font changes - Network changes (declarative uses networking extensively) - Changing the semantics of input arguments of public functions might be worth validating against dependent modules. Let me add - meta-type/QObject kernel changes to that list. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Hi, qtdeclarative needs to be adapted to some recent changes in qtbase. While we try to get that done (http://codereview.qt-project.org/#change,18941), staging of unrelated changes to qtdeclarative has been blocked. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Girish Ramakrishnan for Approver status
Yes, please! Welcome back, Girish! Kent Den 06. mars 2012 10:06, skrev ext lars.kn...@nokia.com: Hi, I'd like to nominate Girish for Approver status. He's been around Qt for a pretty long time, working for Trolltech a couple of years ago, then having his own consultancy company doing Qt related work and he's now back working on Qt for Nokia. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing qreal to a float
Den 15. feb. 2012 08:38, skrev ext gunnar.sle...@nokia.com: For some time we have wanted to unify the behavior of qreal on desktop and embedded. Currently, qreal is defined to be double on desktop and to a float on embedded. The reasons for unifying are: - Using double is pure waste for a lot of use cases. QRectF, QPointF, QPainter, QPolygonF, OpenGL, QMouseEvent, QTouchEvent, to name a few. None of these require the precision offered by double precision floating point. - Predictable behavior on across desktop and device. In the past we have had a few cases where things fell apart when run on embedded because the reduced precision. These were fixed, but they would have been immediately caught during development if they were the same. - For specific use cases were higher precision floats are required, double can still be used. Both inside and outside the Qt libraries. Our initial idea was to change qreal to double to avoid any potential regression but the impact on size combined with the fact that the added precision is almost never needed changed our minds (https://bugreports.qt-project.org/browse/QTBUG-23758) The only questionable use case is geolocation. We know for a fact that floats have limitations in this area and both Qt3D and QtLocation make use of QVector[2|3|4]D and QMatrix4x4 which will now be a float. However, this is no worse (for device) than it already is, so any use case that fails and needs work will now be found early in the development cycle as opposed to during device testing. Unless there are any objections that I have not yet covered, I will go ahead with this change. cheers, Gunnar Great. This would allow us to get rid of various hacks for qreal in the meta-type system as well. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Changing the return type of QMetaMethod::signature()
Hi, As part of http://codereview.qt-project.org/#change,14763 (new meta-object data format) it would be good to change the return type of QMetaMethod::signature() from const char * to QByteArray. In the new meta-data format, the raw, 0-terminated signature string is no longer stored; the signature can be constructed from the method name and parameter type info if needed. I'm hoping that most usages of signature() outside of Qt itself will already be wrapping the signature in a QByteArray/QString, since operating on the raw char pointer isn't so nice. However, if some code does do const char *sig = myMethod.signature(); // do something with sig (call strlen et al) ... that will still _compile_ if the return type of signature() is changed to QByteArray (unless your project defines QT_NO_CAST_FROM_BYTEARRAY), but the sig pointer will no longer be valid after the assignment. The typical thing we do with signatures in qtbase is print them in warnings; such code will have to be changed to pass signature().constData() instead. (Unfortunately, this case also compiles without adding .constData(), at least on gcc -- with a warning about passing a non-POD type.) qtdeclarative does use the raw signature pointer, but it does so to find the boundary between the method name and the argument types. With the new meta-data format and QMetaMethod API (name(), parameterCount(), parameterType()) that code will be adapted accordingly. In the current patch for http://codereview.qt-project.org/#change,14763, we kept the const char * return type, but at the expense of having to maintain an internal cache of signatures that will be kept alive forever, just to ensure that the pointer remains valid. I'm fine with adapting Qt itself if we change the return type, but I can't judge what the impact will be outside of Qt. Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze and Alpha
Yep. https://bugreports.qt-project.org/browse/QTBUG-24154 Kent Den 08. feb. 2012 13:40, skrev Knoll Lars (Nokia-MP/Oslo): Ok, this one makes sense to finish IMO. Can you please add a Jira task for it, and make it a subtask for 20885? Lars On 2/8/12 1:20 PM, ext Kent Hansenkent.han...@nokia.com wrote: Den 05. feb. 2012 15:12, skrev ext lars.kn...@nokia.com: Hi everybody, [...] Is there anything that I have now forgotten that really *must* be in 5.0 (i.e. it really can't be done in a BC/SC way for Qt 5.1)? If you have such an item, please speak up, otherwise I'll consider the above exception list as final. I would like to try to finish http://codereview.qt-project.org/#change,14763: Changing the meta-object data to represent type information in a more useful/efficient (less string-based) way, and then following up by removing the various codepaths we have for dealing with older meta-object revisions. Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Configuration changes for QStateMachine
Den 02. feb. 2012 14:39, skrev ext Caio Marcelo de Oliveira Filho: Hello, I didn't have time to provide a patch this week, but I would like to get this in Qt 5.0 if possible -- I'm willing to write the necessary changes and tests for it. QTBUG-9380: It would be useful if QStateMachine had a signal to notify about configuration changes https://bugreports.qt-project.org/browse/QTBUG-9380 I think the risk of adding this signal is very low. I've talked with Noam about his suggestion and we agreed that for now the signal approach (as described in the task) would be fine. What do you think? Cheers, Sounds good. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QByteArrayRef
Hi, It would be useful to have a QByteArrayRef class, similar to QStringRef -- a thin wrapper that doesn't copy the data. Did anyone implement it already? If not, I can take a stab at it. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of ActiveQt module?
Den 01. feb. 2012 09:47, skrev ext Olivier Goffart: Facts: 1) QMetaObjectBuilder is private, its API may still change from minor version to minor version That's fine. It's still better (lower maintenance) than having home-grown / incompatible generators floating around, IMO. 2) Qt maintain binary compatibility, so metaobject generated from old version of moc must still work for all the Qt 5.x series. Meaning in theory you are fine sticking with revision 7 for all the Qt 5.x time frame. Yeah, we would start from revision 7 in Qt5, but remove codepaths for revisions 7 (Qt4 meta-objects). Then if we need to bump the revision to 8 in Qt 5.x, we would have to keep revision 7 working, of course. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of ActiveQt module?
Den 01. feb. 2012 12:48, skrev ext Robin Burchell: 2012/2/1 Jedrzej Nowackijedrzej.nowa...@nokia.com: Yes, and by updating QMetaObjectBuilder we will update data generated by ActiveQt. ActiveQt would use the newest meta object version (faster tested). As (I think) was raised on Gerrit - this requires that someone take the time to make it use QMetaObjectBuilder... That's not a problem. Testing that it works is the problem. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Status of ActiveQt module?
Hi, Does anyone care about the ActiveQt module for Qt5? A problem with this module is that it doesn't have any autotests. I can run some on the examples, but I don't really know what they're supposed to do, or how to use them to exercise relevant codepaths. The main reason I'm asking is because ActiveQt has code to generate meta-objects at runtime, but the meta-object version it generates is old. For Qt5 it would be good to get rid of support for Qt4 meta-objects (revisions = 6), but this necessitates that we update existing homegrown meta-object generators to generate the latest and greatest version (will be 7 initially for Qt5). ActiveQt could be ported to use QMetaObjectBuilder to generate the meta-object, but that's a non-trivial refactoring that scares me due to the lack of autotests. Or, the ActiveQt meta-object generator could be patched to generate a newer version -- a much smaller change. But that means we have to do that every time the QtCore (moc) revision is bumped in the future (which won't be terribly often, but it's still a hassle, especially in the case of ActiveQt which looks to be ... inactive at the moment). Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Den 30. jan. 2012 06:03, skrev Rohan McGovern: As Joao mentioned, this relates to a dry run of the CI feature. I think that we need a method of requesting that some test procedure is run over your change in gerrit, without also testing some set of everyone else's changes at the same time, and without requesting that the change is actually merged into the repository at the end of the test. Definitely, being able to test a change in isolation would be required, I think; otherwise you lose the confidence in the test results again (was it me, or did that other change sneak in and break everything?). (That's not a problem specific to testing/dry runs, though; right now anyone could be the unlucky person that gets his/her change staged together with an unrelated change that breaks stuff. I don't have a good suggestion for reducing that problem; Jedrzej had the idea of limiting the number of unique commit authors per CI round to some constant N (3 or 4?).) You mentioned a button in gerrit, but what do you think of soliciting machine reviewers instead, as you currently do for humans? e.g. 1. push change to gerrit 2. go to web UI, add reviewer named something like Test : qt5.git tester : compile/test all of qt5.git with your change 3. qt5.git tester immediately adds comment I'll start testing your change in (~ some time estimate) 4. qt5.git tester later adds pass or fail comment, with a link to a build/test log. 3 could be omitted if that's perceived as too noisy. You could add multiple testers with different goals this way, and they'd operate independent from each other. That's a great idea! I'd start using it today. :-) Maybe the reviewer bots could be displayed as suggested reviewers or something to make their existence more known in the web UI. Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Suggestion for new CI: early warning for qt5.git
Hi, Sometimes there are changes to qtbase that the author and/or reviewers strongly suspect will break one or more modules on top of it (e.g. in qt5.git). For example, source-incompatible changes (removing QEventLoop::DeferredDeletion), or changes to the meta-type/QObject internals (which qtdeclarative is relying heavily on). When such a change goes into qtbase, you only get the failure for the dependent modules the next time you stage something (anything) in that other module; suddenly the module no longer builds, or tests seemingly unrelated to the developer's own change start failing. This means developers will be scratching their heads and spending time tracking down what was the actual cause of the failure (first in their own changes/module, then in the dependencies). It also means that the CI is wasting cycles on subsequent (failed) attempts to fix the failure, which is disruptive to everyone trying to stage new and unrelated changes. If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. An idea to avoid such disruption would be a CI where you can try to merge your change, and it will build all of qt5.git with it (_and_ run all the module's tests). This could be a separate button in Gerrit, for example. You then get a report in Gerrit with the status from the complete build tests run. Even if everything succeeds, the change will not actually be integrated; this would just be a tool for getting an indication of potential inter-module problems with your patch. If there are problems, the developer can then either fix the affected modules in advance if possible, or at least give a heads-up and/or prepare patches that will fix the upcoming breakage in the other modules. What do you think? Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Den 27. jan. 2012 09:20, skrev Alan Alpert: On Fri, 27 Jan 2012 18:09:46 ext Kent Hansen wrote: Hi, Sometimes there are changes to qtbase that the author and/or reviewers strongly suspect will break one or more modules on top of it (e.g. in qt5.git). For example, source-incompatible changes (removing QEventLoop::DeferredDeletion), or changes to the meta-type/QObject internals (which qtdeclarative is relying heavily on). When such a change goes into qtbase, you only get the failure for the dependent modules the next time you stage something (anything) in that other module; suddenly the module no longer builds, or tests seemingly unrelated to the developer's own change start failing. This means developers will be scratching their heads and spending time tracking down what was the actual cause of the failure (first in their own changes/module, then in the dependencies). It also means that the CI is wasting cycles on subsequent (failed) attempts to fix the failure, which is disruptive to everyone trying to stage new and unrelated changes. If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. An idea to avoid such disruption would be a CI where you can try to merge your change, and it will build all of qt5.git with it (_and_ run all the module's tests). This could be a separate button in Gerrit, for example. You then get a report in Gerrit with the status from the complete build tests run. Even if everything succeeds, the change will not actually be integrated; this would just be a tool for getting an indication of potential inter-module problems with your patch. If there are problems, the developer can then either fix the affected modules in advance if possible, or at least give a heads-up and/or prepare patches that will fix the upcoming breakage in the other modules. What do you think? How does this compare to our current best alternative, that of your building Qt 5 and running make check yourself? Do you need to have the tests run on all the platforms? Is building Qt5 + make check on your own platform too slow or difficult to be a viable alternative? Gerrit: Click a button Me: Check out qt5.git, apply my patch, build and run make check. Yes, it's slow, and a bunch of tests pop up windows that grab focus. I suppose not all platforms are needed. But Windows would be nice because apparently the latest MSVC has c++0x on by default, something we don't test with the Linux CI afaik. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Den 27. jan. 2012 14:07, skrev ext Olivier Goffart: On Friday 27 January 2012 09:09:46 Kent Hansen wrote: [...] If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. Why is that the last resort? This seems totally normal and was the whole point of modularisation: Differents modules can be developped at different speed. Actually it should be the first resort. The right thing to do is to 1) pin the qtbase sha1 in sync.profile in the modules that you know will break because of your qtbase change, and wait for that to get through CI 2) submit your change to qtbase, wait for it to get through CI 3) submit a change to the other modules that unpins the qtbase sha1 and adapts to the qtbase change That avoids any disruption to others. But it's a chore. And you get conflicts when several people try to pin/unpin the sha1 at the same time (you'd think that wouldn't happen often, but ask Simon ;) ). If not, modularisation was just a waste of time and a way to make development more difficult. It does make development more difficult. Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8's location
Den 03. jan. 2012 22:07, skrev ext lars.kn...@nokia.com: On 1/3/12 5:45 PM, ext Oswald Buddenhagenoswald.buddenha...@nokia.com wrote: On Tue, Jan 03, 2012 at 01:45:27PM -0200, ext Thiago Macieira wrote: Configure already sets a default mkspec symlink that matches the target mkspec. Making it also create a symlink for default-host which matches the host platform would be easy. The tricky part is using that. You could specify the -spec default-host option when running configure, but last I checked with Marius (or was it still Sam?), you can't add that to the .pro file because it's too late. The spec file was already loaded by the time the .pro file is parsed. So my guess is this would be a major incursion into qmake to support the feature. correct. It would probably be easier, though uglier, to add a separate file that is read by qmake when it finds the .pro file. well, technically, there is no reason why that separate file could not be the .pro file itself: #pragma spec:default-host TARGET=lrelease ... pure beauty! :D Yes, something like this would be great. Can we please get it? We could even require this to be in the first line of the pro file to make things simple. The default would obviously use the target mkspec, so we'd only need to patch a few pro files. Cheers, Lars I created https://bugreports.qt.nokia.com/browse/QTBUG-23447 and made it a blocker for the move of v8. Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtQuick becomes a separate module
Hi, See https://bugreports.qt.nokia.com/browse/QTBUG-22889 Once http://codereview.qt-project.org/#change,9948 goes through CI, QtQuick will be a separate module (AKA library). This is where all the QtQuick (2.0) types will live, and QtQuick-specific C++ APIs, like QQuickItem and scenegraph. The old headers (e.g. QtDeclarative/qquickitem.h) will continue to work for some time. But eventually, all existing code must be ported to the QtQuick module. What do _you_ have to do? If you're using QtQuick C++ APIs: 1. Update your .pro files. QT += declarative should become QT += declarative quick 2. Update your includes. #include QtDeclarative/qquickitem.h should become #include QtQuick/qquickitem.h and similarly for other QtQuick/SceneGraph classes. Additionally, qmake will take care of automagically adding QT += quick to projects that only do QT += declarative (and you'll get a warning) (http://codereview.qt-project.org/#change,9803). If you don't use the QtQuick APIs at all, you'll just have to ignore that warning until we remove the compatibility support. I've tried to ensure that existing code builds and runs without requiring immediate changes, but I wouldn't be shocked if I missed something. If you do encounter problems, please file a bug in JIRA. I'll send an update once the change has gone in. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick becomes a separate module
Den 02. des. 2011 09:59, skrev Kent Hansen: Den 02. des. 2011 09:33, skrev ext Kent Hansen: Hi, See https://bugreports.qt.nokia.com/browse/QTBUG-22889 Once http://codereview.qt-project.org/#change,9948 goes through CI, Since the commit is so huge, there's a high likelyhood of conflicts and failing tests when combined with other changes. Therefore staging of qtdeclarative changes in Gerrit has been disabled for the moment. Kent The change went through, and qtdeclarative is open for staging again. The change to automatically add QT += quick -- to allow existing Qt5/QML2-based projects outside of Qt to migrate smoothly -- is being integrated as I type this very sentence (http://codereview.qt-project.org/#change,9803). Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick becomes a separate module
Den 02. des. 2011 16:13, skrev ext Charley Bay: snip, Kent upcoming patch changes Den 02. des. 2011 09:33, skrev ext Kent Hansen: Hi, See https://bugreports.qt.nokia.com/browse/QTBUG-22889 Once http://codereview.qt-project.org/#change,9948 goes through CI, This seems like important info, so I made a page on the wiki: https://wiki.qt-project.org/Transition_from_Qt_4.x_to_Qt5 Is that wiki location the proper place for such things? Feel free to move it or correct me as needed. --charley If, as a colleague suggested, we say that the Qt5 before this change was actually Qt 4.99, that would indeed be the correct place. ;) But this change affects only those who had started to adopt Qt5/QML2. For QtQuick1 (Qt4) users, the correct change is to add QT += qtquick1 (uhm, but that might actually be renamed to quick1) to their .pro file, and then use the fixqt4headers.pl script in qtbase/bin to update the includes. By the way, the suggestion on the table was to abuse fixqt4headers to also support updating these Qt 4.99 includes (QtDeclarative/qquickitem.h = QtQuick/qquickitem.h, et al). Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] V8 updated in qtbase.git
One thing we just remembered is that we want to have v8 snapshot support when cross-compiling. So we'll have a mkv8snapshot tool that must run on the host. How can that be achieved if we move v8 out of qtbase? Currently makefiles for host tool are handled in configure, see this line: *tools/bootstrap*|*tools/moc*|*tools/rcc*|*tools/uic*|*linguist/lrelease*) SPEC=$QMAKESPEC ;; Currently, all we'd have to do is add mkv8snapshot to that. Kent Den 11. nov. 2011 08:40, skrev Hausmann Simon (Nokia-MP-Qt/Oslo): Absolutely, that dependency is fine for WebKit. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] V8 updated in qtbase.git
Hi, bcd16f9453e543ba819385d87bd7061a4caeb325 bumps the sha1 for the V8 submodule, and introduces some build changes to src/v8. You'll need to do git submodule update to be able to build libQtV8 again. Thiago, I missed the previous discussion on V8's location. Since everyone seems to agree that QtCore shouldn't depend on V8, I guess we're free to move it around again. One idea from Lars is that we move it back to qtdeclarative and build it straight into the core libQtDeclarative. The idea is to separate out the graphical parts of declarative into its own library, e.g. QtQuick(2), so that QtDeclarative (or QtQmlCore, or . . .) only contains the QML language + runtime (including JS environment and minimal C++/JS API). Simon, would that type of dependency also work for you QtWebKittens? Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
