[Interest] Migrating QWeakPointer to Qt5

[Tom Isaacson]

I'm moving some Qt4.8.2 code which uses QWeakPointer to Qt5.6.  Simplifying a 
lot it looks like this:

class MySettings : public QObject
{
Q_OBJECT
}

class MyClass : public QObject
{
Q_OBJECT

private:
QWeakPointer m_xSettings;
}

MyClass::MyClass(MySettings* pSettings, QObject* pParent)
: QObject(pParent)
, m_xSettings(pSettings)
{
}

but when I compile under Visual Studio 2013 I get this error:
error C2664: 'QWeakPointer::QWeakPointer(const QSharedPointer &)' : 
cannot convert argument 1 from 'MySettings *' to 'const 
QWeakPointer &'

I tried changing the QWeakPointer to a QPointer but now I'm getting:
error C2440: 'static_cast' : cannot convert from 'QObject *' to MyClass *' 
(GeneratedFiles\Debug\moc_MyCode.cpp)

Is there a recommended method for migrating the use of QWeakPointer into Qt5?

Thanks.

Tom Isaacson

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to set Android Version and App Name

[ekke]

Am 05.05.16 um 21:47 schrieb NoRulez:
> Hello,
>
> I tried to deploy my first example app to my device.
> I noticed that the app name is always QtApp and the target is always 
> android-23.
> I tried to set the version with "--android platform android-21" but it 
> doesn't work either.
>
> Can anybody give me a hint to set those options?
>
> Thanks
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
For the SDK Version:

Have you set the Version from QtCreator - Projects - Build Settings -
Build Android APK -> ...22 ...23

ekke
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Thiago Macieira]

On quinta-feira, 5 de maio de 2016 04:24:48 PDT Nikos Chantziaras wrote:
> > So what are you requirements? Do you want to a container that does delete
> > the object it has, unless the parent has already deleted it?
> 
> Well, basically what I want is not having even a single 'new' or 
> 'delete' anywhere in my code. I already achieved that with all my non-Qt 
> projects.

If you don't want to use new or delete, use stack-based objects and only 
create children objects as members. That is, what Nye suggested.

-- 
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] [QtWayland] App window now showing in Weston

[Ryan Elkholy, PhD, PE]

Hello,

I have successfully built a yocto image that includes wayland and is using
the reference weston compositor on my target device. I have also
successfully ran Qt5_CinematicExperience as well as other example Qt apps
within weston.

My problem occurs when I run the same example apps or even a simple custom
app from my host device. I am using QtCreator to build and deploy the app
which works fine. Once I try to run the app I believe it runs successfully
because the Application Output behaves correctly and my target shows in the
running processes that it is actually running. The problem is that I do not
see the window for the app on the screen within weston. I am thinking it is
running off screen, but I am not sure about that.

Has anyone seen this problem or know of any possible fixes?

Thanks
Ryan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt interfacing to Android native UI ?

[Jason H]

I emailed th author of react-qml, he's just fiddling with it, it's not s serious project.

 

Dang, why can't we (Qt) get buy-in like that?

 

 

Sent: Thursday, May 05, 2016 at 3:58 PM
From: "Edward Sutton" 
To: "Jason H" 
Cc: "Robert Iakobashvili" , "interest@qt-project.org" 
Subject: Re: [Interest] Qt interfacing to Android native UI ?




I have not used the project.

 

My guess one motivating goal would be to reuse the many react-native modules that support both Android and iOS ( or one OS or the other ). 

 

Another goal would be to access real native UI components and native API’s.  While QML looks native-like, for Android or iOS apps, native just feels better to the user IMO.

 

Microsoft is reportedly adding react native support for UWP and claim it will support 270 million Windows 10 devices.


 



https://blogs.windows.com/buildingapps/2016/04/13/react-native-on-the-universal-windows-platform/




 

-Ed

 



On May 5, 2016, at 9:45 AM, Jason H  wrote:
 




What is the motivation for such a project?
 

Sent: Thursday, May 05, 2016 at 10:31 AM
From: "Edward Sutton" 
To: "Robert Iakobashvili" 
Cc: "interest@qt-project.org" 
Subject: Re: [Interest] Qt interfacing to Android native UI ?


An interesting project:
 


https://github.com/grassator/react-qml


 

react-qml is a bridge library that allows to use React.js with QML.


Example

Usage of ReactQml is pretty straightforward — the only difference from web version is that you need to pass id of the qml item to React.render instead of DOM node. For example:


import QtQuick 2.4
import QtQuick.Controls 1.3
import "js/ReactQml.js" as React

ApplicationWindow {
id: root
title: qsTr("React QML")
width: 300
height: 300
visible: true

function reactRender(x, y) {
var props = {
x: 100,
y: 100,
width: 100,
height: 100,
color: '#000'
};
var childProps = {
x: 25,
y: 25,
width: 50,
height: 50,
color: '#fff'
};
var child = React.createElement(React.Rectangle, childProps);
React.render(React.createElement(React.Rectangle, props, child), root);
}

Component.onCompleted: {
reactRender();
}
}

 



 

-Ed

 


On May 2, 2016, at 1:50 PM, Robert Iakobashvili  wrote:
 


Dear Ekke,
Thank you for sharing your experience with
qt.labs.controls Qt Quick Controls2 in 5.7.

Sure, we'll be reading you blog.

Kind regards,
Robert


On Mon, May 2, 2016 at 8:38 PM, ekke  wrote:

I really like the new qt.labs.controls from Qt 5.6 (will become Qt Quick
Controls2 in 5.7)
using these lightweight controls together with Material Style (Android) or
Universal Style (Windows) with light or dark themes and all the new Controls
(like Drawer) for mobile-app-navigation and also HighDPI Support you can now
first time ever develop mobile apps with nearly native feeling. (iOS style
will come later when the new controls are stable)

