Re: [Interest] Is freshly created QNetworkReply guaranteed to be in non-finished state and emit finished signal?

On quarta-feira, 19 de abril de 2017 05:30:49 PDT Konstantin Tokarev wrote: > Hello, > > I wonder if in the following code it's safe to assume onFinished() will > always be called: > > QNetworkReply *reply = networkAccessManager->get(request); > connect(reply, SIGNAL(finished()),

Re: [Interest] Is freshly created QNetworkReply guaranteed to be in non-finished state and emit finished signal?

On Wednesday 19 April 2017 11:03:48 Thiago Macieira wrote: > On quarta-feira, 19 de abril de 2017 05:30:49 PDT Konstantin Tokarev wrote: > > Hello, > > > > I wonder if in the following code it's safe to assume onFinished() will > > > > always be called: > > QNetworkReply *reply =

[Interest] qobject_cast

Hi, What the benefits of qobject_cast<> on simple static_cast<>? Or there is no one? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Is freshly created QNetworkReply guaranteed to be in non-finished state and emit finished signal?

On quarta-feira, 19 de abril de 2017 13:15:23 PDT Reinhardt Behm wrote: > On Wednesday 19 April 2017 11:03:48 Thiago Macieira wrote: > > It's guaranteed not to be finished. > > Doesn't QAN use it's own thread? Irrelevant. > Then it could already be finished before the connection is made. It

Re: [Interest] QPluginLoader

On Wed, April 19, 2017 08:30, Igor Mironchik wrote: > In the docs to QPluginLoader: > > Once loaded, plugins remain in memory until all instances of > QPluginLoader has been unloaded, or until the > application terminates. > > But in plugandpaint example: [cut] > So my question is why plugins

[Interest] Is freshly created QNetworkReply guaranteed to be in non-finished state and emit finished signal?

Hello, I wonder if in the following code it's safe to assume onFinished() will always be called: QNetworkReply *reply = networkAccessManager->get(request); connect(reply, SIGNAL(finished()), SLOT(onFinished())); Or is reply allowed to be in finished state already and never emit finished?

Re: [Interest] Doc Snapshot is not Snapshot

> -Original Message- > From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org] > On Behalf Of Konstantin Podsvirov > Sent: Tuesday, April 18, 2017 7:45 PM > To: interest > Subject: [Interest] Doc Snapshot is not Snapshot > > For example, QtIFW

Re: [Interest] Doc Snapshot is not Snapshot

16:04, 19 April 2017 г., Kai Koehne : -Original Message- From: Interest [mailto:interest-bounces+kai.koehne=qt...@qt-project.org] On Behalf Of Konstantin Podsvirov Sent: Tuesday, April 18, 2017 7:45 PM To: interest  Subject: [Interest] Doc

Re: [Interest] qobject_cast

Hi, 20.04.2017 7:52, Ch'Gans пишет: On 20 April 2017 at 16:38, Igor Mironchik wrote: Hi, What the benefits of qobject_cast<> on simple static_cast<>? Or there is no qobject_cast - works only on QObject (obviously) - returns nullptr if the object cannot be casted

Re: [Interest] qobject_cast

On 20 April 2017 at 17:03, Igor Mironchik wrote: > Hi, > > > 20.04.2017 7:52, Ch'Gans пишет: >> >> On 20 April 2017 at 16:38, Igor Mironchik >> wrote: >>> >>> Hi, >>> >>> What the benefits of qobject_cast<> on simple static_cast<>? Or there is

Re: [Interest] qobject_cast

On quarta-feira, 19 de abril de 2017 21:38:46 PDT Igor Mironchik wrote: > Hi, > > What the benefits of qobject_cast<> on simple static_cast<>? Or there is > no one? qobject_cast checks, static_cast doesn't. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open

Re: [Interest] qobject_cast

20.04.2017 8:47, Ch'Gans пишет: On 20 April 2017 at 17:03, Igor Mironchik wrote: Hi, 20.04.2017 7:52, Ch'Gans пишет: On 20 April 2017 at 16:38, Igor Mironchik wrote: Hi, What the benefits of qobject_cast<> on simple static_cast<>? Or

Re: [Interest] qobject_cast

On 20 April 2017 at 16:38, Igor Mironchik wrote: > Hi, > > What the benefits of qobject_cast<> on simple static_cast<>? Or there is no qobject_cast - works only on QObject (obviously) - returns nullptr if the object cannot be casted to the required type - doesn't relies

[Interest] QPluginLoader

Hello, In the docs to QPluginLoader: Once loaded, plugins remain in memory until all instances of QPluginLoader has been unloaded, or until the application terminates. But in plugandpaint example: //![6] foreach(QStringfileName,pluginsDir.entryList(QDir::Files)){

Re: [Interest] Bluetooth LE: HowTo inspect QBluetoothDeviceInfo::serviceUuids

On 18/04/2017 11:12, ekke wrote: Am 18.04.17 um 10:26 schrieb Oliver Wolff: On 13/04/2017 19:01, ekke wrote: from QBluetoothDeviceInfo::serviceUuids I'm getting a list of Service UUIDs ( QBluetoothUuid) without connecting to the device and inspecting the Services. there's per ex:

Re: [Interest] QPluginLoader

19.04.2017, 09:30, "Igor Mironchik" : > Hello, > > In the docs to QPluginLoader: > > Once loaded, plugins remain in memory until all instances of QPluginLoader > has been unloaded, or until the application terminates. > > But in plugandpaint example: > > //! [6] > >

Re: [Interest] Another query on GTK platform theme/style

Den 18 apr. 2017 7:01 em skrev "Thiago Macieira" : > > Em terça-feira, 18 de abril de 2017, às 09:10:44 PDT, Elvis Stansvik escreveu: > > Right, unless the style plugin is naughty and using private headers > > (like I think eg Breeze is doing). > > I don't think they

Re: [Interest] Qt3D: Problem with QSkybox basename property

Hi, On 19/04/2017 01:20, Ch'Gans wrote: On 18 April 2017 at 22:58, Sean Harmer wrote: Hi, On 18/04/2017 10:10, Ch'Gans wrote: Hi there, I have just tried the sky box entity with Qt-5.9-beta, and found a small problem: If you don't specify a basename or if the

Re: [Interest] QtQuick import question

For what it’s worth, the documentation for Qt Quick Controls 2 has (or will have) such a table (although starting at Qt 5.7, which is when they were released): https://doc-snapshots.qt.io/qt5-5.9/qtquickcontrols2-index.html#versions From: Interest

Re: [Interest] Bluetooth LE: HowTo inspect QBluetoothDeviceInfo::serviceUuids

Am 19.04.17 um 09:45 schrieb Oliver Wolff: > ... >> now I'm simply comparing found ServiceUUIDs with the full value >> {180d--1000-8000-00805f9b34fb} >> to detect the Device as a HeartRate Device > You don't need to compare to the full value. Comparing to > QBluetoothUuid::HeartRate also

Re: [Interest] Bluetooth LE: HowTo inspect QBluetoothDeviceInfo::serviceUuids

Am 19.04.17 um 10:47 schrieb ekke: > Am 19.04.17 um 09:45 schrieb Oliver Wolff: >> ... >>> now I'm simply comparing found ServiceUUIDs with the full value >>> {180d--1000-8000-00805f9b34fb} >>> to detect the Device as a HeartRate Device >> You don't need to compare to the full value.