Re: [Development] New Module for Serial Buses
On 05/29/2015 04:27 PM, Denis Shienkov wrote: So, any payload of data is in 8 bytes.. and all of input/output is carried out by messages, but not separate bytes (as in sockets/pipes/serialport). I don't know as how will look the CanDevice (derived from QIODevice), because QIODevice::read/write methods has not sense. Because, what is happens in case I want to write half (or part) of CAN message? IMHO, this is non-trivial issue to try to unify all interfaces to QIODevice.. :) QUdpSocket is also a QIODevice-derived class which does message-oriented communications :) Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML bindings for native Android controls
On 04/13/2015 03:46 PM, Nurmi J-P wrote: On 13 Apr 2015, at 14:50, Jeremy Lainé jeremy.la...@m4x.org wrote: How about just android-controls, which would become qt-android-controls if the project graduates from playground? I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. Another option is quick-android, which would become qt-quick-android. Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML bindings for native Android controls
On 04/13/2015 01:21 PM, Nurmi J-P wrote: Thanks for the ideas, keep it coming! :) We should probably follow the guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt How about just android-controls, which would become qt-android-controls if the project graduates from playground? Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
On 02/22/2015 06:57 PM, Richard Moore wrote: Slightly off-topic but related : does the Qt Company have any privileged access to Apple engineers working on Secure Transport? I would like to understand what the plans are regarding support for NPN / ALPN. No idea on that one, but I'd imagine they'll want to support http/2 in safari at some point. Well, the thing is that Safari already supports SPDY, but that did not translate into any (public?) API for NPN in Secure Tranport... Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
Hi Rich, On 02/21/2015 06:30 PM, Richard Moore wrote: Here's an outline of stuff I'd like to see get done in the Qt 5.6 time frame: * Complete removal of openssl 0.9.8 support This has been unsupported for a while and was really only retained since it is the only version apple ship on OS X (though they don't actually recommend using it). Qt 5.5 introduces the new SecureTransport backend for SSL so there's now no good reason to continue having all the ifdefs. Whilst I agree with the goal of dropping support for old / unmaintained OpenSSL versions, in the case of OS X we probably need to map out the transition in more detail - especially what policy to follow for the official binary releases. My main concern is that in Qt 5.5 the SecureTransport backend is available on OS X, but as far as I know we are still aiming for OpenSSL-based binaries. This means that a lot of users will not be exposed to this new backend at all, and then suddenly in Qt 5.6 the old backend will be completely gone, with no way to build it even from source. Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
On 02/22/2015 06:42 PM, Richard Moore wrote: On 22 February 2015 at 17:39, Jeremy Lainé jeremy.la...@m4x.org mailto:jeremy.la...@m4x.org wrote: Whilst I agree with the goal of dropping support for old / unmaintained OpenSSL versions, in the case of OS X we probably need to map out the transition in more detail - especially what policy to follow for the official binary releases. My main concern is that in Qt 5.5 the SecureTransport backend is available on OS X, but as far as I know we are still aiming for OpenSSL-based binaries. This means that a lot of users will not be exposed to this new backend at all, and then suddenly in Qt 5.6 the old backend will be completely gone, with no way to build it even from source. I think you're misunderstanding. Openssl will remain supported, just not the outdated 0.9.8 branch apple ship. Users will still be able to make use of openssl on mac they'll just have install a newer version. Does this change your concerns? I understood what you were saying, I think I just expressed my concerns poorly. When I said now way to build even from source, I meant no way to build support for OpenSSL as shipped by Apple. Anyway, my main concern is : how do we encourage OS X users to make use of the new backend, to avoid nasty surprises when it because the default backend? Slightly off-topic but related : does the Qt Company have any privileged access to Apple engineers working on Secure Transport? I would like to understand what the plans are regarding support for NPN / ALPN. Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QCONFIG_FLAGS vs defines
Hi, I am currently trying to finalize an SSL backend using SecureTransport to add SSL support for iOS and/or replace the OpenSSL backend for OSX [1]. When this backend is configured the following should get defined: QT_NO_OPENSSL QT_SECURETRANSPORT To achieve this I modifed the configure script to conditionally add these to QCONFIG_FLAGS. This works just fine for OSX, but for iOS the defines seem to be absent, resulting in a build error. What am I doing wrong? Is the behaviour of QCONFIG_FLAGS expected to be different between OSX and iOS? I see some other defines are added by like this: QMakeVar add DEFINES QT_NO_MTDEV ..which results in this -DQT_NO_MTDEV being passed directly to the compiler (which works for iOS too). Is this what I should be doing instead? Thanks, Jeremy [1] https://codereview.qt-project.org/#/c/101485/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.
On 09/06/2014 01:19 PM, Валерий Котов wrote: There is one more thing. Should we care about cross-origin resource sharing protocol? If I got it right, XMLHttpeRequset should perform OPTIONS preflight request before real cors request. Please see links below for more details: http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 Does it make sense to have separate method for OPTIONS request in QNetworkAccessManager if it is the case (like for get or post)? From the docs: * QML's XMLHttpRequest http://qt-project.org/doc/qt-5/qtqml-javascript-qmlglobalobject.html#xmlhttprequest does not enforce the same origin policy. = you don't care about cross origin requests, much less preflighting. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Update on iOS / SSL implementation
I have unfortunately had to put my work on iOS / SSL support on hold for now as: - the effort to polish my changes for production use is too big to complete on my free time - I am self employed, so I need to focus on actual paid work during working hours Nevertheless, I have followed Richard Moore's suggestion to put the work in progress up on gerrit, so here it is: https://codereview.qt-project.org/91505 If anyone wants to pick up where I left off, you are very welcome! Alternatively I am open to suggestions if anyone would care to sponsor further work on iOS / SSL support. Cheers, Jeremy On 05/30/2014 12:20 AM, Richard Moore wrote: What Jeremy has done here is fantastic. My estimate when I was previously asked how hard it was to write a new backend to the SSL support was approximately a man month given a developer who already knew the subject area. I'm extremely please that someone has been willing to make this investment in time, effort and given the nature of SSL/TLS sheer frustration. Thank you. Not having a Mac, I can't test this, but I'll have a long look over the code and see what I can do to help get this integrated. Rich. On 29 May 2014 18:26, Jeremy Lainé jeremy.la...@m4x.org mailto:jeremy.la...@m4x.org wrote: A while back I posted some proof of concept code to show what an implementation of QSslSocket might look like using Secure Transport. I have continued along these lines, and wanted to keep you updated. 1. GENERAL Apple's Secure Transport API is available both on OS X and iOS. As I do not have a iDevice, I have been developing on OS X exclusively, but making sure the methods I use are available on iOS (iOS only has a subset of OS X's capabilities). Secure Transport API: - provides close to nothing for manipulating certificates / keys = I had to write a minimal (DER-only) ASN.1 parser - only accepts certificates + keys .. in PKCS#12 form = I had some write some ASN.1 serialisation code, and a lot of PKCS#12 code (I absolutely hate that standard by now) 2. WHAT WORKS I am now getting to the point where a lot unit tests are passing. - QSslSocket works in client and in server mode - QSslCertificate works, with no external dependencies - QSslKey : ditto What still needs work: - the build system needs to be updated to allow building the SSL classes, even when OpenSSL is not found - QSslCertificate::isSelfSigned needs implementing - QSslKey : serializing to a password-protected PEM does not work yet - there is some duplicated code between the OpenSSL and Secure Transport backends - QSslConfiguration : no work done yet 3. HOW TO GET IT As previously stated, my current work has been on OS X only, not actual iOS devices. 1/ Checkout the qssl-ios branch from https://qt.gitorious.org/qt/sharkys-qtbase on a OS X machine 2/ Apply the attached patch to fix / disable some QSslSocket unit tests 3/ Build it 4/ Run some unit tests 5/ Help fix the errors :) Cheers, Jeremy PS: no unfortunately I cannot make it to the contributor summit ___ Development mailing list Development@qt-project.org mailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Update on iOS / SSL implementation
A while back I posted some proof of concept code to show what an
implementation of QSslSocket might look like using Secure Transport. I
have continued along these lines, and wanted to keep you updated.
1. GENERAL
Apple's Secure Transport API is available both on OS X and iOS. As I do
not have a iDevice, I have been developing on OS X exclusively, but
making sure the methods I use are available on iOS (iOS only has a
subset of OS X's capabilities).
Secure Transport API:
- provides close to nothing for manipulating certificates / keys = I
had to write a minimal (DER-only) ASN.1 parser
- only accepts certificates + keys .. in PKCS#12 form = I had some
write some ASN.1 serialisation code, and a lot of PKCS#12 code (I
absolutely hate that standard by now)
2. WHAT WORKS
I am now getting to the point where a lot unit tests are passing.
- QSslSocket works in client and in server mode
- QSslCertificate works, with no external dependencies
- QSslKey : ditto
What still needs work:
- the build system needs to be updated to allow building the SSL
classes, even when OpenSSL is not found
- QSslCertificate::isSelfSigned needs implementing
- QSslKey : serializing to a password-protected PEM does not work yet
- there is some duplicated code between the OpenSSL and Secure
Transport backends
- QSslConfiguration : no work done yet
3. HOW TO GET IT
As previously stated, my current work has been on OS X only, not actual
iOS devices.
1/ Checkout the qssl-ios branch from
https://qt.gitorious.org/qt/sharkys-qtbase on a OS X machine
2/ Apply the attached patch to fix / disable some QSslSocket unit tests
3/ Build it
4/ Run some unit tests
5/ Help fix the errors :)
Cheers,
Jeremy
PS: no unfortunately I cannot make it to the contributor summit
diff --git a/tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp b/tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
index baaf21e..e00cb18 100644
--- a/tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
+++ b/tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
@@ -81,6 +81,8 @@ Q_DECLARE_METATYPE(QSsl::SslProtocol)
typedef QSharedPointerQSslSocket QSslSocketPtr;
#endif
+#define OPENSSL_NO_SSL2
+
class tst_QSslSocket : public QObject
{
Q_OBJECT
@@ -262,6 +264,7 @@ void tst_QSslSocket::initTestCase_data()
QTest::addColumnint(proxyType);
QTest::newRow(WithoutProxy) false 0;
+#if 0
QTest::newRow(WithSocks5Proxy) true int(Socks5Proxy);
QTest::newRow(WithSocks5ProxyAuth) true int(Socks5Proxy | AuthBasic);
@@ -269,6 +272,7 @@ void tst_QSslSocket::initTestCase_data()
QTest::newRow(WithHttpProxyBasicAuth) true int(HttpProxy | AuthBasic);
// uncomment the line below when NTLM works
//QTest::newRow(WithHttpProxyNtlmAuth) true int(HttpProxy | AuthNtlm);
+#endif
}
void tst_QSslSocket::initTestCase()
@@ -423,6 +427,7 @@ void tst_QSslSocket::constructing()
QVERIFY(!socket.waitForDisconnected(10));
QCOMPARE(socket.protocol(), QSsl::SecureProtocols);
+#if 0
QSslConfiguration savedDefault = QSslConfiguration::defaultConfiguration();
// verify that changing the default config doesn't affect this socket
@@ -439,6 +444,7 @@ void tst_QSslSocket::constructing()
QVERIFY(QSslConfiguration::defaultConfiguration().ciphers().isEmpty());
QSslConfiguration::setDefaultConfiguration(savedDefault);
+#endif
}
void tst_QSslSocket::simpleConnect()
@@ -810,6 +816,7 @@ void tst_QSslSocket::privateKey()
void tst_QSslSocket::privateKeyOpaque()
{
+#if 0
if (!QSslSocket::supportsSsl())
return;
@@ -836,6 +843,7 @@ void tst_QSslSocket::privateKeyOpaque()
QFETCH_GLOBAL(bool, setProxy);
if (setProxy !socket-waitForEncrypted(1))
QSKIP(Skipping flaky test - See QTBUG-29941);
+#endif
}
void tst_QSslSocket::protocol()
@@ -1025,17 +1033,17 @@ protected:
if (m_interFile.isEmpty()) {
QListQSslCertificate localCert = QSslCertificate::fromPath(m_certFile);
QVERIFY(!localCert.isEmpty());
-QVERIFY(localCert.first().handle());
+QVERIFY(!localCert.first().isNull());
socket-setLocalCertificate(localCert.first());
}
else {
QListQSslCertificate localCert = QSslCertificate::fromPath(m_certFile);
QVERIFY(!localCert.isEmpty());
-QVERIFY(localCert.first().handle());
+QVERIFY(!localCert.first().isNull());
QListQSslCertificate interCert = QSslCertificate::fromPath(m_interFile);
QVERIFY(!interCert.isEmpty());
-QVERIFY(interCert.first().handle());
+QVERIFY(!interCert.first().isNull());
socket-setLocalCertificateChain(localCert + interCert);
}
@@ -1525,7 +1533,7 @@ protected:
// Only set the certificate
QListQSslCertificate localCert = QSslCertificate::fromPath(SRCDIR certs/fluke.cert);
QVERIFY(!localCert.isEmpty());
-
Re: [Development] RFC: Managing the Addition of New SSL Backends
Thanks Richard for taking the time to write up your summary, as the subject is pretty vast. On 05/03/2014 11:23 PM, Richard Moore wrote: Support for QNAM It's obvious that to be useful, a backend must allow QNAM to make SSL requests. It need not support the more advanced features such as client certs, custom CAs, custom cipher suites etc. In order to handle user exceptions, we need a way to signal the errors. This means that QSslError would be required. Another option might be to offer some pre-built UI component for this, but that has the issue that a single component would probably not be a good fit to many UIs. Who is looking into WinRT, as I'd be interested in hearing what the WinRT API offers in terms of error reporting? On the iOS / Secure Transport front, QSslError support is not going to be as detailed as the OpenSSL backend as the API offers very little detail about what went wrong establishing a secure connection. Another issue is displaying the certificate to the user. The QSslCertificate API is large, and whilst I think most backends would be able to provide most (if not all) of the facilities this is still a significant barrier. Instead, how about we allow QSslCertificate to be used as an opaque type for most apps? This could be done by providing access to the platform native (or a Qt provided) certificate dialog. This would reduce the requirements for the backend substantially. Can you explain your thinking in more detail on this point? For iOS / Secure Transport there is a clean separation between the SSL code and anything GUI related - to my knowledge there is no native dialog to handle accepting certificates. On the other hand: - you can get access to the raw DER data for the certificate (SecSecurityGetData [1]) - you can create a certificate instance from the raw DER data (SecCertificateCreateWithData [2]) I have therefore written some code to parse just enough ASN.1 to extract the certificate details: https://qt.gitorious.org/qt/sharkys-qtbase/source/ec189e6994b331e0e6662440a4a6fba3366277ec:src/network/ssl/qsslcertificate_ios.cpp Does WinRT provide access to the DER data? Simplifying the Cipher API == Currently, the QSslCipher API is pretty large. It's not simply the code in the QSslCipher class itself, but also all the stuff in the QSslConfiguration that defines the preferences. Instead, we could offer a simplified API that all backends must offer. So, for example we could have something as simple as High, Medium and Low! After all, most people (including developers) don't know the trade-offs of the different cipher suites anyway. We could also have a flag for perfect forward secrecy since that is independent of the strength. It would also be possible to have a setting like FIPS for people who care about that. I haven't looked into what iOS offers here yet. Cheers, Jeremy [1] https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCopyData [2] https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCreateWithData ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 05/01/2014 03:51 PM, Jeremy Lainé wrote: One problem I am going to run into is that Apple's API doesn't seem to provide error details when a certificate check fails (SecTrustEvaluate), so I don't think we'll get as fine-grained QSslError's as when using OpenSSL. I have however managed to implement the pattern used in the OpenSSL implementation: - start handshake - emit sslErrors if appropriate - allow ignoring the errors using ignoreSslErrors - complete handshake OK it looks as though I was overly optimistic, I just realised I was relying on some functions only available on OS X, not iOS. From what I can tell, we can't even do subject / alternative subject name validation ourselves, as SecCertificateCopyValues is not exposed on OSX. So, it looks as though we can either: - let secure transport do all the checks (name, trust chain, ..) which will result in either success or a failure, with no ability to ignore SSL errors when they occur - disable checks altogether before starting the handshake = totally insecure Bottom line: connecting to hosts with valid certificates is OK, connecting to anything else (self-signed certs, name mismatches) basically nullifies the security promise as we can't check the errors. Is it worth continuing, to at least support the happy path? Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 04/30/2014 11:42 AM, Peter Hartmann wrote: Yeah, nice work! I think it would be a good thing to get this into qtbase (should you be willing to contribute this of course); providing only a subset of the QSsl* functionality sounds perfectly fine to me... I have created a qssl-ios branch in my clone of qtbase on gitorious should you want to track the work in progress. I am progressively getting more tests to pass, though anything which requires QSslCertificate is currently broken. The bulk of the code lives here: https://qt.gitorious.org/qt/sharkys-qtbase/source/a5817fb03bf83ed2c35a5f1e43005562852f639e:src/network/ssl/qsslsocket_ios.mm One problem I am going to run into is that Apple's API doesn't seem to provide error details when a certificate check fails (SecTrustEvaluate), so I don't think we'll get as fine-grained QSslError's as when using OpenSSL. I have however managed to implement the pattern used in the OpenSSL implementation: - start handshake - emit sslErrors if appropriate - allow ignoring the errors using ignoreSslErrors - complete handshake Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 04/29/2014 02:39 PM, Sorvig Morten wrote: This aproach looks promising. If we can get basic QSslSocket working (enough for say QNAM and QWebSocket) then retiring the NSUrlConnection backend and focusing on QSslSocket is a possibility. OK I have moved my proof of concept code here: https://github.com/jlaine/qsslsocketios I provided a demo app : a very naive HTTPS client which fetches https://www.google.com and dumps it to standard out. You can run this on any OSX machine with Qt installed. I'll start looking how hard it would be to actually integrate this into qtbase. Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 04/28/2014 11:44 AM, Nichols Andy wrote: It is possible still in the packaged versions of Qt for iOS to make connections using SSL via QNetworkAccessManager as there is a backend that uses Apples crypto API, but without OpenSSL support you can’t use any of the API’s in Qt that use OpenSSL directly (like QSSLSocket). Ouch I just realised that most likely means QWebSocket on iOS does not support secure websockets! What would the best course of action be to add support for secure websockets on iOS? Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 29 Apr 2014 00:39, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 29 abr 2014, às 00:16:43, Jeremy Lainé escreveu: What would the best course of action be to add support for secure websockets on iOS? Probably to add a new QSslSocket backend that uses the Apple API. OK, I'll take a look at the QNAM code to see what amount of work we are talking about. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainership of QtNetwork
On 11/04/2013 05:13 PM, Robert Knight wrote: Thanks for your work on QtNetwork Shane! Same here, thanks a lot Shane for your work and for your patience getting QDnsLookup into shape! Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML TranslationLoader element?
Le Jul 31, 2012 à 9:34 AM, Alan Alpert a écrit : On Mon, 30 Jul 2012 19:34:23 ext Jeremy Lainé wrote: I have found QML's network transparency very handy for loading whole UIs over the network, it makes it possible for instance to have live updates to an application provided all the changes happen on the QML side. However, once internationalization comes into play, there's a catch: unless I'm mistaken there's currently no way to load Qt's .qm translations straight from QML code. Correct. Currently you need to add additional translation loading inside the C++ part of your application. I was therefore thinking of adding a TranslationLoader QML element (along the lines of FontLoader) which would have the following properties: - QUrl source: the URL to the .qm file - enumeration status (Null / Ready / Loading / Error): the loader's status Any thoughts on such an addition, or on a better API? That API looks good. Pretty simple. If the implementation is correspondingly simple, I think such a type would be a welcome addition to QtQml. All you need to do is contribute it through gerrit ;) . I have put together a simple implementation which is does the basic job, and am currently experimenting with it in one of my applications. It brought to light a couple of points: a/ what is the expected behaviour when a new value is assigned to source: uninstall the previous translator (my preference) or just add a new translator, keeping the old one? b/ if any texts have already been run through qsTr, with my current implementation they are not be re-translated upon successful loading of the translation. Is there a signal or something I can tack onto to trigger a retranslation? For now I have worked around this in my application by only loading the QML files which require translation once the TranslationLoader has finished loading (successfully or with an error). c/ I noticed that (at least in Qt 4.8) classes such as FontLoader have a special code path (protected by ifdefs) for handling local files. Should I be doing the same, I was under the impression QNetworkAccessManager already had provisions for handling local files? PS: To me, CrowdQuick looks like a completely different thing, albiet one which would greatly benefit from a type such as this. I share your opinion. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML TranslationLoader element?
On 07/31/2012 01:16 PM, lars.kn...@nokia.com wrote: You should uninstall the old one. For several translators it's better if we use either several TranslationLoader elements or have a special property taking an array of source files. I have done what you suggest, and uninstall the old translator. I have pushed a proposal to codereview: https://codereview.qt-project.org/#change,31864 The sanity bot doesn't like the .qm files (one good, one invalid) I included in my unit tests. Any suggestions, short of renaming the files to some other extension? b/ if any texts have already been run through qsTr, with my current implementation they are not be re-translated upon successful loading of the translation. Is there a signal or something I can tack onto to trigger a retranslation? For now I have worked around this in my application by only loading the QML files which require translation once the TranslationLoader has finished loading (successfully or with an error). It'll require a bit of work in in QtQml/QtQuick. Qt sends a QEvent::LanguageChange to all top level windows when a translation gets loaded or removed. So you'll need to add a hook listening for the event in QQuickWindow. OK that sounds like a different change, this behaviour would make sense whether you're installing your translations from QML or from C++. c/ I noticed that (at least in Qt 4.8) classes such as FontLoader have a special code path (protected by ifdefs) for handling local files. Should I be doing the same, I was under the impression QNetworkAccessManager already had provisions for handling local files? I think the special code path is there for performance reasons. I'd go through QNAM for now, and once that's properly implemented check whether optimising for local files is worth it. OK, I send all requests through QNAM for now. One other thought came to mind: a typical use case will be that the user wants to load such or such .qm file depending on the current locale. Unfortunately I don't think QLocale is accessible from QML. Would a constant localeName property make sense in TranslationLoader? Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QML TranslationLoader element?
I have found QML's network transparency very handy for loading whole UIs over the network, it makes it possible for instance to have live updates to an application provided all the changes happen on the QML side. However, once internationalization comes into play, there's a catch: unless I'm mistaken there's currently no way to load Qt's .qm translations straight from QML code. I was therefore thinking of adding a TranslationLoader QML element (along the lines of FontLoader) which would have the following properties: - QUrl source: the URL to the .qm file - enumeration status (Null / Ready / Loading / Error): the loader's status Any thoughts on such an addition, or on a better API? Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
- finalise the class name (I think QDns was suggested) Could we get this point settled once and for all? My suggestions: - QDnsLookup (my preferred one, as the object represents a lookup and its result) - QDnsInfo (similar to QHostInfo) - QDns Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QHttp removal
Le Jan 4, 2012 à 11:47 AM, Peter Hartmann a écrit : On 01/03/2012 01:07 PM, ext Thiago Macieira wrote: On Tuesday, 3 de January de 2012 09.53.41, Jonas M. Gastal wrote: As for removing them entirely yes, it would require changes in the HTTP socket engine and QAuthenticator. But given that both of them use QHttpResponseHeader I see no reason to duplicate the code in both classes, perphaps it would be preferable to simply strip the not used functionality from the existing QHttpResponseHeader class? I'm pretty sure that the functionality exists in QNetworkRequestPrivate plus the feeding of line by line, found in the QNAM's HTTP engine. We don't need to keep even the QHttpResponseHeader class. I also think the only reason for the old header classes from QHttp to still exist is that it is used inside QtNetwork, ideally we want to get rid of them altogether and have only one code path for the header files (i.e. the one in QNAM)... If it's possible I would really appreciate having a publicly-available class for incrementally parsing HTTP requests or responses (with or without the initial line). The use case I have is a Qt-based HTTP-server, but there are probably others.. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 01/05/2012 01:47 AM, Thiago Macieira wrote: On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote: This could be perceived as creating a race condition. You'd have to connect a slot to the signal on the object returned, but what if the signal is emitted before you get a chance to do that? It cannot happen if you make it, by design, not possible. That means the reply object must ensure that it never processes replies before first returning to the user. If a result was found cached (if ever there's a cache), then we need to be able to tell the user that the reply has already finished. As you stated, the reply object lives in the calling thread, and the finished() signal is always emitted in a queued fashion, so I think we're OK. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 01/05/2012 01:03 AM, craig.sc...@csiro.au wrote: Some notes about the implementation: - the actual lookup code is run in a thread, managed by a global threadpool (QHostInfo-style) What happens if the client/user is also employing their own thread pool? Does your implementation simply set some arbitrary number of threads it will use and assume the system will take care of scheduling threads fairly (probably the only safe option)? Are you making use of QThread::idealThreadCount(), in which case it probably won't give the behaviour expected with the client/user also employing their own separate thread pool? Just wondering if using a thread pool here is really buying you anything over simply using QThread directly (but I guess if you are trying to manage supporting a large number of DNS queries then it makes sense to limit how many can be processed at once via a thread pool). I followed QHostInfo's pattern exactly here: I set a fixed maximum number of threads (5) on the pool. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
Le Nov 9, 2011 à 10:14 AM, André Somers a écrit : On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé jeremy.la...@m4x.org wrote: On 11/08/2011 10:57 PM, Thiago Macieira wrote: On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote: - the QNAM-style API seems to be OK Correct, but all functions in QDnsResolver are static. That means they could go into QDnsReply and we could rename the class simply QDns. It worked for Qt 3... The methods are not static, the QDnsResolver instance initially owns all QDnsReply objects it returns. It also owns the QThreadPool used to perform the lookups. Initially? What does that mean exactly? When does QDnsResolver stops owning the QDnsReply objects? It means you can use QDnsReply::setParent() to take over ownership of the reply (like QNetworkReply). - I have implemented QDnsReply::abort() to cancel a lookup request Good. I forgot to mention: you can delete the QDnsReply at any time, as both QDnsReply and QDnsResolverRunnable access QDnsReplyPrivate via a QSharedPointer. In that case, wouldn't it make more sense then to return a QDnsReply (so not a pointer)? Hmmm... but that is of course not possible because it derives from QObject, right? Correct, QDnsReply has both an abort() slot and a finished() signal. - Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have an opinion on this? No need if all functions are static. And since they are not? As I argued before: I think they should be, as the class you showed up contains no actual data (from the user's perspective of it, anyway). It causes problems with having to keep the instance alive while the DNS request is running, even though the object itself can not really be interacted with anymore. It doesn't even provide API to know if it can be savely deleted, or if it is still in the background managing running requests. So, when can the API user savely get rid of the requester object? IMHO, it would make sense to have the methods on QDnsResolver be static, and let those static methods reference some private (singleton?) instance of the object that owns stuff like a threadpool and the QDnsReplies. That frees the user from having to care about the lifetime of the resolver object. Currently, QDnsResolver can be deleted at any time without fear of a crash. However if there are outstanding requests, this will block until the QThreadPool has finished. I agree that it looks as though QDnsResolver methods should be static, although it does once again raise the question of QDnsReply ownership since the replies can no longer be owned by the QDnsResolver. However, I am unsure about putting the methods in QDnsReply (even if it gets renamed to just QDns), I don't find it very descriptive in terms of API. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/09/2011 07:41 PM, Giuseppe D'Angelo wrote: On 9 November 2011 18:35, Jeremy Lainéjeremy.la...@m4x.org wrote: C/ you make QDnsReply's constructor public, and let the user manage the lifetime of the object. This is what the Q3Dns API looks like. What I don't like about Q3Dns's API is that it's unclear when the request is actually made. It starts after you return to the event loop, just like all the other socket classes What I mean is that the Q3Dns has setters as well as a constructor with arguments, so for instance: Q3Dns *dns = new Q3Dns; dns-setLabel(foodomain.org);// will a request be triggered if I stop here and don't specify the record type? dns-setRecordType(Q3Dns::); .. later .. dns-setLabel(bardomain.org); // will a new request be issued, since I changed the queried domain? What happens to the existing results? Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/04/2011 09:37 PM, Thiago Macieira wrote: On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote: Me too. My point was, that we have slightly different patters for basically the same sort of thing in different places in Qt. QFuture is currently coupled with QtConcurrent, but is there a strong reason why is must be? I was not privy to that IRC chat, perhaps you could tell us the reasoning why it would not be possible? There's no reason why it has to be coupled with Concurrent. Or, to put in other words, it could be changed to work without Concurrent. However, the problem is, it is currently too tightly coupled with QtConcurrent. Unless someone is volunteering to do this work right now... OK so to sum up: - the QNAM-style API seems to be OK - I have implemented QDnsReply::abort() to cancel a lookup request - Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have an opinion on this? - concerning QDnsReply ownership: * using QSharedPointerQDnsReply doesn't really help, it breaks QNAM expectations by making the user needs to hold an explicit reference to the reply * QFuture would be interesting, but it won't be split from QtConcurrent in the foreseable future * as a fallback I propose we stick with the same reply ownership model as QNAM (i.e. the reply is initially owned by the QDnsResolver, but the user can use setParent), it has the advantage of being well-known Unless there are any objections I will push the reworked QDnsResolver to gerrit. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
Le Nov 4, 2011 à 11:05 AM, Thiago Macieira a écrit : On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote: I am happy with having one QDnsReply class; I think we can get pretty far with some special accessors for SRV and other records, and one generic accessor for simple (QString) and unsupported cases. Then whoever wants to read a currently unsupported response format needs to parse the response string himself, which IMO is not that bad. We can then in the future extend the class with more special accessors if need be. There's no way to provide the unsupported formats in QString. It would need to be QByteArray and, even then, it's useless if it contains a compressed domain name. Domain name expansion is handled for known fields, win32 does it itself as far as I know, and for unix I call dn_expand. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/04/2011 11:47 AM, Peter Hartmann wrote: Btw. I think we need the generic accessor anyway because you never know what the format of a TXT response looks like. Q3Dns allowed that only for TXT records, but IMO it would be better to always have an accessor to the raw response data, or at least if the query type is unknown. Access to the raw response data for arbitrary records is not going to work in a cross-platform way. For instance, on Windows the result has already been digested for you and put into a suitable structure depending on the record type: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682082%28v=vs.85%29.aspx Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/04/2011 09:01 PM, Andre Somers wrote:
Op 4-11-2011 20:31, Jeremy Lainé schreef:
On 11/04/2011 10:15 AM, André Somers wrote:
The more I think about it, the more I think it is important to fix this:
who is
responsible for the lifetime of the QDnsReply object?
Why not have the same pattern as QNAM for consistency?
How about fixing QNAM to solve this issue there as well then?
This API does not make that clear. I like the pattern in itself (also in
QNAM), but I do
think it would be an improvement if we were to use a shared pointer to the
reply object.
That at least makes clear who has ownership of the object, and prevents
memory leaks
when people don't realize they are supposed to delete the object.
I'm not sure I understand how using a QSharedPointer would clarify the API,
it would lead
to code like this:
void someObject::someMethod()
{
QSharedPointerQDnsReply reply = someResolver-lookupService(X, Y,
Z);
connect(reply.data(), SIGNAL(finished()),
this, SLOT(replyFinished()));
}
= surprise, the reply has been deleted!
Has it? Probably not, as the lookup service is still holding on to
another shared pointer to it in order to know where to put the results
of the lookup, right? Using a shared pointer, at least you are sure the
object is valid while either the receiver or the resolver is still
interested in having the object around, and as soon as that is no longer
the case, it will be properly deleted. Using raw pointers, you can not
be sure of either.
Let's say that another shared pointer is indeed held by the resolver class, at
what point
should we let go of this shared pointer? The answer is probably at some point
after the
finished() signal is emitted, but when exactly?
dreaming
Would be nice by the way if connect could directly deal with QObjects in
shared pointers...
/dreaming
Yep, otherwise we're going to have some confused users!
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
