On 9 April 2015 at 17:08, Joerg Bornemann
wrote:
> On 08-Apr-15 17:45, Sze Howe Koh wrote:
>
>> May I suggest adding a bit of documentation on our side to help people
>> discover the features? Currently,
>> http://doc.qt.io/qt-5/qjsengine.html#script-exceptions only recommends
>> using toString()
On 9 April 2015 at 19:17, Simon Hausmann
wrote:
>
> On Thursday 9. April 2015 11.52.31 Simon Hausmann wrote:
> > On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote:
> > [...]
> >
> > > Going off on a slight tangent:
> > > https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is
>
On Tuesday April 14 2015 15:58:20 Thiago Macieira wrote:
> They may not have noticed they're broken, but they're broken.
Ok then
> > If those that break can be fixed with a simple invocation of a new
> > mechanism provided exactly
^
shatter into pieces
>
On Tuesday 14 April 2015 21:26:40 René J.V. Bertin wrote:
> Between a rock and a hard place one could opt for a compromise. You're
> planning to introduce changes to QtDBus that may break things. Applications
> that don't break because of it don't need a solution. If those that break
> can be fixed
On Tuesday April 14 2015 09:27:34 Thiago Macieira wrote:
> On Tuesday 14 April 2015 17:53:20 René J.V. Bertin wrote:
> > This may be an open door, but couldn't you change the application's entry
> > point (or provide an alternative entry point like KDE does with kdemain).
> > That gives you an extr
On Tuesday 14 April 2015 14:37:25 Matthew Woehlke wrote:
> Would it be horrible to add a new method, e.g. shutdown(), which
> subclasses are required to call in their dtor? It won't fix existing
> applications, but it at least provides a mechanism to make things work.
Same answer as I gave to Juli
On Tuesday 14 April 2015 19:55:47 Julien Cugnière wrote:
> 2015-04-14 16:36 GMT+02:00 Thiago Macieira :
> > 2) fix it by not passing through notify() outside the main thread. That's
> > the solution I implemented in I27eaacb532114dd188c413d4ad2a4bb443e6.
>
> People rely on QCoreApplication::not
On 2015-04-14 12:27, Thiago Macieira wrote:
> The problem is the public, *user* class if they derived from QApplication.
>
> If they've overridden notify(), then I need to know when the *user* class
> begins destruction so that we stop calling notify().
Would it be horrible to add a new method,
> On 14 Apr 2015, at 19:45, Nicolás Ulrich wrote:
>
> I would love to try this so any name is good for me. I was just starting to
> develop something for android (in java) just because qtquickcontrols doesn't
> feel right. This however is really encouraging.
This is looking very promising, but
> On 14 Apr 2015, at 18:14, Jeremy Lainé wrote:
>
> On 04/13/2015 03:46 PM, Nurmi J-P wrote:
>> On 13 Apr 2015, at 14:50, Jeremy Lainé wrote:
>>
>>> How about just "android-controls", which would become
>>> "qt-android-controls" if the project graduates from playground?
>> I like this suggestio
2015-04-14 16:36 GMT+02:00 Thiago Macieira :
>
> 2) fix it by not passing through notify() outside the main thread. That's the
> solution I implemented in I27eaacb532114dd188c413d4ad2a4bb443e6.
>
People rely on QCoreApplication::notify to provide a try/catch when
working with Qt and exceptions
On Tue, Apr 14, 2015 at 1:14 PM, Jeremy Lainé wrote:
>
> On 04/13/2015 03:46 PM, Nurmi J-P wrote:
> > On 13 Apr 2015, at 14:50, Jeremy Lainé wrote:
> >
> >> How about just "android-controls", which would become
> >> "qt-android-controls" if the project graduates from playground?
> > I like this s
On Tuesday 14 April 2015 17:53:20 René J.V. Bertin wrote:
> This may be an open door, but couldn't you change the application's entry
> point (or provide an alternative entry point like KDE does with kdemain).
> That gives you an extra layer around what the user sees as the main
> function.
I don
On Tuesday 14 April 2015 18:36:16 Robert Iakobashvili wrote:
> > The problem here is that QCoreApplication is not reference counted and we
> > can't change it without breaking *every* *single* *application*, since
> > this is what people usually do:
> C++ idiom with protected destructor
> enforces
On 04/13/2015 03:46 PM, Nurmi J-P wrote:
> On 13 Apr 2015, at 14:50, Jeremy Lainé wrote:
>
>> How about just "android-controls", which would become
>> "qt-android-controls" if the project graduates from playground?
> I like this suggestion. In the end we will have much more (*) than just UI
> con
On Tuesday April 14 2015 08:27:57 Thiago Macieira wrote:
>C++ already has that, it's called reference counting. You may have heard we
>use it in Qt :-)
Well, reference counting can be used for many things (like deleteLater, I
presume) :)
>The problem here is that QCoreApplication is not refere
On Tue, Apr 14, 2015 at 6:27 PM, Thiago Macieira
wrote:
> On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote:
> [cut]
>> ObjC is so intricately linked to OS X, because from a few quick attempts it
>> seems to be perfectly possible to use an ObjC++ wrapper class to extend the
>> retain/releas
On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote:
[cut]
> ObjC is so intricately linked to OS X, because from a few quick attempts it
> seems to be perfectly possible to use an ObjC++ wrapper class to extend the
> retain/release scheme to C++ classes.
>
> Is this clear enough?
Yes, thank
On Tuesday April 14 2015 07:28:03 Thiago Macieira wrote:
>On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote:
>I don't know how to answer this since I have no idea what retain/release is
>and does. Can you explain?
OK, sorry, I thought you had sufficient knowledge of ObjC programming (from
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 conditions.
if (self)
return self->notify(object, event);
On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote:
> On Monday April 13 2015 21:12:58 Thiago Macieira wrote:
>
> Hello,
>
> >> I'd like some opinions on whether we should try this or not.
> >
> >Note another problem: if a thread is running and delivering events while
> >the QCoreApplicatio
On Monday 13. April 2015 21.12.58 Thiago Macieira wrote:
> On Monday 13 April 2015 13:23:29 Thiago Macieira wrote:
> > On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote:
> > > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote:
> > > > > Finally, note what happens if there's a thre
On Tuesday 14. April 2015 08.33.06 Mathias Hasselmann wrote:
> So we finally have reached the turning point at which we have no chance
> but to make C++11 mandatory for public Qt headers:
You might think you're trolling, but I think requiring C++11 would be an
excellent goal for Qt 6.
- Paul
___
On Monday April 13 2015 22:11:51 René J.V. Bertin wrote:
>The culprit is probably the failure to find filterIncludePath and
>filterLibraryPath . Where are those supposed to be found?
I think I found my answer:
http://git.buildroot.net/buildroot/diff/?id=b37f428bacdca7859fb0b678ec9658cbccaa359a
On Monday April 13 2015 21:12:58 Thiago Macieira wrote:
Hello,
>> I'd like some opinions on whether we should try this or not.
>
>Note another problem: if a thread is running and delivering events while the
>QCoreApplication gets destroyed, the application will have several race
>conditions:
>
25 matches
Mail list logo