I prefer to write UI in QML compared with React Native's mix of Markup and
JS or using Xamarin where you have one language but different code for
x-platform.

Before leaving QT for mobile apps - give it a try.
BTW: I'm writing a blog series about my experiences  https://urldefense.proofpoint.com/v2/url?u=http-3A__j.mp_qt-2Dx=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=13ftz5U9_dHo8BjIh3RKmuX9DkqPXcAx9ctnx5a0YHA=   and
I'll develop - as proof of concept - Conference APPs for QtCon and Qt World
Summit.

ekke

Am 02.05.16 um 20:17 schrieb Robert Iakobashvili:

Dear Edward,
React Native - good catch.

Thank you so much for sharing this idea
and your experience!

Kind regards,
Robert


On Mon, May 2, 2016 at 8:08 PM, Edward Sutton 
wrote:

On May 1, 2016, at 4:27 AM, Robert Iakobashvili  wrote:

Dear Edward,
What are your conclusions and which direction you decided on
after your experiments?


I never made much progress. While QML looked more "native like” I never felt
comfortable using it.

I am doing my new iOS and Android development using Facebook's react-native.
React Native calls native UI from _javascript_.

https://urldefense.proofpoint.com/v2/url?u=https-3A__facebook.github.io_react-2Dnative_=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=e9hAWWmY2S0Mo76_ex-_PF0NFk6ccgclP50872TSMfs=


When it makes sense I select UI components that have counterparts in Android
and iOS in order to increase code re-use.   I have seem claims of 85% code
re-use and from my experience  I do not doubt these claims.

So far, so good...

-Ed



Thanks,
Kind 

Re: [Interest] How to set Android Version and App Name

[NoRulez]

The name and version in the package/AndroidManifest.xml are the correct ones

> Am 05.05.2016 um 21:50 schrieb Jason H :
> 
> 
>> I tried to deploy my first example app to my device.
>> I noticed that the app name is always QtApp and the target is always 
>> android-23.
>> I tried to set the version with "--android platform android-21" but it 
>> doesn't work either.
>> 
>> Can anybody give me a hint to set those options?
> 
> Edit AndroidManifest.xml - get familiar with it, because it controls a lot.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt interfacing to Android native UI ?

[Edward Sutton]

I have not used the project.

My guess one motivating goal would be to reuse the many react-native modules 
that support both Android and iOS ( or one OS or the other ).

Another goal would be to access real native UI components and native API’s.  
While QML looks native-like, for Android or iOS apps, native just feels better 
to the user IMO.

Microsoft is reportedly adding react native support for UWP and claim it will 
support 270 million Windows 10 devices.

https://blogs.windows.com/buildingapps/2016/04/13/react-native-on-the-universal-windows-platform/

-Ed

On May 5, 2016, at 9:45 AM, Jason H > wrote:

What is the motivation for such a project?

Sent: Thursday, May 05, 2016 at 10:31 AM
From: "Edward Sutton" 
>
To: "Robert Iakobashvili" >
Cc: "interest@qt-project.org" 
>
Subject: Re: [Interest] Qt interfacing to Android native UI ?
An interesting project:

https://github.com/grassator/react-qml

react-qml is a bridge library that allows to use React.js with QML.
Example

Usage of ReactQml is pretty straightforward — the only difference from web 
version is that you need to pass id of the qml item to React.render instead of 
DOM node. For example:

import QtQuick 2.4
import QtQuick.Controls 1.3
import "js/ReactQml.js" as React

ApplicationWindow {
id: root
title: qsTr("React QML")
width: 300
height: 300
visible: true

function reactRender(x, y) {
var props = {
x: 100,
y: 100,
width: 100,
height: 100,
color: '#000'
};
var childProps = {
x: 25,
y: 25,
width: 50,
height: 50,
color: '#fff'
};
var child = React.createElement(React.Rectangle, childProps);
React.render(React.createElement(React.Rectangle, props, child), root);
}

Component.onCompleted: {
reactRender();
}
}



-Ed

On May 2, 2016, at 1:50 PM, Robert Iakobashvili 
 wrote:

Dear Ekke,
Thank you for sharing your experience with
qt.labs.controls Qt Quick Controls2 in 5.7.

Sure, we'll be reading you blog.

Kind regards,
Robert


On Mon, May 2, 2016 at 8:38 PM, ekke 
 wrote:
I really like the new qt.labs.controls from Qt 5.6 (will become Qt Quick
Controls2 in 5.7)
using these lightweight controls together with Material Style (Android) or
Universal Style (Windows) with light or dark themes and all the new Controls
(like Drawer) for mobile-app-navigation and also HighDPI Support you can now
first time ever develop mobile apps with nearly native feeling. (iOS style
will come later when the new controls are stable)

I prefer to write UI in QML compared with React Native's mix of Markup and
JS or using Xamarin where you have one language but different code for
x-platform.

Before leaving QT for mobile apps - give it a try.
BTW: I'm writing a blog series about my experiences 
https://urldefense.proofpoint.com/v2/url?u=http-3A__j.mp_qt-2Dx=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=13ftz5U9_dHo8BjIh3RKmuX9DkqPXcAx9ctnx5a0YHA=
   and
I'll develop - as proof of concept - Conference APPs for QtCon and Qt World
Summit.

ekke

Am 02.05.16 um 20:17 schrieb Robert Iakobashvili:

Dear Edward,
React Native - good catch.

Thank you so much for sharing this idea
and your experience!

Kind regards,
Robert


On Mon, May 2, 2016 at 8:08 PM, Edward Sutton 

wrote:

On May 1, 2016, at 4:27 AM, Robert Iakobashvili 
 wrote:

Dear Edward,
What are your conclusions and which direction you decided on
after your experiments?


I never made much progress. While QML looked more "native like” I never felt
comfortable using it.

I am doing my new iOS and Android development using Facebook's react-native.
React Native calls native UI from Javascript.

