[Development] Qt Installer (1.5.0) uninstaller customization

Hello All, How can I control the uninstaller to check program is running or not before uninstalling program in Qt installer version 1.5.0 ? Actually, I could do this in 2.0.0 with controller script but then there is a bug: https://bugreports.qt.io/browse/QTIFW-659 and it is not seen in 1.5.0 vers

Re: [Development] Qt Installer (1.5.0) uninstaller customization

> -Original Message- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > Subject: [Development] Qt Installer (1.5.0) uninstaller customization > > Hello All, > > How can I control the uninstaller to check program is running or not before > uninstalling program in Qt installer ve

[Development] Qt5.4.2 snapshot available

Hi all, Qt 5.4.2 snapshot finally available. Windows: http://download.qt.io/snapshots/qt/5.4/5.4.2/2015-04-14_118/ Linux: http://download.qt.io/snapshots/qt/5.4/5.4.2/2015-04-14_121/ Mac: http://download.qt.io/snapshots/qt/5.4/5.4.2/2015-04-14_107/ Most of installers are there, only windows

Re: [Development] Allowing event delivery prior to and after QCoreApplication

On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote: > On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote: > > Would it be feasible to make event loops started before and after > > QCoreApplication truly independent from notify() but all the others "join" > > in? > > Not without race cond

Re: [Development] Allowing event delivery prior to and after QCoreApplication

On 15/04/15 11:30, "Simon Hausmann" wrote: >On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote: >> On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote: >> > Would it be feasible to make event loops started before and after >> > QCoreApplication truly independent from notify() but all the

[Development] RFC: RAII for property changes

Hi, When writing QObject-derived classes with properties, I often found myself writing code like this: void MyClass::setFoo(QString value) { if (m_foo != value) { m_foo = value; emit fooChanged(m_foo); } } Trivial enough, in the simple case. However, when more than one property

Re: [Development] Allowing event delivery prior to and after QCoreApplication

Knoll Lars schreef op 15-4-2015 om 11:39: > Well, I’d say we should try to see how much this is being used. I > don’t think we ourselves use it at all. How much is this used in other > projects? The central notify() hook is something I don’t like at all. > It’s very easy to mess things up using

Re: [Development] RFC: RAII for property changes

Hi, On Wed, Apr 15, 2015 at 11:49 AM, André Somers wrote: > That's why I have been working with a RAII implementation to monitor > property changes for a while now. This looks like an interesting idea. Another issue I often have with properties is performance related. Imagine a model that has m

Re: [Development] Allowing event delivery prior to and after QCoreApplication

2015-04-14 20:39 GMT+02:00 Thiago Macieira : > > We removed the try/catch and replaced with stack objects that will unwind > properly. If you're lucky, an exception will simply unwind QCoreApplication > out of exec(), so a try/catch around exec() may work. > > But this is untested and unsupported.

Re: [Development] RFC: RAII for property changes

Hi André, On Wednesday 15 April 2015 11:49:56 André Somers wrote: > void MyClass::setFoo(QString value) > { >PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >Q_UNUSED(guard); > >m_foo = value; > } This is an interesting idea, though I don't think I have encount

Re: [Development] RFC: RAII for property changes

