Re: [Development] The place of QML

DEFIB. all of these are replies to comments in http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/ which Marius Storm-Olsen decided to close Donald http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72564 + others >We are putting serious effort into QML and hope to disrupt

Re: [Development] UDS feedback

On 05/22/2012 01:27 AM, ext Girish Ramakrishnan wrote: >> I think the most important part is that we actually have a reasonable, auto- >> detected default. If the application is run under Wayland, it loads the >> Wayland plugin. > > Currently, our default on each platform is hardcoded. > Windows -

Re: [Development] Compiler errors with clang 3.1

On Monday 21 May 2012 18:01:22 Stephen Chu wrote: > On 5/21/12 5:22 PM, Thiago Macieira wrote: > > On segunda-feira, 21 de maio de 2012 17.07.51, Stephen Chu wrote: > >> On 5/21/12 4:28 PM, Thiago Macieira wrote: > >>> On sexta-feira, 18 de maio de 2012 16.56.09, Stephen Chu wrote: > On the ot

Re: [Development] Compiler errors with clang 3.1

On segunda-feira, 21 de maio de 2012 18.01.22, Stephen Chu wrote: > Q_DECL_CONSTEXPR inline QByteArray(QByteArrayDataPtr dd) > > : d(reinterpret_cast(dd.ptr)) > > { > } > > And I don't think it can ever be made a constexpr. I agree. -- Thiago Macieira - thiago.macieira (AT)

Re: [Development] Compiler errors with clang 3.1

On 5/21/12 5:22 PM, Thiago Macieira wrote: > On segunda-feira, 21 de maio de 2012 17.07.51, Stephen Chu wrote: >> On 5/21/12 4:28 PM, Thiago Macieira wrote: >>> On sexta-feira, 18 de maio de 2012 16.56.09, Stephen Chu wrote: On the other hand, compiling using gcc 4.7 is successful. I am not su

Re: [Development] Compiler errors with clang 3.1

On segunda-feira, 21 de maio de 2012 17.07.51, Stephen Chu wrote: > On 5/21/12 4:28 PM, Thiago Macieira wrote: > > On sexta-feira, 18 de maio de 2012 16.56.09, Stephen Chu wrote: > >> On the other hand, compiling using gcc 4.7 is successful. I am not sure > >> if gcc is more lex on this or Q_DECL_C

Re: [Development] Compiler errors with clang 3.1

On 5/21/12 4:28 PM, Thiago Macieira wrote: > On sexta-feira, 18 de maio de 2012 16.56.09, Stephen Chu wrote: >> On the other hand, compiling using gcc 4.7 is successful. I am not sure >> if gcc is more lex on this or Q_DECL_CONSTEXPR macro is not defined. > > GCC seems to be more lax. I recommend p

[Development] looking for chart examples

Are there any examples on line for implementing the qt chart widget?I need to implement 15 charts on a single panel. Thank You ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiler errors with clang 3.1

On sexta-feira, 18 de maio de 2012 16.56.09, Stephen Chu wrote: > On the other hand, compiling using gcc 4.7 is successful. I am not sure > if gcc is more lex on this or Q_DECL_CONSTEXPR macro is not defined. GCC seems to be more lax. I recommend providing us with fixes to make Qt compile under th

Re: [Development] Compiler errors with clang 3.1

On 5/18/12 4:56 PM, Stephen Chu wrote: > > > I tried both MacPort clang 3.1 and Apple's so-called LLVM 4.0 to build > Qt and create apps with C++11 turned on. Both failed with constexpr errors. > > On the other hand, compiling using gcc 4.7 is

Re: [Development] QUrl fully-decoded path API

On segunda-feira, 14 de maio de 2012 18.29.23, Thiago Macieira wrote: > == Proposal 2 => > So instead of adding decodedPath(), decodedUserName(), decodedPassword(), > etc. and cluttering the Qt5 QUrl API like the Qt4 one was, there's a > separate proposal: > > - add an option to QUrl::ComponentFor

Re: [Development] UDS feedback

On Mon, May 14, 2012 at 2:28 AM, Oswald Buddenhagen wrote: > On Sat, May 12, 2012 at 12:13:09PM -0700, ext Girish Ramakrishnan wrote: >> 2. Rename our qt5 tool binaries - the binary names of moc, uic, qmake >> conflict in qt3 and qt4. Now with qt5, we will have another conflict. >> Is it possible

Re: [Development] UDS feedback

On Sat, May 12, 2012 at 1:34 PM, Thiago Macieira wrote: > On sábado, 12 de maio de 2012 12.13.09, Girish Ramakrishnan wrote: >> 5. QPA plugins + packaging: One can install the wayland and xcb plugin >> simultaneously. We need a mechanism to switch the QPA plugin globally >> for all apps. One can u

Re: [Development] [Qt-l10n] Using Transifex for handling Qt localization?

On Mon, May 21, 2012 at 1:20 AM, Oswald Buddenhagen wrote: > On Mon, May 21, 2012 at 12:13:41AM +0200, ext Gábor Garami wrote: >> Btw, I cannot imagine why Nokia (and previously Trolltech) do not foucus to >> Linguist to improve it and make it as a best translation software. > > let's put it that

Re: [Development] Mutex future directions

On segunda-feira, 21 de maio de 2012 08.34.32, bradley.hug...@nokia.com wrote: > On May 18, 2012, at 8:34 PM, ext Thiago Macieira wrote: > > Recommendations (priority): > > > > (P0) de-inline QBasicMutex locking functions until we solve some or all of > > the below problems > > I agree with this, s

Re: [Development] License for Qt Desktop Components

I agree and cleaning up the mess is long overdue. The non-commercial clause certainly makes no sense as you say and LGPL might be problematic when it comes to re-use of QML code. I got the permissions to move existing headers over to BSD and will use that for the new ones as well. The required c

Re: [Development] Mutex future directions

On May 18, 2012, at 8:34 PM, ext Thiago Macieira wrote: > Recommendations (priority): > > (P0) de-inline QBasicMutex locking functions until we solve some or all of > the > below problems I agree with this, so that it gives a chance to fix the performance regressions on Mac at a later date (

Re: [Development] [Qt-l10n] Using Transifex for handling Qt localization?

On Mon, May 21, 2012 at 12:13:41AM +0200, ext Gábor Garami wrote: > Btw, I cannot imagine why Nokia (and previously Trolltech) do not foucus to > Linguist to improve it and make it as a best translation software (I used > it in a lot of translation project, in some cases I converted external > sour

Re: [Development] Quick2 and Directx11 backend (Angle)

Hi, I have qmake build support for ANGLE here[1]. This should compliment your work and enable us to integrate better with the Qt build - I don't think we want to add a dependency to the ANGLE build system. It might give us a mingw build as well. I got as far as getting Hello_Triangle compiling