https://urldefense.proofpoint.com/v2/url?u=https-3A__facebook.github.io_react-2Dnative_=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=e9hAWWmY2S0Mo76_ex-_PF0NFk6ccgclP50872TSMfs=


When it makes sense I select UI components that have counterparts in Android
and iOS in order to increase code re-use.   I have seem claims of 85% code
re-use and from my experience  I do not doubt these claims.

So far, so good...

-Ed



Thanks,
Kind regards,
Robert


On Thu, Nov 5, 2015 at 2:40 PM, Edward Sutton 

Re: [Interest] How to set Android Version and App Name

[Jason H]

> I tried to deploy my first example app to my device.
> I noticed that the app name is always QtApp and the target is always 
> android-23.
> I tried to set the version with "--android platform android-21" but it 
> doesn't work either.
> 
> Can anybody give me a hint to set those options?

Edit AndroidManifest.xml - get familiar with it, because it controls a lot.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] How to set Android Version and App Name

[NoRulez]

Hello,

I tried to deploy my first example app to my device.
I noticed that the app name is always QtApp and the target is always android-23.
I tried to set the version with "--android platform android-21" but it doesn't 
work either.

Can anybody give me a hint to set those options?

Thanks
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] [QML][C++][Context] change property into context

[Jérôme Godbout]

Hi,
I would like to known if there's a way to efficiently change the value into
a context and emit changed() signal without having setContextProperty()
forcing whole context revaluation?

Let say I have a special Repeater alike component that create and maintain
expensive Object that add index,value into the context (that's just an
example). I would like to avoid deleting/creating all item but just change
the index of one of them.

Ex my component create the following Object list:
[O0, O1, O2, O3, O4]

A command remove O1:
I would like instead of creating all and deleting all previous or making
[O0, O2, O3, O4] I would like to create [O0, O4, O2, O3] and change the
context values of O4 only, reducing the number of binding evaluation.

I was wondering if that possible to set context property value after object
creation and emit the changed? is it safe to call setContextProperty on
already created object? I guess it is, but would be very slow to change
multiple value into it (not so bad we only have 2 of them to set on a
limited number of object, would still be a gain over current implementation
we have or what repeater does too).

This would be very nice to achieve that for some very long repeated GUI
list item we have that.

Thanks,
Jerome
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Nikos Chantziaras]

On 05/05/16 14:52, Giuseppe D'Angelo wrote:

On Thu, May 5, 2016 at 1:22 PM, Nikos Chantziaras  wrote:

That doesn't do anything useful. I think you're missing the point here.


Did you try the earlier suggestion of using a QScopedPointer with a
custom deleter that holds a QPointer to the instance and deletes it
only if it has not been deleted already?


Yes. But I now did the same with unique_ptr, so all is fine now :-)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Nikos Chantziaras]

Well, lots of strong opinions on this one :-)

Anyway, to each his own. Of course I know that C++ isn't Java, nor would 
I want it to be. But just because C++ isn't Java doesn't mean I am in 
favor of poor exception safety or lots of manual checking and cleaning 
up. Yes, we still have to do these things, but the less of them we have 
to do, the better.


So for my own needs, I just came up with this:

template 
auto q_make_unique(Args&&... args)
{
auto tmp = std::make_unique(std::forward(args)...);
auto deleter = [q_ptr = QPointer(tmp.get())](const T* obj)
{
if (q_ptr) {
delete obj;
}
};
std::unique_ptr
uptr(tmp.release(), std::move(deleter));
return uptr;
}

Which probably can be done better with less overhead, but I'll settle 
for "good enough" for now.



On 04/05/16 17:48, Nikos Chantziaras wrote:

I've been removing every trance of 'new' and 'delete' from my code and
switching to something like:

   auto obj = std::make_unique(ctor args);

(Or std::make_shared, depending on the situation.)

But for QObjects with a parent, that can go horribly wrong. So I have to
do annoying stuff like:

   auto dialog = new QDialog(parent);
   // work...
   delete dialog;

Yes, 'parent' will eventually delete 'dialog', but that doesn't help
much when 'parent' is a long lived object (like the main application
window.)

Is there a Qt-specific idiom where I can manage QObjects that have a
parent with a smart pointer and not have to worry about double-deletion?

Or, to phrase it in another way, is there a way to eliminate the 'new'
keyword completely from my code-base when using QObjects with a parent?




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt interfacing to Android native UI ?

[Jason H]

What is the motivation for such a project?
 

Sent: Thursday, May 05, 2016 at 10:31 AM
From: "Edward Sutton" 
To: "Robert Iakobashvili" 
Cc: "interest@qt-project.org" 
Subject: Re: [Interest] Qt interfacing to Android native UI ?


An interesting project:
 


https://github.com/grassator/react-qml


 

react-qml is a bridge library that allows to use React.js with QML.


Example

Usage of ReactQml is pretty straightforward — the only difference from web version is that you need to pass id of the qml item to React.render instead of DOM node. For example:


import QtQuick 2.4
import QtQuick.Controls 1.3
import "js/ReactQml.js" as React

ApplicationWindow {
id: root
title: qsTr("React QML")
width: 300
height: 300
visible: true

function reactRender(x, y) {
var props = {
x: 100,
y: 100,
width: 100,
height: 100,
color: '#000'
};
var childProps = {
x: 25,
y: 25,
width: 50,
height: 50,
color: '#fff'
};
var child = React.createElement(React.Rectangle, childProps);
React.render(React.createElement(React.Rectangle, props, child), root);
}

Component.onCompleted: {
reactRender();
}
}

 



 

-Ed

 


On May 2, 2016, at 1:50 PM, Robert Iakobashvili  wrote:
 


Dear Ekke,
Thank you for sharing your experience with
qt.labs.controls Qt Quick Controls2 in 5.7.

Sure, we'll be reading you blog.

Kind regards,
Robert


