Re: [Interest] Enabling OpenSSL on a shared build of Qt
> -Original Message- > From: Nuno Santos [mailto:nunosan...@imaginando.pt] > Sent: Wednesday, March 02, 2016 5:22 PM > To: Koehne Kai > Cc: interest > Subject: Re: [Interest] Enabling OpenSSL on a shared build of Qt > > I think I have missed something. If it has support enabled by default why > can’t he find openssl on my system? I’m on Mac OSX 10.11.2 and I there > are this crypto and ssl libs available: > > /opt/local/lib/libcrypto.dylib > /usr/lib/libcrypto.dylib > > /opt/local/lib/libssl.dylib > /usr/lib/libssl.dylib > > Are they incompatible? Ah, I missed to that you're talking about OS X. There the system OpenSSL version should work - though it's very old (0.9.8y IIRC). You get these warnings though because Qt checks for newer API. It's a runtime warning though, basic SSL should still work. > I would compile Qt if needed I just want to see if I can avoid it. If you do so, consider configuring with -securetransport. This let QtNetwork use Apples Secure Transport library, instead of the deprecated OpenSSL one. Regards Kai ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
> > Ah you mean by "knowing types at compile time" is actually defined > types, so you actually defining classes at run-time? > Sina, > No, I didn't mean that. You can't define classes at runtime as C++ is not > a dynamic language. > Yeah, but sometimes qt makes me confuse, reflection was also not possible with C++ but it is with qt :). > I had an issue similar to your own - I wanted to write an object to a byte > array, send it through the network, and then recreate the object at the > other end. So one option is to have a factory class that know every > possible object that can be send, writes a number or a string, then the > object writes its data; send it through the network and at the other end - > read the number/string, create the object and then call the function on > that object (typically a virtual one) that reads the object's data. The > thing is, for me this whole write-send-read thing is in a dynamic library > and the classes that are serialized/deserialized are defined in the user > application, so the library doesn't know in advance what possible classes > the user might have defined, only that they have a common ancestor. So > instead of making my own registration, I used Qt's QMetaType class. > Our cases are actually almost same, maybe the only the difference is my objects are QObject-derived but this issue was already solved on early of this thread. > > Long story short: > When I have to serialize the object, I'm retrieving the appropriate > QMetaObject, getting the class name from it and then I'm using > QMetaType::type to retrieve the corresponding meta-type id. This integer I > write in the byte stream, and then, I'm calling the object's virtual > serialize method with the byte array (so it can write its data). > On the other end I'm reading the integer, checking if this meta-type id is > registered with QMetaType::isRegistered and then I'm using > QMetaType::create with said meta-type id to create the correct instance. > I'm casting the void * that the creation method returns to a base class > pointer and calling the virtual deserialize method (so the object can read > it's data). > > Here's a thread I started in the Qt forum some time ago, which could be > useful if you decide to have your objects marshaled in a similar manner: > https://forum.qt.io/topic/64277/meta-type-id-of-an-object > But I thank for you to writing, I guess at that point I have enough material to overcome this! I will study on this thread. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
On quarta-feira, 2 de março de 2016 15:29:16 PST Thiago Macieira wrote: > A better solution: copy the two libraries to your application's > /Contents/Frameworks Oh, I should point out: if you do this, you'll be distributing cryptographic code. If your application is not open source, you may need to obtain export licences in certain jurisdictions. Now you know why Qt doesn't come with or link to the OpenSSL libraries. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
On quarta-feira, 2 de março de 2016 23:15:09 PST Nuno Santos wrote: > cat out | grep ssl > loaded library "/usr/lib/libssl.dylib" > qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback > qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method > qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method > qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method > qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method > qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto > qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb > qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated > qt.network.ssl: QSslSocket: cannot call unresolved function > SSL_get0_next_proto_negotiated qt.network.ssl: QSslSocket: cannot call > unresolved function SSL_get0_next_proto_negotiated > > Can’t find anything that can help. > > If it is trying to load older libs what should be my call here? Delete old > libs and get new ones? A solution: set DYLD_LIBRARY_PATH to /usr/local/lib A better solution: copy the two libraries to your application's /Contents/Frameworks -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
On quinta-feira, 3 de março de 2016 00:08:38 PST Jason H wrote: > > Another idea: why don't you use QTemporaryFile? > > Thought about it. It takes a template specification which does not allow me > to specify the exact filename. "If the templateName does not contain XX > it will automatically be appended and used as the dynamic portion of the > filename." Why do you need a specific name? What happens if another application needs that same name at the same time? Will you delete the other application's file? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
Thiago, I have run with QT_DEBUG_PLUGINS=1 and redirected stderr to out and “greped” with ssl: cat out | grep ssl loaded library "/usr/lib/libssl.dylib" qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated Can’t find anything that can help. If it is trying to load older libs what should be my call here? Delete old libs and get new ones? Thx Nuno > On 02 Mar 2016, at 19:23, Thiago Macieira wrote: > > On quarta-feira, 2 de março de 2016 19:05:36 PST you wrote: >> Thiago, >> >> I have it in several places, but below are the most system wide: >> >> /opt/local/lib/libssl.1.0.0.dylib >> /opt/local/lib/libssl.a >> /opt/local/lib/libssl.dylib >> /opt/local/lib/pkgconfig/libssl.pc >> /usr/lib/libssl.0.9.7.dylib >> /usr/lib/libssl.0.9.8.dylib >> /usr/lib/libssl.dylib > > It's possible Qt found that 0.9.7 first and it's insufficient. Please rerun > with > QT_DEBUG_PLUGINS=1 and post the log. > >> I’m trying this: >> >> LIBS += -L/usr/lib -lssl -lcrypto -lz > > Don't do this. Don't link to libraries unless you're explicitly calling them, > directly. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
> Another idea: why don't you use QTemporaryFile? Thought about it. It takes a template specification which does not allow me to specify the exact filename. "If the templateName does not contain XX it will automatically be appended and used as the dynamic portion of the filename." ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Minimum required OS X SDK for Qt 5.6?
On quarta-feira, 2 de março de 2016 20:20:32 PST NoRulez wrote: > Hello, > > what is the minimum required Mac OS X SDK? Latest. There's no point in using any SDK but the latest. You can compile applications (and Qt itself) to target older OSes, even with the latest SDK. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
On quarta-feira, 2 de março de 2016 09:53:46 PST Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 17:45:15 PST Jason H wrote: > > Let me expand on this, I can f->setParent(reply), but I also need to > > delete > > the file from disk. If I rely on the parent/child object deletion, I can't > > get a change to delete the file. > > If you're on Unix, you can delete the file while it's still open. The file > will disappear from the directory listing immediately and the contents will > be discarded once the last open file descriptor closes. Another idea: why don't you use QTemporaryFile? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Minimum required OS X SDK for Qt 5.6?
> Am 02.03.2016 um 20:20 schrieb NoRulez : > > Hello, > > what is the minimum required Mac OS X SDK? > I tried it with MacOSX10.8.sdk and C++11 enabled but it fails with (I > think that C++11 is not fully supported in 10.8): Just to clarify: you need to distinguish between "(Minimum) BUILD SDK" and "Minimum DEPLOYMENT Target". See here: http://lists.qt-project.org/pipermail/interest/2014-October/013718.html QMAKE_MAC_SDK and QMAKE_MACOSX_DEPLOYMENT_TARGET is what you're after. Usually you want to build against the latest SDK (e.g. "macosx10.11"). Setting the Deployment Target to a lower value (e.g. "10.8") will "weak-link" any symbols which were not available on that target. Off course if you want to use features of a later SDK you need to dynamically check for their existence. (I am not an Xcode/Cocoa/ObjC expert, so not 100% sure about the "weak-linking part" - but as long as you don't use Cocoa directly, but Qt exclusively, you don't need to bother anyway: Qt does it all for you, down to the lowest supported OS X). Not sure about C++11 support (in case that's the problem here anyway), but according to http://blog.michael.kuron-germany.de/2013/02/using-c11-on-mac-os-x-10-8/ it should be supported since OS X 10.7. Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
> You can either use QMetaType for that or your own registration/factory. Thiago, Yes, that's exactly true. I just decided to use QMetaType, as Qt already provides the registration/creation infrastructure, instead of pushing a factory object to the library that will create the instances (or using my own implementation of runtime registration). My intention was not, however, to hijack Sina's thread, so I'll stop with that here. > Ah you mean by "knowing types at compile time" is actually defined types, so you actually defining classes at run-time? Sina, No, I didn't mean that. You can't define classes at runtime as C++ is not a dynamic language. I had an issue similar to your own - I wanted to write an object to a byte array, send it through the network, and then recreate the object at the other end. So one option is to have a factory class that know every possible object that can be send, writes a number or a string, then the object writes its data; send it through the network and at the other end - read the number/string, create the object and then call the function on that object (typically a virtual one) that reads the object's data. The thing is, for me this whole write-send-read thing is in a dynamic library and the classes that are serialized/deserialized are defined in the user application, so the library doesn't know in advance what possible classes the user might have defined, only that they have a common ancestor. So instead of making my own registration, I used Qt's QMetaType class. Long story short: When I have to serialize the object, I'm retrieving the appropriate QMetaObject, getting the class name from it and then I'm using QMetaType::type to retrieve the corresponding meta-type id. This integer I write in the byte stream, and then, I'm calling the object's virtual serialize method with the byte array (so it can write its data). On the other end I'm reading the integer, checking if this meta-type id is registered with QMetaType::isRegistered and then I'm using QMetaType::create with said meta-type id to create the correct instance. I'm casting the void * that the creation method returns to a base class pointer and calling the virtual deserialize method (so the object can read it's data). Here's a thread I started in the Qt forum some time ago, which could be useful if you decide to have your objects marshaled in a similar manner: https://forum.qt.io/topic/64277/meta-type-id-of-an-object I hope that helps. Kind regards. On Wed, Mar 2, 2016 at 5:51 PM, Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 13:04:35 PST Nye wrote: > > I just meant that in my case the classes are defined in the user > > application, so the library has no notion whatsoever what classes it has > > available to create instances from and it depends on the meta-type system > > exclusively for that (while still handling the > > serialization/deserialization of said instances). It just makes a factory > > inapplicable in my case (at least if you're not counting the meta-type > > system as a factory). > > You don't know the list when you write the code, but you do know the list > at > runtime. The full set of classes that can be instantiated needs to be > registered with a central authority. > > You can either use QMetaType for that or your own registration/factory. > > But it needs to be done. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Background Uploads in Android
Looks like you have to create and launch in Java that will take over uploading your file in the background when Android feels like it. Job Schedule API may be your best way out. No more worrying about ApplicationSuspended, Job Api is independent of that. Bad thing is that you have to write some java. Cheers, md On 3/2/2016 1:56 PM, Jason H wrote: So there seems to be some conflicting information out there about how to do this in Qt. It seems that in 5.3, because the Qt thread as not the UI thread, everything worked. then in 5.4, that stopped working? This was supposed to be fixed in 5.5? Anyhow, I'm working with 5.6 now. I have enough of a platform shim in place that I I wrote a bunch of code that assumed that I'd be running any time. I've successfully locked the CPU awake and detected foreground/background switches, but it seems that once I get to Qt::ApplicationState(ApplicationSuspended) my app is unable to do anything. Any help? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Background Uploads in Android
So there seems to be some conflicting information out there about how to do this in Qt. It seems that in 5.3, because the Qt thread as not the UI thread, everything worked. then in 5.4, that stopped working? This was supposed to be fixed in 5.5? Anyhow, I'm working with 5.6 now. I have enough of a platform shim in place that I I wrote a bunch of code that assumed that I'd be running any time. I've successfully locked the CPU awake and detected foreground/background switches, but it seems that once I get to Qt::ApplicationState(ApplicationSuspended) my app is unable to do anything. Any help? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Minimum required OS X SDK for Qt 5.6?
Hello,
what is the minimum required Mac OS X SDK?
I tried it with MacOSX10.8.sdk and C++11 enabled but it fails with (I
think that C++11 is not fully supported in 10.8):
In file included from
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/QString:1:
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:756:55: error:
no type named 'u16string' in namespace 'std'
static inline QString fromStdU16String(const std::u16string &s);
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:757:17: error:
no type named 'u16string' in namespace 'std'
inline std::u16string toStdU16String() const;
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:758:55: error:
no type named 'u32string' in namespace 'std'
static inline QString fromStdU32String(const std::u32string &s);
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:759:17: error:
no type named 'u32string' in namespace 'std'
inline std::u32string toStdU32String() const;
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1319:53:
error: no type named 'u16string' in namespace 'std'
inline QString QString::fromStdU16String(const std::u16string &s)
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1322:13:
error: no type named 'u16string' in namespace 'std'
inline std::u16string QString::toStdU16String() const
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1323:15:
error: no member named 'u16string' in namespace 'std'
{ return std::u16string(reinterpret_cast(utf16()),
length()); }
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1325:53:
error: no type named 'u32string' in namespace 'std'
inline QString QString::fromStdU32String(const std::u32string &s)
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1328:13:
error: no type named 'u32string' in namespace 'std'
inline std::u32string QString::toStdU32String() const
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1330:10:
error: no member named 'u32string' in namespace 'std'
std::u32string u32str(length(), char32_t(0));
~^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1331:75:
error: use of undeclared identifier 'u32str'
int len = toUcs4_helper(d->data(), length(),
reinterpret_cast(&u32str[0]));
^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1332:5: error:
use of undeclared identifier 'u32str'
u32str.resize(len);
^
/opt/Qt/5.6/clang_64/lib/QtCore.framework/Headers/qstring.h:1333:12:
error: use of undeclared identifier 'u32str'
return u32str;
^
13 errors generated.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
And yet another idea (untested), using C++11 lambdas :
QFile *f = new QFile(filename);
f->open(QIODevice::ReadOnly);
QNetworkReply* reply = nam.post(req, f);
connect(reply, &QNetworkReply::finished, f, [=f]() {
f->close();
f->remove();
delete f; // or f->deleteLater()
});
Julien Cugnière
2016-03-02 19:19 GMT+01:00 Elvis Stansvik :
>
> 2016-03-02 18:56 GMT+01:00 Jason H :
> > Indeed it is, there's a couple ways to skin this cat.
>
> Another idea, after looking at the API: You could perhaps transport
> your QFile* pointer in a user attribute of the request, e.g. something
> like (untested):
>
> int CoolFileAttribute = QNetworkRequest::User;
>
> // Sending the request, attaching the QFile* pointer to it.
> QFile *f = new QFile(filename);
> f->open(QIODevice::ReadOnly)
> ...
> req.setAttribute(CoolFileAttribute, QVariant::fromValue(f));
> nam.post(req, f);
>
> // And in your slot handling the reply, get the attribute from the
> corresponding request.
> QFile *f = reply->request().attribute(CoolFileAttribute).value();
> f->remove();
> f->close();
> delete f;
>
> With obviously some improved naming / error handling.
>
> Elvis
>
> > What I settled on (so far) is since I'm using setParent(), isto iterate over
> > the children and just QFile::remove() anything that can be cast as a QFile*.
> > It eliminates maintaining an additional mapping. it seems that this idea of
> > having a file that is to be deleted on request does not exist, except for
> > QTemporaryFile which you can't explitily state the filename.
> >
> >> Let me expand on this, I can f->setParent(reply), but I also need to
> >> delete the file from disk. If I rely on the parent/child object deletion, I
> >> can't get a change to delete the file.
> >>
> >> > QFile *f = new QFile(filename);
> >> > f->open(QIODevice::ReadOnly)
> >> > ...
> >> > nam.post(req, f);
> >> > ...
> >> >
> >> > // sometime later in the finished slot:
> >> > finished(QNetworkReply *reply) {
> >> >
> >> > // how to close and delete f ? (The QFile object)
> >
> > Save the pointer somewhere when you create it, then use the saved pointer to
> > close/delete it?
> >
> > I guess you would need to store it indexed by the request, so that you know
> > which file to close/delete in your slot.
> >
> > Take my advice with some grain of salt, as I haven't used QNAM before. But
> > it sounds like a general resource management problem.
> >
> > Cheers,
> > Elvis
> >
> >
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
2016-03-02 18:56 GMT+01:00 Jason H :
> Indeed it is, there's a couple ways to skin this cat.
Another idea, after looking at the API: You could perhaps transport
your QFile* pointer in a user attribute of the request, e.g. something
like (untested):
int CoolFileAttribute = QNetworkRequest::User;
// Sending the request, attaching the QFile* pointer to it.
QFile *f = new QFile(filename);
f->open(QIODevice::ReadOnly)
...
req.setAttribute(CoolFileAttribute, QVariant::fromValue(f));
nam.post(req, f);
// And in your slot handling the reply, get the attribute from the
corresponding request.
QFile *f = reply->request().attribute(CoolFileAttribute).value();
f->remove();
f->close();
delete f;
With obviously some improved naming / error handling.
Elvis
> What I settled on (so far) is since I'm using setParent(), isto iterate over
> the children and just QFile::remove() anything that can be cast as a QFile*.
> It eliminates maintaining an additional mapping. it seems that this idea of
> having a file that is to be deleted on request does not exist, except for
> QTemporaryFile which you can't explitily state the filename.
>
>> Let me expand on this, I can f->setParent(reply), but I also need to
>> delete the file from disk. If I rely on the parent/child object deletion, I
>> can't get a change to delete the file.
>>
>> > QFile *f = new QFile(filename);
>> > f->open(QIODevice::ReadOnly)
>> > ...
>> > nam.post(req, f);
>> > ...
>> >
>> > // sometime later in the finished slot:
>> > finished(QNetworkReply *reply) {
>> >
>> > // how to close and delete f ? (The QFile object)
>
> Save the pointer somewhere when you create it, then use the saved pointer to
> close/delete it?
>
> I guess you would need to store it indexed by the request, so that you know
> which file to close/delete in your slot.
>
> Take my advice with some grain of salt, as I haven't used QNAM before. But
> it sounds like a general resource management problem.
>
> Cheers,
> Elvis
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
On quarta-feira, 2 de março de 2016 17:45:15 PST Jason H wrote: > Let me expand on this, I can f->setParent(reply), but I also need to delete > the file from disk. If I rely on the parent/child object deletion, I can't > get a change to delete the file. If you're on Unix, you can delete the file while it's still open. The file will disappear from the directory listing immediately and the contents will be discarded once the last open file descriptor closes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
On quarta-feira, 2 de março de 2016 15:37:41 PST Nuno Santos wrote: > Hi, > > I’m using Qt 5.5.1 clang_64 prebuilt package and it doesn’t seem to have > OpenSSL support built in as I’m receiving this output. That output indicates that it *does* have OpenSSL support built-in. It wouldn't be looking for OpenSSL symbols if OpenSSL hadn't been supported. > From documentation I see that OpenSSL is enabled by default however it > doesn’t seem to able to find it. Correct, it seems to be failing to find it at runtime. Where is it in your system? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
On quarta-feira, 2 de março de 2016 13:04:35 PST Nye wrote: > I just meant that in my case the classes are defined in the user > application, so the library has no notion whatsoever what classes it has > available to create instances from and it depends on the meta-type system > exclusively for that (while still handling the > serialization/deserialization of said instances). It just makes a factory > inapplicable in my case (at least if you're not counting the meta-type > system as a factory). You don't know the list when you write the code, but you do know the list at runtime. The full set of classes that can be instantiated needs to be registered with a central authority. You can either use QMetaType for that or your own registration/factory. But it needs to be done. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Obtain the QNAM in use in a QML app?
> On 02 Mar 2016, at 16:49, Jason H wrote: > > Is there a static/singleton QNetworkAccessManager that I can get in a Qt app > rather than creating my own? http://doc.qt.io/qt-5/qqmlengine.html#networkAccessManager -- J-P Nurmi ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
Let me expand on this, I can f->setParent(reply), but I also need to delete the
file from disk. If I rely on the parent/child object deletion, I can't get a
change to delete the file.
> QFile *f = new QFile(filename);
> f->open(QIODevice::ReadOnly)
> ...
> nam.post(req, f);
> ...
>
> // sometime later in the finished slot:
> finished(QNetworkReply *reply) {
>
> // how to close and delete f ? (The QFile object)
>
> }
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Deleting the QNetworkAccessManager post(req, iodev) QIODevice?
QFile *f = new QFile(filename);
f->open(QIODevice::ReadOnly)
...
nam.post(req, f);
...
// sometime later in the finished slot:
finished(QNetworkReply *reply) {
// how to close and delete f ? (The QFile object)
}
Thanks
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
I think I have missed something. If it has support enabled by default why can’t he find openssl on my system? I’m on Mac OSX 10.11.2 and I there are this crypto and ssl libs available: /opt/local/lib/libcrypto.dylib /usr/lib/libcrypto.dylib /opt/local/lib/libssl.dylib /usr/lib/libssl.dylib Are they incompatible? I would compile Qt if needed I just want to see if I can avoid it. Thx, Nuno > On 02 Mar 2016, at 16:14, Koehne Kai wrote: > > > >> -Original Message- >> From: Interest [mailto:interest- >> bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of >> Nuno Santos >> Sent: Wednesday, March 02, 2016 4:38 PM >> To: interest >> Subject: [Interest] Enabling OpenSSL on a shared build of Qt >> >> Hi, >> >> I’m using Qt 5.5.1 clang_64 prebuilt package and it doesn’t seem to have >> OpenSSL support built in as I’m receiving this output. >> >> From documentation I see that OpenSSL is enabled by default however it >> doesn’t seem to able to find it. > > It does try to load libssl.so, libcrypto.so with different version numbers, > in different places. Enjoy > > https://code.woboq.org/qt5/qtbase/src/network/ssl/qsslsocket_openssl_symbols.cpp.html > >> I’m even trying to additionally link ssl libraries to the app but it doesn’t >> seem to work either. > > You need to recompile Qt to dynamically or statically link openssl. > > Regards > > Kai ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
On Wed, Mar 2, 2016 at 6:07 PM, Robert Iakobashvili wrote: > On Wed, Mar 2, 2016 at 5:37 PM, Nuno Santos wrote: >> I’m using Qt 5.5.1 clang_64 prebuilt package and it doesn’t seem to have >> OpenSSL support built in as I’m receiving this output. >> >> From documentation I see that OpenSSL is enabled by default however it >> doesn’t seem to able to find it. >> >> I’m even trying to additionally link ssl libraries to the app but it doesn’t >> seem to work either. >> >> qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback >> qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method >> qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method > > Nuno, > > 1. LIBS += -L"/path-to-lib-files" -llibeay32 -lssleay32 > > Sometimes, it may need crypt32.lib > > 2. You need to provide these openssl dlls either in one of the > directories mentioned in > PATH or add their location to PATH. > > Moreover, it seems to be that OpenSSL 1.1.x version that is required > by your Qt-version > since 1.0.x series required also SSL2 functions.. > > 3. You can find several places with instructions on how to build > OpenSSL on Windows; > as a tip, build without NASM - no need in NASM. > > Take care. > > Kind regards, > Robert Correction: 1.0.x is OK with Qt-5.5.1 . The instructions provided were for Windows. Sorry. Kind regards, Robert ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
> -Original Message- > From: Interest [mailto:interest- > bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of > Nuno Santos > Sent: Wednesday, March 02, 2016 4:38 PM > To: interest > Subject: [Interest] Enabling OpenSSL on a shared build of Qt > > Hi, > > I’m using Qt 5.5.1 clang_64 prebuilt package and it doesn’t seem to have > OpenSSL support built in as I’m receiving this output. > > From documentation I see that OpenSSL is enabled by default however it > doesn’t seem to able to find it. It does try to load libssl.so, libcrypto.so with different version numbers, in different places. Enjoy https://code.woboq.org/qt5/qtbase/src/network/ssl/qsslsocket_openssl_symbols.cpp.html > I’m even trying to additionally link ssl libraries to the app but it doesn’t > seem to work either. You need to recompile Qt to dynamically or statically link openssl. Regards Kai ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Enabling OpenSSL on a shared build of Qt
On Wed, Mar 2, 2016 at 5:37 PM, Nuno Santos wrote: > I’m using Qt 5.5.1 clang_64 prebuilt package and it doesn’t seem to have > OpenSSL support built in as I’m receiving this output. > > From documentation I see that OpenSSL is enabled by default however it > doesn’t seem to able to find it. > > I’m even trying to additionally link ssl libraries to the app but it doesn’t > seem to work either. > > qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback > qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method > qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method Nuno, 1. LIBS += -L"/path-to-lib-files" -llibeay32 -lssleay32 Sometimes, it may need crypt32.lib 2. You need to provide these openssl dlls either in one of the directories mentioned in PATH or add their location to PATH. Moreover, it seems to be that OpenSSL 1.1.x version that is required by your Qt-version since 1.0.x series required also SSL2 functions.. 3. You can find several places with instructions on how to build OpenSSL on Windows; as a tip, build without NASM - no need in NASM. Take care. Kind regards, Robert ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Obtain the QNAM in use in a QML app?
Is there a static/singleton QNetworkAccessManager that I can get in a Qt app rather than creating my own? I know there is a QNetworkAccessMangerFactory for customizing the QNAM that QML gets, but that's not what I'm asking. Platform is Android, but I'm interested "in general". ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Enabling OpenSSL on a shared build of Qt
Hi, I’m using Qt 5.5.1 clang_64 prebuilt package and it doesn’t seem to have OpenSSL support built in as I’m receiving this output. From documentation I see that OpenSSL is enabled by default however it doesn’t seem to able to find it. I’m even trying to additionally link ssl libraries to the app but it doesn’t seem to work either. qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated How do I enable OpenSSL on a shared build of Qt? Thanks, Nuno___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
Ah you mean by "knowing types at compile time" is actually defined types, so you actually defining classes at run-time? 2016-03-02 13:04 GMT+02:00 Nye : > I just meant that in my case the classes are defined in the user > application, so the library has no notion whatsoever what classes it has > available to create instances from and it depends on the meta-type system > exclusively for that (while still handling the > serialization/deserialization of said instances). It just makes a factory > inapplicable in my case (at least if you're not counting the meta-type > system as a factory). > > > On Wed, Mar 2, 2016 at 12:58 PM, André Somers > wrote: > >> >> >> Op 02/03/2016 om 11:51 schreef Sina Dogru: >> >> > For now there is a design choice which I feel weak myself, to do >>> factory or to use QMetaType for creating instances. >>> >>> Depends on the use case I suppose. If you know the types at compile >>> time, as is usually the case I'd go with the simple solution to make a >>> factory. I recently, however, had a case where the deserialization routine >>> couldn't know at compile time the exact type (i.e. for a library), so I had >>> to put a (gadget) base class and use the runtime type ids. >>> >> >> Since I'm trying to recover states of the QObject-derived class instances >> from a file, it is not possible to know the types at compile time. But is >> not that factory was also for creating objects that type is known at >> run-time? Or am I missing something? Because I thought both factory and >> metaobject system provide run-time object creation? >> >> You are right. If you know the type you need at compile time, just >> construct the instance directly. >> Factories are useful for the creation of objects who's types you do _not_ >> know at compile time. And indeed, as demonstrated above, the metaobject >> system together with the metatype system can also be abused to do the same >> thing. >> >> André >> >> > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
I just meant that in my case the classes are defined in the user application, so the library has no notion whatsoever what classes it has available to create instances from and it depends on the meta-type system exclusively for that (while still handling the serialization/deserialization of said instances). It just makes a factory inapplicable in my case (at least if you're not counting the meta-type system as a factory). On Wed, Mar 2, 2016 at 12:58 PM, André Somers wrote: > > > Op 02/03/2016 om 11:51 schreef Sina Dogru: > > > For now there is a design choice which I feel weak myself, to do >> factory or to use QMetaType for creating instances. >> >> Depends on the use case I suppose. If you know the types at compile time, >> as is usually the case I'd go with the simple solution to make a factory. I >> recently, however, had a case where the deserialization routine couldn't >> know at compile time the exact type (i.e. for a library), so I had to put a >> (gadget) base class and use the runtime type ids. >> > > Since I'm trying to recover states of the QObject-derived class instances > from a file, it is not possible to know the types at compile time. But is > not that factory was also for creating objects that type is known at > run-time? Or am I missing something? Because I thought both factory and > metaobject system provide run-time object creation? > > You are right. If you know the type you need at compile time, just > construct the instance directly. > Factories are useful for the creation of objects who's types you do _not_ > know at compile time. And indeed, as demonstrated above, the metaobject > system together with the metatype system can also be abused to do the same > thing. > > André > > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
Op 02/03/2016 om 11:51 schreef Sina Dogru: >For now there is a design choice which I feel weak myself, to do factory or to use QMetaType for creating instances. Depends on the use case I suppose. If you know the types at compile time, as is usually the case I'd go with the simple solution to make a factory. I recently, however, had a case where the deserialization routine couldn't know at compile time the exact type (i.e. for a library), so I had to put a (gadget) base class and use the runtime type ids. Since I'm trying to recover states of the QObject-derived class instances from a file, it is not possible to know the types at compile time. But is not that factory was also for creating objects that type is known at run-time? Or am I missing something? Because I thought both factory and metaobject system provide run-time object creation? You are right. If you know the type you need at compile time, just construct the instance directly. Factories are useful for the creation of objects who's types you do _not_ know at compile time. And indeed, as demonstrated above, the metaobject system together with the metatype system can also be abused to do the same thing. André ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
> > > For now there is a design choice which I feel weak myself, to do > factory or to use QMetaType for creating instances. > > Depends on the use case I suppose. If you know the types at compile time, > as is usually the case I'd go with the simple solution to make a factory. I > recently, however, had a case where the deserialization routine couldn't > know at compile time the exact type (i.e. for a library), so I had to put a > (gadget) base class and use the runtime type ids. > Since I'm trying to recover states of the QObject-derived class instances from a file, it is not possible to know the types at compile time. But is not that factory was also for creating objects that type is known at run-time? Or am I missing something? Because I thought both factory and metaobject system provide run-time object creation? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to create QObject-derived class instance from class name
> For now there is a design choice which I feel weak myself, to do factory
or to use QMetaType for creating instances.
Depends on the use case I suppose. If you know the types at compile time,
as is usually the case I'd go with the simple solution to make a factory. I
recently, however, had a case where the deserialization routine couldn't
know at compile time the exact type (i.e. for a library), so I had to put a
(gadget) base class and use the runtime type ids.
On Wed, Mar 2, 2016 at 9:31 AM, Sina Dogru wrote:
> I thank you for your answers and solutions.
>
> Before I wrote, I tried to use QMetaType::create function to instantiate
> an instance but since QObject have deleted copy constructor and copy
> assignment operator, I have ended up using QObject pointer with QMetaType..
> And when I see that QMetaType::create() function, it just create a pointer
> to QObject but not the QObject instance.. So I thought QMetaType is not for
> the QObject-derived classes..
>
> But I have not realised that QMetaType::metaObjectForType function returns
> QMetaObject instance for the class not for the pointer to class.
>
> For now there is a design choice which I feel weak myself, to do factory
> or to use QMetaType for creating instances.
>
> Thank you,
> Sina
>
> 2016-03-01 18:51 GMT+02:00 André Somers :
>
>>
>>
>> Op 01/03/2016 om 17:21 schreef Thiago Macieira:
>>
>>> On terça-feira, 1 de março de 2016 17:06:49 PST André Somers wrote:
>>>
The meta *object* system has no registration.
>
> The meta *type* system requires that the registered type be default-
> constructible and copyable, but QObject is not copyable. Therefore,
> QObject- derived classes cannot be registered with the meta type
> system.
>
Am I completely misinterpretting the documentation then?
http://doc.qt.io/qt-5/qmetatype.html#metaObject
If I read that correctly, you can register a
pointer-to-a-QObject-derived-class-instance and use that. So, indeed,
you do not register the type, but the type*. And that has no problems
with being default constructed or copied.
>>> Correct. You can't register a QObject class with the meta type system,
>>> but you
>>> can register a pointer to a QObject class. The problem is that
>>> QMetaType::create() will then create a pointer, not the object.
>>>
>> Of course. But... Again, if I read it correctly, you *can* then get the
>> QMetaObject from QMetaType, and using that, you can create an actual
>> instance.
>>
>> Just tested this trivial example:
>>
>> //main.cpp
>> int main(int argc, char *argv[])
>> {
>> qRegisterMetaType(); //this could be elsewhere of course
>>
>> QCoreApplication a(argc, argv);
>>
>> auto tId = QMetaType::type("TestClass*"); //just using the class name
>> with an *
>> auto metaObject = QMetaType::metaObjectForType(tId);
>> QObject* instance = metaObject->newInstance();
>>
>> return a.exec();
>> delete instance;
>> }
>>
>> //testclass.h
>> class TestClass: public QObject
>> {
>> Q_OBJECT
>>
>> public:
>> Q_INVOKABLE TestClass();
>> };
>>
>> Q_DECLARE_METATYPE(TestClass*)
>>
>> //testclass.cpp
>> TestClass::TestClass()
>> {
>> qDebug() << "TestClass instance created";
>> }
>>
>> Which prints out "TestClass instance created" on the console. My
>> conclusion is that it works, and that you _can_ create a QObject derived
>> instance with just the class name.
>>
>> Again: I am not claiming that abusing this to skip defining a factory is
>> a good idea. Just that it is possible.
>>
>>
>> André
>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] how QQmlProperty works ?
2. Why are you write string values? It's not "Image.Stretch", it's an enum value of QQuickImage. 3. Remove the .ui suffix, like "MainForm.qml". 4. QML id is not the same as objectName. If you use QObject::findChild(), you should set objectName. Also, creating two QQmlEngine's for different QML files looks weird... 2016-03-02 5:50 GMT+02:00 Nicolas Jäger : > Hi, > > I dont understand how QQmlProperty works, consider this example : > > main.cpp : http://pastebin.com/B17uY2Av [1] > > MainForm.ui.qml : http://pastebin.com/N3JKnU2h [2] > > output : > > Property value: QVariant(int, 3) > Property value: QVariant(int, 3) > Property value: QVariant(double, 10) > Property value: QVariant(double, 500) > > first, in the window the image isn't resized, it still has 10px. > > second, how can set and display with qDebug values like : > > fillMode: Image.Tile > > third, when using qcreator everytime I clicked on MainForm.ui.qml I got > the window of design opened, if I click on edit there is a message that > this file should only be edited trough the designer, ok but to be able > to use findchild I have to set objectName. I haven't found how to do > that in the designer. Personnaly I don't like to have the designer > opened by default, I would like to get the edit mode opened by default. > > four, instead of using objectName, could we use id ? > > Regards, > > Nicolas > > > Links: > -- > [1] http://pastebin.com/B17uY2Av > [2] http://pastebin.com/N3JKnU2h > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
