On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
> In that case, the QCoapReply life is managed with a
> QSharedPointer in the request.
>
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this
> approach?
The API sounds interesting, but it's a departure of what we a
> On 16 Jan 2018, at 15:04, Shawn Rutledge wrote:
>
>
>> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote:
>>
>>
>> On 15.01.2018 17:25, Ryan Chu wrote:
>>> Hi all,
>>> I'm working on a task supporting "Push Notification" for Qt applications.
>>> This feature will be implemented on Android an
On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote:
> So just use QString(), or define your own static instance of it if you
> really want to microoptimize it that much.
No it is simply that the first version of Qwt was for Qt 1.2 ( before
QString even existed ) and during a history of almos
Uwe Rathmann wrote:
> So my first question would be, what is wrong about using QString:null and
> why using QString() is better. My second question then would be if this
> is also for Qt4 ( Qwt 6.1.2 supports all versions >= Qt 4.4 ) and older
> versions of C++ and compilers.
A long long time ago,
> Sent: Tuesday, January 16, 2018 at 9:18 AM
> From: "Konstantin Tokarev"
> To: "Shawn Rutledge" , "development@qt-project.org"
>
> Subject: Re: [Development] Repository request: Qt Notifier
>
>
>
> 16.01.2018, 17:05, "Shawn Rutledge" :
> >> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote:
On Tue, 16 Jan 2018 17:54:43 +0100, Giuseppe D'Angelo wrote:
> headers of 3rd party libraries
> should be included under -isystem, not -I, to disable warnings in their
> headers.
Yes as there seems to be no BC break ( thanks to all correcting me, I
should have a deeper look at the code before )
No it isn‘t about you. But your message suggested you blame it on Qt project ;)
Anyway, default values are not part of a functions signature and don’t break
binary compatibility.
Beste Grüße / Best regards,
Alexander Nassian
> Am 16.01.2018 um 17:46 schrieb Uwe Rathmann :
>
>> On Tue, 16 Jan 2
Il 16/01/2018 16:20, Uwe Rathmann ha scritto:
Sure this is only a warning, but it is obviously something where Qwt
users get irritated as they can't fix code of a 3rd party header.
Changing to QString() is BC, as explained, so just do that. Note that
this is actually a buildsystem issue: heade
Dear Qt Community,
I am writing my first application using a compute shader based on Qt3D in C++.
My question: What is the correct way of updating the data needed by the compute
shader during run-time? This is what I tried so far:
I create a QBuffer object (in form of a QPointer) and fill it wi
On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote:
> Deprecated since Qt4 ...
According to qstring.h:
#if QT_DEPRECATED_SINCE(5, 9)
...
#endif
But come this is not about me and if I missed, that an API has been
declared as deprecated. It is about what to best in the current situation
changing the parameter's default value *is* binary compatible.
Regards,
Konstantin
2018-01-16 20:35 GMT+04:00 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com>:
> > The "just change" introduces a binary incompatibility - right ?
>
> I don't think it does: the QString is constructed on the
> On Jan 16, 2018, at 17:16, Uwe Rathmann wrote:
>
> On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
>
>> Just change your code to use "= QString()", no #ifdef necessary.
>
> The "just change" introduces a binary incompatibility - right ?
I don’t see why that would be the case, the
> The "just change" introduces a binary incompatibility - right ?
I don't think it does: the QString is constructed on the caller's side
anyways and your function is always passed a QString object;
if you had an app that linked to qwt and didn't recompile it will just keep
calling QString::null()
Deprecated since Qt4 (so it survived already two versions that were allowed to
break binary compatibility) means that you had 12 (twelve) years to do the
migration. How long should it be maintained? And again, it also could have been
removed in Qt4 or 5.
> Am 16.01.2018 um 17:16 schrieb Uwe Rat
16.01.2018, 19:18, "Uwe Rathmann" :
> On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
>
>> Just change your code to use "= QString()", no #ifdef necessary.
>
> The "just change" introduces a binary incompatibility - right ?
>
> Please be aware, that Qwt is part of almost any Linux dis
On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
> Just change your code to use "= QString()", no #ifdef necessary.
The "just change" introduces a binary incompatibility - right ?
Please be aware, that Qwt is part of almost any Linux distro - according
to sourceforge it has more than
Am Dienstag, 16. Januar 2018, 16:20:54 CET schrieb Uwe Rathmann:
> Hi all,
>
> I received a bug report concerning a header of the Qwt library ( http://
> qwt.sf.net ), that is using the deprecated QString::null.
>
> Sure this is only a warning, but it is obviously something where Qwt
> users get
Hi all,
I received a bug report concerning a header of the Qwt library ( http://
qwt.sf.net ), that is using the deprecated QString::null.
Sure this is only a warning, but it is obviously something where Qwt
users get irritated as they can't fix code of a 3rd party header.
The offending line lo
16.01.2018, 17:46, "Shawn Rutledge" :
>> On 16 Jan 2018, at 15:18, Konstantin Tokarev wrote:
>>
>> Is cloud aspect so principal? Can there be "non-cloud" backend which just
>> uses persistent
>> HTTP connection, e.g. with nginx-push-stream-module on the server side?
>>
>> https://github.com
> On 16 Jan 2018, at 15:18, Konstantin Tokarev wrote:
>
> Is cloud aspect so principal? Can there be "non-cloud" backend which just
> uses persistent
> HTTP connection, e.g. with nginx-push-stream-module on the server side?
>
> https://github.com/wandenberg/nginx-push-stream-module
An HTTP se
16.01.2018, 17:05, "Shawn Rutledge" :
>> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote:
>>
>> On 15.01.2018 17:25, Ryan Chu wrote:
>>> Hi all,
>>> I'm working on a task supporting "Push Notification" for Qt applications.
>>> This feature will be implemented on Android and iOS devices as th
> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote:
>
>
> On 15.01.2018 17:25, Ryan Chu wrote:
>> Hi all,
>> I'm working on a task supporting "Push Notification" for Qt applications.
>> This feature will be implemented on Android and iOS devices as the first
>> stage. A new module called "Qt No
On 15.01.2018 17:25, Ryan Chu wrote:
Hi all,
I'm working on a task supporting "Push Notification" for Qt
applications. This feature will be implemented on Android and iOS
devices as the first stage. A new module called "Qt Notify" will be
created for all platforms. Therefore I request a repo
Thanks, Jake. It seems to be a better naming.
- Revise the module name of my request
Hi all,
I'm working on a task supporting "Push Notification" for Qt applications. This
feature will be implemented on Android and iOS devices as the first stage. A
new module called "Qt Notifications" will b
On mandag 15. januar 2018 14.52.29 CET Simon Hausmann wrote:
> Hi,
>
>
> I would like to nominate Adam for approver status. He has been developing
> with Qt for more than a decade and has been working on Qt and Qt 3D studio
> full time for about a year. I fully trust him to review changes thoroug
Thiago, thanks for the clarification. Yeah, you have a point, I agree with
those reasons though they are more server-related and CoAP module has no one
yet. I was also thinking that having a TP status on CoAP module can help to
mitigate possible API/design problems/inconsistency.
Maurice:
>
Am 01/15/2018 um 11:12 PM schrieb Bartosz Pajewski:
> I need a little bit help.
>
> After compilation my app and include necessary libraries the app has
> problem with load drivers included in plugins/sqldrivers.
> The problem is solved, if I install Qt, and compile project again.
I guess what
27 matches
Mail list logo