On Mon, May 2, 2016 at 8:38 PM, ekke  wrote:

I really like the new qt.labs.controls from Qt 5.6 (will become Qt Quick
Controls2 in 5.7)
using these lightweight controls together with Material Style (Android) or
Universal Style (Windows) with light or dark themes and all the new Controls
(like Drawer) for mobile-app-navigation and also HighDPI Support you can now
first time ever develop mobile apps with nearly native feeling. (iOS style
will come later when the new controls are stable)

I prefer to write UI in QML compared with React Native's mix of Markup and
JS or using Xamarin where you have one language but different code for
x-platform.

Before leaving QT for mobile apps - give it a try.
BTW: I'm writing a blog series about my experiences  https://urldefense.proofpoint.com/v2/url?u=http-3A__j.mp_qt-2Dx=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=13ftz5U9_dHo8BjIh3RKmuX9DkqPXcAx9ctnx5a0YHA=   and
I'll develop - as proof of concept - Conference APPs for QtCon and Qt World
Summit.

ekke

Am 02.05.16 um 20:17 schrieb Robert Iakobashvili:

Dear Edward,
React Native - good catch.

Thank you so much for sharing this idea
and your experience!

Kind regards,
Robert


On Mon, May 2, 2016 at 8:08 PM, Edward Sutton 
wrote:

On May 1, 2016, at 4:27 AM, Robert Iakobashvili  wrote:

Dear Edward,
What are your conclusions and which direction you decided on
after your experiments?


I never made much progress. While QML looked more "native like” I never felt
comfortable using it.

I am doing my new iOS and Android development using Facebook's react-native.
React Native calls native UI from _javascript_.

https://urldefense.proofpoint.com/v2/url?u=https-3A__facebook.github.io_react-2Dnative_=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=e9hAWWmY2S0Mo76_ex-_PF0NFk6ccgclP50872TSMfs=


When it makes sense I select UI components that have counterparts in Android
and iOS in order to increase code re-use.   I have seem claims of 85% code
re-use and from my experience  I do not doubt these claims.

So far, so good...

-Ed



Thanks,
Kind regards,
Robert


On Thu, Nov 5, 2015 at 2:40 PM, Edward Sutton 
wrote:

Hi Robert,

The approach you outlined below was the one I was considering. Use of common
C++ business layer, widgets for desktops, iOS native UI, and Android native
UI.

The Android native UI was my biggest concern.

I am going to continue experimenting with QML for a few more days


Hi Ben,

Thank you for sharing your Android UI interfacing code.  I will take a look.

Your iOS UI interfacing code was *very* helpful in understanding how to mix
C++ and Objective-C++ in the same *.mm file.  Java seems much more
challenging to interface to native UI.  However all I have done so far is
simple JNI calls into Java.

Thank you both,

-Ed


On Nov 5, 2015, at 1:51 AM, Ben Lau  wrote:


Not really a solution for wrapping Android UI in Qt app. But I have already
developed an image picker with native UI and communication library between
Qt and Java/Android. May be it could used as example / core framework.

Image Picker

Re: [Interest] Qt interfacing to Android native UI ?

[Edward Sutton]

An interesting project:

https://github.com/grassator/react-qml

react-qml is a bridge library that allows to use React.js with QML.
Example

Usage of ReactQml is pretty straightforward — the only difference from web 
version is that you need to pass id of the qml item to React.render instead of 
DOM node. For example:

import QtQuick 2.4
import QtQuick.Controls 1.3
import "js/ReactQml.js" as React

ApplicationWindow {
id: root
title: qsTr("React QML")
width: 300
height: 300
visible: true

function reactRender(x, y) {
var props = {
x: 100,
y: 100,
width: 100,
height: 100,
color: '#000'
};
var childProps = {
x: 25,
y: 25,
width: 50,
height: 50,
color: '#fff'
};
var child = React.createElement(React.Rectangle, childProps);
React.render(React.createElement(React.Rectangle, props, child), root);
}

Component.onCompleted: {
reactRender();
}
}


-Ed

On May 2, 2016, at 1:50 PM, Robert Iakobashvili 
> wrote:

Dear Ekke,
Thank you for sharing your experience with
qt.labs.controls Qt Quick Controls2 in 5.7.

Sure, we'll be reading you blog.

Kind regards,
Robert


On Mon, May 2, 2016 at 8:38 PM, ekke 
> wrote:
I really like the new qt.labs.controls from Qt 5.6 (will become Qt Quick
Controls2 in 5.7)
using these lightweight controls together with Material Style (Android) or
Universal Style (Windows) with light or dark themes and all the new Controls
(like Drawer) for mobile-app-navigation and also HighDPI Support you can now
first time ever develop mobile apps with nearly native feeling. (iOS style
will come later when the new controls are stable)

I prefer to write UI in QML compared with React Native's mix of Markup and
JS or using Xamarin where you have one language but different code for
x-platform.

Before leaving QT for mobile apps - give it a try.
BTW: I'm writing a blog series about my experiences 
https://urldefense.proofpoint.com/v2/url?u=http-3A__j.mp_qt-2Dx=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=13ftz5U9_dHo8BjIh3RKmuX9DkqPXcAx9ctnx5a0YHA=
   and
I'll develop - as proof of concept - Conference APPs for QtCon and Qt World
Summit.

ekke

Am 02.05.16 um 20:17 schrieb Robert Iakobashvili:

Dear Edward,
React Native - good catch.

Thank you so much for sharing this idea
and your experience!

Kind regards,
Robert


On Mon, May 2, 2016 at 8:08 PM, Edward Sutton 
>
wrote:

On May 1, 2016, at 4:27 AM, Robert Iakobashvili 
> wrote:

Dear Edward,
What are your conclusions and which direction you decided on
after your experiments?


I never made much progress. While QML looked more "native like” I never felt
comfortable using it.

