Re: [Development] Specifying module dependencies

On Friday, June 12, 2015 09:47:44 AM Oswald Buddenhagen wrote: > On Thu, Jun 11, 2015 at 08:30:37PM +, Gladhorn Frederik wrote: > > On Thursday 11. June 2015 18.47.40 Oswald Buddenhagen wrote: > > > you won't get rid of the redundant dependency specifications anyway, > > > because qt.pro (and t

Re: [Development] Some Qt3D feedback

On Thursday, June 11, 2015 11:49:23 AM Marc Mutz wrote: > On Wednesday 10 June 2015 21:03:32 Stephen Kelly wrote: > > I would encourage a discussion of why this module needs namespaces when > > the rest of Qt gets by without them. There is certainly a consistency > > angle. > > I think you come a

[Development] Fwd: (QTBUG-46655) qt5base: font license files missing

The file qtbase-opensource-src-5.4.2/lib/fonts/README states: 'Copyright statements and the source of the qpf fonts are located in ../../src/3rdparty/fonts' The directory src/3rdparty/fonts does not exist in qtbase-opensource- src-5.4.2.tar.xz archive. This directory exists in the 'old' qt-4.8.7

Re: [Development] Avoid overloading of 'error'

Hasn't it already been decided to change the name? +1 for that. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Olivier Goffart Sent: Sunday, June 14, 2015 10:05 PM To: development@qt-project.org Subject: Re:

Re: [Development] Avoid overloading of 'error'

Should we re-target the discussion to the problem at hand? The problem is that error is overloaded and that is annoying when connecting to it. Renaming it would be one way to solve the problem. (e.g: adding a second signal that is emitted at the same time and possibly deprecate the old one) Non

Re: [Development] Avoid overloading of 'error'

"err" is the verb. To err is human. onErr: to forgive is divine. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Thiago Macieira Sent: Sunday, June 14, 2015 6:55 PM To: development@qt-project.org Subject: Re:

Re: [Development] QVariantMap <-> QML

Hi, This is a result of QVariant being a value type. If you make a copy and modify it, then the original remains as-is. The call to setContextProperty creates a copy. If you want explicitly shared data between the JavaScript environment and C++ then I would recommend using a JavaScript object -

Re: [Development] QVariantMap <-> QML

Ben Lau , 15.06.2015 01:45: > var tmp = myMap.asdf; > tmp.name = "asdf" > myMap.asdf = tmp; Thanks for the fast reply! Unfortunately, this approach is very cumbersome for deeper hierarchies like: a.b.c.d[2].e.f = "g" I was hoping for a more convenient solution. Best regards Gerhard

Re: [Development] QVariantMap <-> QML

On 15 June 2015 at 01:43, Gerhard Scheikl wrote: > Hi > > I recently discovered some unexpected behavior when exchanging a > QVariantMap > with QML code: > > Here's what I'm doing on the C++ side: > my_map = json_document.toVariant(); > engine.rootContext()->setContextProperty("myMap", my_map); >

[Development] QVariantMap <-> QML

Hi I recently discovered some unexpected behavior when exchanging a QVariantMap with QML code: Here's what I'm doing on the C++ side: my_map = json_document.toVariant(); engine.rootContext()->setContextProperty("myMap", my_map); Then on the QML side: myMap.asdf.name = "asdf" This change is not

Re: [Development] QtCS: Notes from Modern C++ session

On Sunday 14 June 2015 14:00:03 Marc Mutz wrote: > So, we might as well remove Q_DECL_EQ_DEFAULT, I think. Agreed, since it does not mean the same thing to have and not to have it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center

Re: [Development] QtCS: Notes from Modern C++ session

On Saturday 13 June 2015 19:33:14 Gunnar Roth wrote: > Not available for use are: > * = default, > * = deleted, > >> > >> Where are these not supported? I have code that (AFAIK) has been using > >> these already, and IIRC our compiler requirements are lower. > > > > GCC requires 4.

Re: [Development] Avoid overloading of 'error'

On Sunday 14 June 2015 15:35:37 Lorn Potter wrote: > On 14/06/2015 1:01 pm, Alan Alpert wrote: > > On Sat, Jun 13, 2015 at 12:42 PM, Lorn Potter wrote: > >> On 11/06/2015 12:36 am, Samuel Gaist wrote: > >>> failed doesn't always mean there was an error with a direct relation. > >> > >> I was goi

Re: [Development] QtCS: Notes from Modern C++ session

On Sunday 14 June 2015 12:06:21 Knoll Lars wrote: [ regarding = default, = delete ] > The main place where we use this feature is anyway with Q_DISABLE_COPY. So > for now, I don't think it's a huge problem if we can't use those. That's = delete, yes, and you can always make those into linker error

Re: [Development] QtCS: Notes from Modern C++ session

On 13/06/15 19:33, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Gunnar Roth" mailto:development-bounces+lars.knoll=theqtcompany@qt-project.org> on behalf of gunnar.r...@gmx.de