On Wed, Apr 15, 2015 at 9:38 AM Marc Mutz wrote: > Hi André, > > On Wednesday 15 April 2015 11:49:56 André Somers wrote: > > void MyClass::setFoo(QString value) > > { > >PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY > >Q_UNUSED(guard); > > > >m_foo = value; >

Re: [Development] RFC: RAII for property changes

Hi Marc, Thank you for responding. Marc Mutz schreef op 15-4-2015 om 16:43: > Hi André, > > On Wednesday 15 April 2015 11:49:56 André Somers wrote: >> void MyClass::setFoo(QString value) >> { >> PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >> Q_UNUSED(guard); >>

Re: [Development] RFC: RAII for property changes

On 2015-04-15 10:43, Marc Mutz wrote: > On Wednesday 15 April 2015 11:49:56 André Somers wrote: >> void MyClass::setFoo(QString value) >> { >>PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >>Q_UNUSED(guard); >> >>m_foo = value; >> } > > This is an interesting id

Re: [Development] Allowing event delivery prior to and after QCoreApplication

On Wednesday 15 April 2015 15:01:29 Julien Cugnière wrote: > > But this is untested and unsupported. DO NOT throw through the event loop > > and DO NOT throw back to the signal-slot delivery mechanism. We will not > > deal with bug reports that this does not work. I may accept patches that > > fix

Re: [Development] RFC: RAII for property changes

[Valid points about the inconsistent state of the object elided.] On 2015-04-15 10:58, André Somers wrote: > What if that slot [connected to the instance property changed > signal] triggers something that ends up deleting the instance? Then the slot is broken. What if the sender needs to do somet

Re: [Development] Allowing event delivery prior to and after QCoreApplication

On Wednesday 15 April 2015 11:56:04 André Somers wrote: > We use it in our applications. It is used indeed as a catch-all > exception handler (I'm not a fan, but ok), but a useful use we also have > that we use it as a debug device to get more insight into what events > are send around the system,

Re: [Development] RFC: RAII for property changes

On 04/15/2015 05:12 PM, Matthew Woehlke wrote: > [Valid points about the inconsistent state of the object elided.] > > On 2015-04-15 10:58, André Somers wrote: >> What if that slot [connected to the instance property changed >> signal] triggers something that ends up deleting the instance? > > Then

Re: [Development] RFC: RAII for property changes

On 15-4-2015 16:54, Keith Gardner wrote: On Wed, Apr 15, 2015 at 9:38 AM Marc Mutz > wrote: Hi André, On Wednesday 15 April 2015 11:49:56 André Somers wrote: > void MyClass::setFoo(QString value) > { >PropertyGuard guard(this, "foo"); //foo

Re: [Development] RFC: RAII for property changes

On 15-4-2015 17:08, Matthew Woehlke wrote: > On 2015-04-15 10:43, Marc Mutz wrote: >> On Wednesday 15 April 2015 11:49:56 André Somers wrote: >>> void MyClass::setFoo(QString value) >>> { >>> PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >>> Q_UNUSED(guard); >>> >>>

Re: [Development] RFC: RAII for property changes

On 2015-04-15 12:29, Andre Somers wrote: > On 15-4-2015 17:08, Matthew Woehlke wrote: >> What about something like this? >> >>QPropertyGuard g{this}; >>g.addProperty("a"); // use QObject::property >>g.addProperty("b", m_b); // take value member by reference >>g.addProperty(m_c, &cCh

Re: [Development] RFC: RAII for property changes

> > I'd certainly be interested to seeing how you solved this, yes. Thanks! > I have made a repository for the class with an example. Sorry that there is no documentation for it. It requires C++11 support for r-value references, std::functional, and some type traits features. In addition to hav

Re: [Development] RFC: RAII for property changes

On 15-4-2015 18:44, Matthew Woehlke wrote: > The second form would thus save the value <-> QVariant comparison and > not much else. The third form however eliminates the string look-up > entirely by having the user provide both the backing member variable > *and* what to do when a change should

Re: [Development] RFC: RAII for property changes

On 15 April 2015 at 17:12, Matthew Woehlke wrote: > > Then the slot is broken. What if the sender needs to do something after > it delivers the signal? What if other slots are connected? Deleting a > signal sender from a slot connected to the signal is inherently > dangerous. Don't do it. For the

Re: [Development] RFC: RAII for property changes

On Wed, Apr 15, 2015 at 8:08 AM, Matthew Woehlke wrote: > On 2015-04-15 10:43, Marc Mutz wrote: >> On Wednesday 15 April 2015 11:49:56 André Somers wrote: >>> void MyClass::setFoo(QString value) >>> { >>>PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >>>Q_UNUSED(gua

Re: [Development] RFC: RAII for property changes

On 2015-04-15 13:55, Alan Alpert wrote: > The common case is one property I think, so keep that case to one > line. I'd envision using it in all my basic setters to save code at > the start of a project, and then when the features start to creep in > it's easier to add complexity into the setters.

Re: [Development] Allowing event delivery prior to and after QCoreApplication

2015-04-15 17:11 GMT+02:00 Thiago Macieira : > Not exactly. It all depends on what you define to be "works". I don't consider > resuming the event loop to be "works". I think that an uncaught exception > should exit the event loop and cause the application to exit, so I consider > your code above b

Re: [Development] RFC: RAII for property changes

On Wednesday 15 April 2015 17:08:11 Matthew Woehlke wrote: > FWIW I had the same thought; also, I'm not a fan of needing the > Q_UNUSED, or using a macro to 'hide' it. I haven't had to use Q_UNUSED on a RAII object since iirc GCC 3 times. What broken compilers are you guys using? > What about so

Re: [Development] RFC: RAII for property changes

> > > QPropertyGuard g{this}; > > g.addProperty("a"); // use QObject::property > > g.addProperty("b", m_b); // take value member by reference > > g.addProperty(m_c, &cChanged); // ...and also slot address > > There's type erasure going on, so it will allocate memory. Allocating > memory > i

Re: [Development] RFC: RAII for property changes

On 15-4-2015 21:05, Keith Gardner wrote: > QPropertyGuard g{this}; > g.addProperty("a"); // use QObject::property > g.addProperty("b", m_b); // take value member by reference > g.addProperty(m_c, &cChanged); // ...and also slot address There's type erasure going on, s

Re: [Development] RFC: RAII for property changes

On Wednesday 15 April 2015 16:58:24 André Somers wrote: > Basically, if you have this code (or something like it) somewhere, you > already have a problem: > > void MyClass::setFooAndBar(QString foo, int bar) > { >if (m_foo != foo) { > m_foo = foo; > emit fooChanged(foo); //this is

Re: [Development] RFC: RAII for property changes

On Wed, Apr 15, 2015 at 2:20 PM Andre Somers wrote: > On 15-4-2015 21:05, Keith Gardner wrote: > > > QPropertyGuard g{this}; >> > g.addProperty("a"); // use QObject::property >> > g.addProperty("b", m_b); // take value member by reference >> > g.addProperty(m_c, &cChanged); // ...and als

Re: [Development] RFC: RAII for property changes

On Wednesday 15 April 2015 21:05:39 Keith Gardner wrote: > Would something like this be better? > > std::function No, a std::function in general allocates memory and even if it uses the small object optimisation, the call to the lambda will still be indirect. Thanks, Marc -- Marc Mutz | Seni

Re: [Development] Allowing event delivery prior to and after QCoreApplication

On Wednesday 15 April 2015 20:49:42 Julien Cugnière wrote: > The idea is that we have threads which serve requests from other > threads through the use of slots. When an exception is thrown during > the processing of such a slot, it means the request encountered a > fatal error and was aborted. But