I am doing my new iOS and Android development using Facebook's react-native.
React Native calls native UI from Javascript.

https://urldefense.proofpoint.com/v2/url?u=https-3A__facebook.github.io_react-2Dnative_=CwIGaQ=G4BpsyPyB19LB50bn2swXw=cAG2c-SQES5P2qb8IW-uwnBOCX_f2qYJIlzenFnoHUc=5X_i0s6I6cbSYRP1ZGUPRMZL0OkDR9nmhuR8RAiIems=e9hAWWmY2S0Mo76_ex-_PF0NFk6ccgclP50872TSMfs=


When it makes sense I select UI components that have counterparts in Android
and iOS in order to increase code re-use.   I have seem claims of 85% code
re-use and from my experience  I do not doubt these claims.

So far, so good...

-Ed



Thanks,
Kind regards,
Robert


On Thu, Nov 5, 2015 at 2:40 PM, Edward Sutton 
>
wrote:

Hi Robert,

The approach you outlined below was the one I was considering. Use of common
C++ business layer, widgets for desktops, iOS native UI, and Android native
UI.

The Android native UI was my biggest concern.

I am going to continue experimenting with QML for a few more days


Hi Ben,

Thank you for sharing your Android UI interfacing code.  I will take a look.

Your iOS UI interfacing code was *very* helpful in understanding how to mix
C++ and Objective-C++ in the same *.mm file.  Java seems much more
challenging to interface to native UI.  However all I have done so far is
simple JNI calls into Java.

Thank you both,

-Ed


On Nov 5, 2015, at 1:51 AM, Ben Lau 
> wrote:


Not really a solution for wrapping Android UI in Qt app. But I have already
developed an image picker with native UI and communication library between
Qt and Java/Android. May be it could used as example / core framework.

Image Picker

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Nye]

>
> Well, that's not quite true of course. If you want to show a dialog
> created on the stack, you will have to use it's exec() method. That spins
> an event loop, and that means that a lot can happen in the mean time. It
> can vary from an incoming DBUS messages causing the application to
> terminate to something in response to a signal from that dialog itself, to
> some timer triggering a series of events that lead to the destruction of
> the parent.
>
So, in that sense, Nikos is right.
>
> I prefer just dealing with that using... new and ::open instead.
>

I don't mind your preference, everyone has theirs and I wouldn't presume to
tell people how to write their code. However I'd make two points here:
To delete the dialog's parent you would either call delete directly or use
`deleteLater`. It is true, of course, that QDialog::exec will start a
*local* event loop (do correct me if I'm wrong). However to call delete
directly on the dialog's parent you have to put it somewhere in your code
(presumably in the dialog itself, or in a slot somewhere, which is one of
the exceptions I was referring to: it's not a good idea to delete QObjects
inside slots directly, especially if the said object is the receiver; Qt
doesn't like that at all).

As for the second case where you'd connect to the deleteLater slot, this
wouldn't be an issue, since the deferred delete event is posted in the
*thread's
global* event loop and is not handled by the *local* event loops stack (and
that behavior is documented). So the delete event wouldn't be processed
until the control returns to the thread's event loop, thus the QDialog
would have already been deallocated.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[André Somers]

Op 05/05/2016 om 13:20 schreef Nye:
On Thu, May 5, 2016 at 4:22 AM, Nikos Chantziaras > wrote:


On 05/05/16 01:44, Nye wrote:

No one said it does. Perhaps I'm misunderstanding, are you
searching for
a silver bullet for memory management?


I already found it. Question is how to make Qt work with it :-)


You most certainly have not. I'm tired of repeating this, but here I 
go again: C++ IS NOT JAVA!



 > That's not good enough. I need to delete objects way before
their
parent is deleted.

So delete them. As I said, parent is notified of the child's
deletion.


If I delete them, the parent may already have deleted them. So I'd
have a double-delete.


We are running in a circle here. If the parent may delete the children 
before you've lost all the references to them, then use QPointer.


 > When 'parent' gets deleted before 'dialog', then 'dialog' gets
deleted even though it's on the stack.

And how does the parent gets deleted before the 'dialog' if I
may ask,
unless you're doing deletions from different threads ...?


I don't know. There's long call chains. Someone may delete the
parent. There's no way to know.


The whole premise behind Mr. Sommers' code was that this is in one 
function (one stack frame), so unless you do `delete this` in the 
middle of the function (directly or indirectly) there doesn't seem be 
a way the parent gets deleted.
Well, that's not quite true of course. If you want to show a dialog 
created on the stack, you will have to use it's exec() method. That 
spins an event loop, and that means that a lot can happen in the mean 
time. It can vary from an incoming DBUS messages causing the application 
to terminate to something in response to a signal from that dialog 
itself, to some timer triggering a series of events that lead to the 
destruction of the parent.


So, in that sense, Nikos is right.

I prefer just dealing with that using... new and ::open instead.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] using cmake to build Qt projects.

[André Pönitz]

On Thu, May 05, 2016 at 07:54:53AM -0400, william.croc...@analog.com wrote:
> 
> >
> >>I have never been able to get creator to work.  The 5 series won't even run
> >>under my versions of VNC and the NX virtual desktops.  This apparently due 
> >>to a
> >>dependency on new visual fluff.
> >
> >Qt Quick doesn't indeed not work well over VNC. The common workaround is to
> >not load Quick based plugins of which there are only few:
> >
> > path/to/qtcreator -noload Welcome
> >
> >The session handling bits of the Welcome screen are still independently
> >available in the 'Files' menu.
> >
> 
> Here is what happens when I try to run creator.
> Please excuse me for not imagining that there might
> be a command line option to resolve the issue.

Looks like there might be more plugins than the Welcome screen involved.
I can't tell from the output which one. In any case, my next attempt
would be white- instead of blacklisting plugins, i.e. something like

   bin/qtcreator -noload all -load QmakeProjectManager -load Debugger

(-noload all was new in 3.5)

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] using cmake to build Qt projects.

[william.croc...@analog.com]

I have never been able to get creator to work.  The 5 series won't even run
under my versions of VNC and the NX virtual desktops.  This apparently due to a
dependency on new visual fluff.


Qt Quick doesn't indeed not work well over VNC. The common workaround is to
not load Quick based plugins of which there are only few:

 path/to/qtcreator -noload Welcome

The session handling bits of the Welcome screen are still independently
available in the 'Files' menu.



Here is what happens when I try to run creator.
Please excuse me for not imagining that there might
be a command line option to resolve the issue.

:-)

Bill




qtcreator

QXcbConnection: Failed to initialize XRandr
SOFT ASSERT: "str && *str" in file 
/work/build/qt-creator/src/plugins/coreplugin/id.cpp, line 122
SOFT ASSERT: "str && *str" in file 
/work/build/qt-creator/src/plugins/coreplugin/id.cpp, line 122
SOFT ASSERT: "str && *str" in file 
/work/build/qt-creator/src/plugins/coreplugin/id.cpp, line 122
SOFT ASSERT: "str && *str" in file 
/work/build/qt-creator/src/plugins/coreplugin/id.cpp, line 122

Reading Qt Account settings from disk: "/home/whc/.local/share/Qt/qtaccount.ini"
Reading licenses from file: "/home/whc/.local/share/Qt/qtlicenses.ini"
License added. License id [ XXX ] License schema [ "Full Commercial" ] Licensed 
products [ "Enterprise" ] Licensed platforms [ ("X11", "Windows", "Mac") ] 
License expiry date [ QDate("2016-06-22") ]

Valid licenses found: 1
Sending license download request..
libGL error: failed to load driver: swrast
WARNING: Application 
/nobackup/whc/qt/Qt5.6.0/Tools/QtCreator/bin/qtcreatorp�a
 calling GLX 
1.3 function "glXCreatePbuffer" when GLX 1.3 is not supported!  This is an 
application bug!

QQuickWidget: Failed to make context current
QQuickWidget::resizeEvent() no OpenGL context

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Giuseppe D'Angelo]

On Thu, May 5, 2016 at 1:22 PM, Nikos Chantziaras  wrote:
> That doesn't do anything useful. I think you're missing the point here.

Did you try the earlier suggestion of using a QScopedPointer with a
custom deleter that holds a QPointer to the instance and deletes it
only if it has not been deleted already?

Cheers,

-- 
Giuseppe D'Angelo
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] using cmake to build Qt projects.

[André Pönitz]

On Thu, May 05, 2016 at 06:53:54AM -0400, Bill Crocker wrote:
> >>I am trying to port my Qt project to a cmake based build so I can use CLion
> >>for debugging.
> >
> >Why is CLion preferable for you to do Qt debugging, opposed to e.g. using Qt
> >Creator?
> >
> 
> Because CLion works out of the box and I am assuming that I can use it to 
> debug
> my app once I get it to build with cmake.

I would expect CLion to be able to debug your application but not have
specific support for Qt, like introspection of QObjects and containers
etc.
 
> I have never been able to get creator to work.  The 5 series won't even run
> under my versions of VNC and the NX virtual desktops.  This apparently due to 
> a
> dependency on new visual fluff.

Qt Quick doesn't indeed not work well over VNC. The common workaround is to
not load Quick based plugins of which there are only few:

path/to/qtcreator -noload Welcome

The session handling bits of the Welcome screen are still independently
available in the 'Files' menu.

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Nikos Chantziaras]

On 05/05/16 14:24, André Pönitz wrote:

On Thu, May 05, 2016 at 04:24:48AM +0300, Nikos Chantziaras wrote:

Well, basically what I want is not having even a single 'new' or 'delete'
anywhere in my code. I already achieved that with all my non-Qt projects.


remedyforirrationalfear.h:

  namespace snakeoil {
  template
  inline T* make_dynamic_object(Args&&... args)
 { return new T(std::forward(args)...); }
  }

myposhapp.cpp:

  #include "remedyforirrationalfear.h"

  // Oh Noes! Get out the garlic!
  // auto x = new X(23);
  auto x = snakeoil::make_dynamic_object(23);


By now, I consider application-level code that uses 'new' or 'delete' as
bogus and in need of fixing.


What a happy world we live in.


That doesn't do anything useful. I think you're missing the point here.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Nye]

On Thu, May 5, 2016 at 4:22 AM, Nikos Chantziaras  wrote:
>
> On 05/05/16 01:44, Nye wrote:
>
>> No one said it does. Perhaps I'm misunderstanding, are you searching for
>> a silver bullet for memory management?
>>
>
> I already found it. Question is how to make Qt work with it :-)
>
>
You most certainly have not. I'm tired of repeating this, but here I go
again: C++ IS NOT JAVA!


>
>  > That's not good enough. I need to delete objects way before their
>> parent is deleted.
>>
>> So delete them. As I said, parent is notified of the child's deletion.
>>
>
> If I delete them, the parent may already have deleted them. So I'd have a
> double-delete.


We are running in a circle here. If the parent may delete the children
before you've lost all the references to them, then use QPointer.


>  > When 'parent' gets deleted before 'dialog', then 'dialog' gets
>> deleted even though it's on the stack.
>>
>> And how does the parent gets deleted before the 'dialog' if I may ask,
>> unless you're doing deletions from different threads ...?
>>
>
> I don't know. There's long call chains. Someone may delete the parent.
> There's no way to know.
>

The whole premise behind Mr. Sommers' code was that this is in one function
(one stack frame), so unless you do `delete this` in the middle of the
function (directly or indirectly) there doesn't seem be a way the parent
gets deleted.


> Anyway, the question was whether Qt had something already in place. I now
> see I have to roll my own solution.


It has, it provides a battery of wrapper classes for pointers usable for
different cases. However I get the feeling this won't be just enough for
you.

Well, basically what I want is not having even a single 'new' or 'delete'
> anywhere in my code. I already achieved that with all my non-Qt projects.
>
By now, I consider application-level code that uses 'new' or 'delete' as
> bogus and in need of fixing.


Refer to my first comment at the very top of this mail, I know it's getting
repetitive, but ... C++ is not Java!

I completely disagree with you :-)
>
> I hope you're not the type of guy who writes code like this:
> [snippet]
> This is a nightmare, and this is C++ code that's indeed probably from 20
> years ago. If somebody writes code that like that today, I would want to
> hire them.


I would refer you the Qt's source, I'm sure you'll be terrified of the
amount of raw pointers used. Forgive my bluntness, but what would your
suggestion be then? Scoped pointers can be used, but that's not much
different that manually deleting the objects. And shared pointers are for
things you share, not for things you're too lazy to delete ...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[André Pönitz]

On Thu, May 05, 2016 at 04:24:48AM +0300, Nikos Chantziaras wrote:
> On 04/05/16 21:35, Thiago Macieira wrote:
> >On quarta-feira, 4 de maio de 2016 20:56:52 PDT Nikos Chantziaras wrote:
> >>  From what I can tell, QPointer does not delete the object, so that's a
> >>no go.
> >>
> >>Putting the objects on the stack doesn't work either, because the Qt
> >>object model does not support that (it will call 'delete' on the object
> >>even if it's on the stack.)
> >
> >So what are you requirements? Do you want to a container that does delete the
> >object it has, unless the parent has already deleted it?
> 
> Well, basically what I want is not having even a single 'new' or 'delete'
> anywhere in my code. I already achieved that with all my non-Qt projects.

remedyforirrationalfear.h:

 namespace snakeoil {
 template
 inline T* make_dynamic_object(Args&&... args)
{ return new T(std::forward(args)...); }
 }

myposhapp.cpp:

 #include "remedyforirrationalfear.h"

 // Oh Noes! Get out the garlic!
 // auto x = new X(23);
 auto x = snakeoil::make_dynamic_object(23);

> By now, I consider application-level code that uses 'new' or 'delete' as
> bogus and in need of fixing.

What a happy world we live in.

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] using cmake to build Qt projects.

[william.croc...@analog.com]

On 05/05/2016 06:08 AM, Jean-Michaël Celerier wrote:

 I am almost there, but when it links there are symbols undefined.
 From my experience the symbols I am seeing are typical of missing moc files.


You should still post your error messages I think, maybe it's some library that
Qt links automatically but that you have to link by hand with CMake ?


No. They were my symbols.

[Resolution]

Just as with qmake, one has to declare all of the .h files.
When I add the .h files to the add_executable() statement it
works. This so they can be MOCed.

Thanks.

Bill

I also had to add -pthread to my
set(CMAKE_CXX_FLAGS "-m32 -pthread").




On Wed, May 4, 2016 at 7:29 PM, william.croc...@analog.com
 > wrote:

On 05/04/2016 01:07 PM, Thiago Macieira wrote:

On quarta-feira, 4 de maio de 2016 10:08:27 PDT Bill Crocker wrote:

 From my experience the symbols I am seeing are typical of missing 
moc
files. I know I have all of my #include "abc.moc" statements in 
place
because my project builds fine with qmake.


That probably is. You need to tell cmake to handle the moc files. 
Either use
qt4_wrap_moc (or whatever the macro is called) or turn automoc on.


Per the inclusion of my cmake instruction file at the end of the post,
that is what I thought these two lines were for.

set(CMAKE_AUTOMOC TRUE)
set(CMAKE_INCLUDE_CURRENT_DIR ON)

___
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] using cmake to build Qt projects.

[Konstantin Tokarev]

05.05.2016, 13:54, "Bill Crocker" :
>>>  I am trying to port my Qt project to a cmake based build so
>>>  I can use CLion for debugging.
>>
>>  Why is CLion preferable for you to do Qt debugging, opposed to
>>  e.g. using Qt Creator?
>
> Because CLion works out of the box and I am assuming
> that I can use it to debug my app once I get it to build
> with cmake.
>
> I have never been able to get creator to work.
> The 5 series won't even run under my versions
> of VNC and the NX virtual desktops. This apparently
> due to a dependency on new visual fluff.

Run it with -noload welcome first time, then disable Welcome plugin in menu.

-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] using cmake to build Qt projects.

[Bill Crocker]

I am trying to port my Qt project to a cmake based build so
I can use CLion for debugging.


Why is CLion preferable for you to do Qt debugging, opposed to
e.g. using Qt Creator?



Because CLion works out of the box and I am assuming
that I can use it to debug my app once I get it to build
with cmake.

I have never been able to get creator to work.
The 5 series won't even run under my versions
of VNC and the NX virtual desktops. This apparently
due to a dependency on new visual fluff.

Bill
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Nikos Chantziaras]

I completely disagree with you :-)

I hope you're not the type of guy who writes code like this:

  something;
  if (!something) {
  delete;
  return;
  }
  something else;
  if (!something else) {
  delete;
  return;
  }
  try {
 do stuff;
  }
  catch (...) {
  delete;
  throw;
  }

This is a nightmare, and this is C++ code that's indeed probably from 20 
years ago. If somebody writes code that like that today, I would want to 
hire them.



On 05/05/16 10:18, Bo Thorsen wrote:

I'm still not sure if I should respond to this or not. You're clearly
trying to solve an unsolvable problem.

This mail is going to sound like a rant, because I've heard those types
of arguments from Qt newbies again and again. But it's actually not.
There's information here that will lead you to a code style that fits
the Qt memory model. Not your memory model.

First, you need to listen to this and fully understand it: There is *no*
way you can code C++ so memory errors are impossible.

Using smart pointers is just a silly pipe dream of the nineties that
unfortunately hasn't gone away. As Herb Sutter (I think, not completely
sure) once said: "Smart pointers is a solution in search of a problem".

Smart pointers is good for one thing only: To delete objects that
control their own life span.

For all other - and that's 99.9% - objects, it's cleaner simpler and
more efficient if you get rid of the notion that a system can do it for
you, and start giving clear lifetime ownership of your objects.

Yes, you can get crashes or memory loss. That's why you don't hire crap
coders to do C++, and check your code with tools like valgrind.

I'm sure you will have a long list of objections as to why I'm
completely wrong. Shared pointer lovers usually do. I don't care. I've
been doing Qt coding for 20 years and have tried every trick available
and come to the conclusion that it's actually only up to me writing good
code.

I hope this helps. I give the same type of arguments to my customers.
The smart ones get it, the others pay with increased maintenance cost
over the years.

Bo Thorsen,
Director, Viking Software.




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Konstantin Tokarev]

05.05.2016, 13:16, "Jean-Michaël Celerier" :
> On Thu, May 5, 2016 at 3:24 AM, Nikos Chantziaras  wrote:
>> By now, I consider application-level code that uses 'new' or 'delete' as 
>> bogus and in need of fixing.
> This line of thought doesn't work at all with Qt. It's just how it is done. 
> If you are in such dire need of guaranteeing the absence of memory problems :
>
> template
> auto make_qobject(Args&&... args, QObject* parent) // Repeat for 
> QGraphicsItem / Object if necessary
> {
>     assert(parent);
>     return new T{std::forward(args)..., parent};
> }
>
> QMainWindow win;
> auto safe_obj_1 = make_qobject ();
> auto safe_obj_2 = make_qobject();

Nevertheless that won't save from memory problems when parent needs to have 
longer lifetime then its children


-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[Jean-Michaël Celerier]

On Thu, May 5, 2016 at 3:24 AM, Nikos Chantziaras  wrote:

>
> By now, I consider application-level code that uses 'new' or 'delete' as
> bogus and in need of fixing.


This line of thought doesn't work at all with Qt. It's just how it is done
. If you are in such dire need of
guaranteeing the absence of memory problems :

template
auto make_qobject(Args&&... args, QObject* parent) // Repeat for
QGraphicsItem / Object if necessary
{
assert(parent);
return new T{std::forward(args)..., parent};
}

QMainWindow win;
auto safe_obj_1 = make_qobject ();
auto safe_obj_2 = make_qobject();
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] using cmake to build Qt projects.

[Jean-Michaël Celerier]

> I am almost there, but when it links there are symbols undefined.
> From my experience the symbols I am seeing are typical of missing moc
files.

You should still post your error messages I think, maybe it's some library
that Qt links automatically but
that you have to link by hand with CMake ?


On Wed, May 4, 2016 at 7:29 PM, william.croc...@analog.com <
william.croc...@analog.com> wrote:

> On 05/04/2016 01:07 PM, Thiago Macieira wrote:
>
>> On quarta-feira, 4 de maio de 2016 10:08:27 PDT Bill Crocker wrote:
>>
>>>From my experience the symbols I am seeing are typical of missing moc
>>> files. I know I have all of my #include "abc.moc" statements in place
>>> because my project builds fine with qmake.
>>>
>>
>> That probably is. You need to tell cmake to handle the moc files. Either
>> use
>> qt4_wrap_moc (or whatever the macro is called) or turn automoc on.
>>
>>
> Per the inclusion of my cmake instruction file at the end of the post,
> that is what I thought these two lines were for.
>
> set(CMAKE_AUTOMOC TRUE)
> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>
> ___
> 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] What's the recommended way to put QObjects in smart pointers?

[Bo Thorsen]

Den 04-05-2016 kl. 16:48 skrev Nikos Chantziaras:

I've been removing every trance of 'new' and 'delete' from my code and
switching to something like:

  auto obj = std::make_unique(ctor args);

(Or std::make_shared, depending on the situation.)

But for QObjects with a parent, that can go horribly wrong. So I have to
do annoying stuff like:

  auto dialog = new QDialog(parent);
  // work...
  delete dialog;

Yes, 'parent' will eventually delete 'dialog', but that doesn't help
much when 'parent' is a long lived object (like the main application
window.)

Is there a Qt-specific idiom where I can manage QObjects that have a
parent with a smart pointer and not have to worry about double-deletion?

Or, to phrase it in another way, is there a way to eliminate the 'new'
keyword completely from my code-base when using QObjects with a parent?


I'm still not sure if I should respond to this or not. You're clearly 
trying to solve an unsolvable problem.


This mail is going to sound like a rant, because I've heard those types 
of arguments from Qt newbies again and again. But it's actually not. 
There's information here that will lead you to a code style that fits 
the Qt memory model. Not your memory model.


First, you need to listen to this and fully understand it: There is *no* 
way you can code C++ so memory errors are impossible.


Using smart pointers is just a silly pipe dream of the nineties that 
unfortunately hasn't gone away. As Herb Sutter (I think, not completely 
sure) once said: "Smart pointers is a solution in search of a problem".


Smart pointers is good for one thing only: To delete objects that 
control their own life span.


For all other - and that's 99.9% - objects, it's cleaner simpler and 
more efficient if you get rid of the notion that a system can do it for 
you, and start giving clear lifetime ownership of your objects.


Yes, you can get crashes or memory loss. That's why you don't hire crap 
coders to do C++, and check your code with tools like valgrind.


I'm sure you will have a long list of objections as to why I'm 
completely wrong. Shared pointer lovers usually do. I don't care. I've 
been doing Qt coding for 20 years and have tried every trick available 
and come to the conclusion that it's actually only up to me writing good 
code.


I hope this helps. I give the same type of arguments to my customers. 
The smart ones get it, the others pay with increased maintenance cost 
over the years.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest