Re: [Development] [IMPORTANT] staging in qt dev branches temporarily disabled

[Laszlo Papp]

On Wed, Mar 20, 2013 at 2:53 PM, Oswald Buddenhagen <
oswald.buddenha...@digia.com> wrote:

> moin,
>
> empirical evidence shows that People™ don't read announcments, and
> consequently are still staging changes meant for 5.1 (i.e., bugfixes to
> new functionality) to dev. these changes would miss 5.1, or need to be
> cherry-picked, both of which are bad.
>
> consequently i have temporarily "locked down" the relevant branches, so
> really *everyone* gets it (i.e., is forced to ask wtf is going on).
>
> unfortunately this also prevents staging changes which are legitimately
> meant for dev.
> the solution/workaround is simple: just add me or Sergio Ahumada to the
> reviewers and ask for staging. i don't think this will be a real
> bottleneck,


What is up with this? Might be unrelated, but please whoever can do this,
stage it, or please explain the reason if it cannot be. Currently, it is
blocking any integration in QtSerialPort.

https://codereview.qt-project.org/#change,5179

Laszlo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [QT5] Configure error in QUrl

[Matteo Brichese]

Hi everyone, I'm Matteo from Italy, I'm trying to crosscompile qt5 for a tegra2 
device (Colibri T20 from Toradex) but I'm finding some errors in configure 
script.

Here is my configure:

./configure -make libs \
-prefix /opt/qt5_tegra \
-sysroot /home/matteo/oe-core/sysroot \
-device tegra2 \
-device-option CROSS_COMPILE=arm-angstrom-linux-gnueabi- \
-no-neon \
-opengl es2 \
-confirm-license \
-nomake examples -nomake tests \
-optimized-qmake \
-reduce-relocations \
-release \
-no-sse2 \
-no-sse3 \
-no-sse4.1 \
-no-sse4.2 \
-qt-xcb \
-opensource -v

the compiler is in my path, compiler and toolchain was generated by my 
openembedded env.
If I run this configure I came accross this error:


  1.
In file included from 
../../../../include/QtCore/qurl.h:1:0,
  2.
 from 
../../../../include/QtGui/../../src/gui/kernel/qevent.h:56,
  3.
 from 
../../../../include/QtGui/qevent.h:1,
  4.
 from 
../../../../include/QtGui/QTouchEvent:1,
  5.
 from 
../../../../include/QtGui/5.0.2/QtGui/qpa/../../../../../src/gui/kernel/qwindowsysteminterface.h:61,
  6.
 from 
../../../../include/QtGui/5.0.2/QtGui/qpa/qwindowsysteminterface.h:1,
  7.
 from 
../../../../include/QtGui/5.0.2/QtGui/private/../../../../../src/gui/kernel/qguiapplication_p.h:63,
  8.
 from 
../../../../include/QtGui/5.0.2/QtGui/private/qguiapplication_p.h:1,
  9.
 from qeglfsintegration.cpp:48:
  10.
../../../../include/QtCore/../../src/corelib/io/qurl.h:130:9:
 error: expected identifier before numeric constant
  11.
../../../../include/QtCore/../../src/corelib/io/qurl.h:130:9:
 error: expected '}' before numeric constant
  12.
../../../../include/QtCore/../../src/corelib/io/qurl.h:130:9:
 error: expected unqualified-id before numeric constant
  13.
../../../../include/QtCore/../../src/corelib/io/qurl.h:160:26:
 error: 'UrlFormattingOption' was not declared in this scope
  14.
../../../../include/QtCore/../../src/corelib/io/qurl.h:160:72:
 error: template argument 1 is invalid
  15.
../../../../include/QtCore/../../src/corelib/io/qurl.h:160:91:
 error: invalid type in declaration before ';' token
  16.
../../../../include/QtCore/../../src/corelib/io/qurl.h:163:10:
 error: expected unqualified-id before ')' token
  17.
../../../../include/QtCore/../../src/corelib/io/qurl.h:164:10:
 error: expected unqualified-id before 'const'


This error refers to folder qtbase/src/plugins/platforms/eglfs

It seems that the “None” element of the struct defined in qurl.h is even a 
defined constant in an X11-header.


If I relaunch the configure script with -no-eglfs option all goes well and I'm 
able to compile (make & make install) all the modules that I need, but I need 
eglfs for my project.


I'm using QT5 from git (5.0.1), in Ubuntu 12.04 32bit, gcc compiler 4.7.2.

I've also post the question here: http://qt-project.org/forums/viewthread/25896


Thank you.

Regards.

---
Matteo Brichese
Software Engineer
mbrich...@came.it
[Came Cancelli Automatici S.p.A.]
Il messaggio di posta elettronica contiene informazioni di carattere 
confidenziale specifiche per il destinatario. Nel caso non ne siate il 
destinatario, segnalatelo immediatamente al mittente ed eliminate dai vostri 
archivi quanto ricevuto (compresi i file allegati). L'uso, la diffusione, 
distribuzione o riproduzione del presente messaggio e dei suoi allegati da 
parte di ogni altra persona costituisce reato. Rif. Decreto legislativo 30 
giugno 2003, n. 196 - Codice in materia di protezione dei dati personali.

The email message contains confidential information specific to the recipient. 
If you are not the recipient, write it to the sender immediately and delete 
from your files as received (including 

[Development] R: [QT5] Configure error in QUrl

[Matteo Brichese]

I'm sorry, I've made an error, this errors came up when I launch the MAKE 
command, not in the configure.

Regards.
---
Matteo Brichese
Software Engineer
mbrich...@came.it
Came Cancelli Automatici S.p.A.
www.came.com

Da: development-bounces+mbrichese=came...@qt-project.org 
[development-bounces+mbrichese=came...@qt-project.org] per conto di Matteo 
Brichese [mbrich...@came.it]
Inviato: venerdì 22 marzo 2013 8.58
A: development@qt-project.org
Oggetto: [Development] [QT5] Configure error in QUrl

Hi everyone, I'm Matteo from Italy, I'm trying to crosscompile qt5 for a tegra2 
device (Colibri T20 from Toradex) but I'm finding some errors in configure 
script.

Here is my configure:

./configure -make libs \
-prefix /opt/qt5_tegra \
-sysroot /home/matteo/oe-core/sysroot \
-device tegra2 \
-device-option CROSS_COMPILE=arm-angstrom-linux-gnueabi- \
-no-neon \
-opengl es2 \
-confirm-license \
-nomake examples -nomake tests \
-optimized-qmake \
-reduce-relocations \
-release \
-no-sse2 \
-no-sse3 \
-no-sse4.1 \
-no-sse4.2 \
-qt-xcb \
-opensource -v

the compiler is in my path, compiler and toolchain was generated by my 
openembedded env.
If I run this configure I came accross this error:


  1.
In file included from 
../../../../include/QtCore/qurl.h:1:0,
  2.
 from 
../../../../include/QtGui/../../src/gui/kernel/qevent.h:56,
  3.
 from 
../../../../include/QtGui/qevent.h:1,
  4.
 from 
../../../../include/QtGui/QTouchEvent:1,
  5.
 from 
../../../../include/QtGui/5.0.2/QtGui/qpa/../../../../../src/gui/kernel/qwindowsysteminterface.h:61,
  6.
 from 
../../../../include/QtGui/5.0.2/QtGui/qpa/qwindowsysteminterface.h:1,
  7.
 from 
../../../../include/QtGui/5.0.2/QtGui/private/../../../../../src/gui/kernel/qguiapplication_p.h:63,
  8.
 from 
../../../../include/QtGui/5.0.2/QtGui/private/qguiapplication_p.h:1,
  9.
 from qeglfsintegration.cpp:48:
  10.
../../../../include/QtCore/../../src/corelib/io/qurl.h:130:9:
 error: expected identifier before numeric constant
  11.
../../../../include/QtCore/../../src/corelib/io/qurl.h:130:9:
 error: expected '}' before numeric constant
  12.
../../../../include/QtCore/../../src/corelib/io/qurl.h:130:9:
 error: expected unqualified-id before numeric constant
  13.
../../../../include/QtCore/../../src/corelib/io/qurl.h:160:26:
 error: 'UrlFormattingOption' was not declared in this scope
  14.
../../../../include/QtCore/../../src/corelib/io/qurl.h:160:72:
 error: template argument 1 is invalid
  15.
../../../../include/QtCore/../../src/corelib/io/qurl.h:160:91:
 error: invalid type in declaration before ';' token
  16.
../../../../include/QtCore/../../src/corelib/io/qurl.h:163:10:
 error: expected unqualified-id before ')' token
  17.
../../../../include/QtCore/../../src/corelib/io/qurl.h:164:10:
 error: expected unqualified-id before 'const'


This error refers to folder qtbase/src/plugins/platforms/eglfs

It seems that the “None” element of the struct defined in qurl.h is even a 
defined constant in an X11-header.


If I relaunch the configure script with -no-eglfs option all goes well and I'm 
able to compile (make & make install) all the modules that I need, but I need 
eglfs for my project.


I'm using QT5 from git (5.0.1), in Ubuntu 12.04 32bit, gcc compiler 4.7.2.

I've also post the question here: http://qt-project.org/forums/viewthread/25896


Thank you.

Regards.

---
Matteo Brichese
Software Engineer
mbrich...@came.it
[Came Cancelli Automatici S.p.A.]
Il messaggio di posta elettronica contiene informazioni di carattere 
confidenziale specifiche per il destinatario. Nel caso non ne siate il 
destinatario, segnalatelo immediata

Re: [Development] Tons of warnings in the Cocoa plugin

[Sorvig Morten]

On Mar 21, 2013, at 10:55 PM, Thiago Macieira  wrote:

> Someone who knows about this, could you please take a look?
> 
> The first and third warnings are scary.

Fixed most of them: 

https://codereview.qt-project.org/51868
https://codereview.qt-project.org/51869
https://codereview.qt-project.org/51870
https://codereview.qt-project.org/51871
https://codereview.qt-project.org/51872
https://codereview.qt-project.org/51873

Two exceptions:

[NSApp setAppMenu] is inherited from Qt 4 and is as far as I can see the only 
way to keep that Qt 4 feature/API working (see 51871).

I also left the color-space related ones. My plan is to take a closer look at 
color space support at some point after I return from my leave (which means 
after summer), and leave the current code as-is until then. 

Morten



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged

[Eskil Abrahamsen Blomfeldt]

On 03/21/2013 05:12 PM, Qi Liang wrote:
>> Let's be more clear: no commits were lost. They are all still present.
>>
>> However, due to conflicts, some changes may have been improperly resolved. 
>> This
>> is no different than any other merge, in any direction.
> Yes, it's "lost" because of conflict resolve. And we recorded the conflicts 
> information in merge commit, that's better than before, the merge commits in 
> Qt 4.

This is also a good reason to make an effort to add unit tests that 
verify your fix, however banal they might be, because there's a much 
smaller chance that the unit test will disappear in the merge than the 
bug fix.

-- Eskil

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtWayland: current state and roadmap

[Nichols Andy]

Greetings fellow Qt developers,

I would like to say a little bit about the current state of the QtWayland 
project and the current roadmap.  Today the QtWayland repository was split into 
the "stable" and "dev" branches following the convention of other Qt modules.  
There is no "release" branch yet because there has not yet been an official 
release of QtWayland.  In the "stable" branch work is being done to prepare for 
the first release, which is planned to happen with or shortly after the Qt 5.1 
release.  Here is a summary of the current road map for QtWayland (versions 
correspond the the Qt versions they are released against).

QtWayland 5.1.x (stable) 
Requires Qt 5.1 or higher
Requires xkbcommon 0.2.0 or higher
Requires libwayland 1.0.3 or higher

Provides support for running Qt applications as Wayland clients via the 
"wayland" platform plugin.  This is the ability to run Qt applications natively 
in Wayland compositors (like the Weston reference compositor).  This requires 
wayland-egl support to use.

Includes the experimental QtCompositor API for implementing Wayland 
compositors using Qt (did I mention that it's experimental at this point and 
very subject to API changes ?!)

Known issues:
Resizing OpenGL windows have sync issues, and displays buffer 
corruption when resizing
Window decorations behave unusually
Mouse cursors only work on window decoration
Menu's and pop-ups don't move if the parent window is moved (in 
Weston)

QtWayland 5.2.x (dev)
Requires Qt 5.2 or higher
Requires libwayland 1.x (master)

Planned Features:
QtCompositor API support for implementing Wayland compositors 
using Qt or QtQuick that are compatible with any other toolkits with Wayland 
client support (via wayland-egl)
QtCompositor API support for implementing Wayland compositors 
in places without wayland-egl through the use of hardware integration plugins 
(though no longer compatible with toolkits without them also implementing 
additional protocols).
Window decorations API for customizing decorations
Window decorations using Wayland sub-surfaces (because the 
solution we have now is sub-optimal)
Wayland input methods integration.
Test suite to run QtWayland CI tests

So that is the current status and roadmap.  There are a handful of developers 
contributing to the QtWayland module now, and they are doing a really awesome 
job, but we could always use more eyes and help if we hope to reach our goals 
and improve the quality of our Wayland support.  Here are some links that would 
be useful if you want additional information:

Qt project wiki with advice to get started:
http://qt-project.org/wiki/QtWayland

Bug tracker list of unresolved QtWayland bugs(please add more when you find 
them):
https://bugreports.qt-project.org/secure/IssueNavigator.jspa?mode=hide&requestId=13761

QtWayland talk I did at QtDevDays2012:
http://www.youtube.com/watch?v=jLiSEmtRvGs

Finally, feel free to ask questions on the freenode.  My handle is "nezticle" 
and QtWayland typically discussed in either #qt-lighthouse or #wayland

Regards and good hacking,
Andy Nichols
--
QtWayland maintainer
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Tons of warnings in the Cocoa plugin

[Jake Thomas Petroules]

Not the only way...

There's [NSApplicationDelegate applicationDockMenu:], and dock tile plugins (we 
should look into bundling a default dock tile plugin in Qt apps!).

Dock tile plugins have the added benefit of having the menu show up when the 
app isn't open (more like Windows jump lists).

https://developer.apple.com/library/mac/#documentation/Carbon/Conceptual/customizing_docktile/CreatingaDockTilePlug-in/CreatingaDockTilePlug-in.html
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Mar 22, 2013, at 4:51 AM, Sorvig Morten  wrote:

> 
> On Mar 21, 2013, at 10:55 PM, Thiago Macieira  
> wrote:
> 
>> Someone who knows about this, could you please take a look?
>> 
>> The first and third warnings are scary.
> 
> Fixed most of them: 
> 
> https://codereview.qt-project.org/51868
> https://codereview.qt-project.org/51869
> https://codereview.qt-project.org/51870
> https://codereview.qt-project.org/51871
> https://codereview.qt-project.org/51872
> https://codereview.qt-project.org/51873
> 
> Two exceptions:
> 
> [NSApp setAppMenu] is inherited from Qt 4 and is as far as I can see the only 
> way to keep that Qt 4 feature/API working (see 51871).
> 
> I also left the color-space related ones. My plan is to take a closer look at 
> color space support at some point after I return from my leave (which means 
> after summer), and leave the current code as-is until then. 
> 
> Morten
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QT5] Configure error in QUrl

[Thiago Macieira]

On sexta-feira, 22 de março de 2013 07.58.46, Matteo Brichese wrote:
>  from qeglfsintegration.cpp:48:

> This error refers to folder qtbase/src/plugins/platforms/eglfs
>
> It seems that the “None” element of the struct defined in qurl.h is even a
> defined constant in an X11-header.

Please reorder the includes in that file. The X11 includes must *always* be the
last include in the .cpp. If you can, submit that fix to codereview.qt-
project.org.

Note: there is no X11 include in that file. It's probably qeglfsintegration.h →
qeglfscreen.h → EGL/egl.h. Any chance that you can get better EGL headers from
your vendor, with no X11 requirements?

PS: please send text emails

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] R: [QT5] Configure error in QUrl

[Matteo Brichese]

Hi, the EGL is provided by nvidia, so I don't think that I could get any mod.

So, I've to reorder the include in EGL/egl.h right?

I'm sorry for the html signature, it's a society default, I'll try to delete it 
when sending to this ML.
---
Matteo Brichese
Software Engineer
mbrich...@came.it
Came Cancelli Automatici S.p.A.
www.came.com

Da: development-bounces+mbrichese=came...@qt-project.org 
[development-bounces+mbrichese=came...@qt-project.org] per conto di Thiago 
Macieira [thiago.macie...@intel.com]
Inviato: venerdì 22 marzo 2013 16.10
A: development@qt-project.org
Oggetto: Re: [Development] [QT5] Configure error in QUrl

On sexta-feira, 22 de março de 2013 07.58.46, Matteo Brichese wrote:
>  from qeglfsintegration.cpp:48:

> This error refers to folder qtbase/src/plugins/platforms/eglfs
>
> It seems that the “None” element of the struct defined in qurl.h is even a
> defined constant in an X11-header.

Please reorder the includes in that file. The X11 includes must *always* be the
last include in the .cpp. If you can, submit that fix to codereview.qt-
project.org.

Note: there is no X11 include in that file. It's probably qeglfsintegration.h →
qeglfscreen.h → EGL/egl.h. Any chance that you can get better EGL headers from
your vendor, with no X11 requirements?

PS: please send text emails

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] R: [QT5] Configure error in QUrl

[Thiago Macieira]

On sexta-feira, 22 de março de 2013 15.20.03, Matteo Brichese wrote:
> Hi, the EGL is provided by nvidia, so I don't think that I could get any
> mod.

Can you compile Qt with the Mesa headers?

> So, I've to reorder the include in EGL/egl.h right?
>
> I'm sorry for the html signature, it's a society default, I'll try to delete
> it when sending to this ML.

This is not about the footer and signature, it's about the format. If you read
your original email in text mode, you see:
  1.
In file included from 
../../../../include/QtCore/qurl.h:1:0,
  2.
 from 
../../../../include/QtGui/../../src/gui/kernel/qevent.h:56,


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] R: R: [QT5] Configure error in QUrl

[Matteo Brichese]

>>On sexta-feira, 22 de março de 2013 15.20.03, Matteo Brichese wrote:
>> Hi, the EGL is provided by nvidia, so I don't think that I could get any
>> mod.
>Can you compile Qt with the Mesa headers?
I think yes, but compiling with Mesa header I will be able to have hardware 
acceleration from qt?


--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
---
Matteo Brichese
Software Engineer
mbrich...@came.it
Came Cancelli Automatici S.p.A.
www.came.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QT5] Configure error in QUrl

[Thiago Macieira]

On sexta-feira, 22 de março de 2013 15.29.45, Matteo Brichese wrote:
> >>On sexta-feira, 22 de março de 2013 15.20.03, Matteo Brichese wrote:
> >> Hi, the EGL is provided by nvidia, so I don't think that I could get any
> >> mod.
> >
> >Can you compile Qt with the Mesa headers?
>
> I think yes, but compiling with Mesa header I will be able to have hardware
> acceleration from qt?

That's how you run, not how you compile.

As far as I know, the Mesa libraries are binary compatible with any other
vendor's, so you can replace them at runtime with an implementation with
hardware acceleration.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Updating third-parties

[Frederik Gladhorn]

Onsdag 20. mars 2013 09.50.22 skrev Thiago Macieira:
> Hello
> 
> We're feature-freezing 5.1. It's time to verify if any of the third-party
> libraries we include in Qt need updating to newer versions. I recommend
> updating all of them to their latest versions.
> 
> Do we have volunteers?
> 
> Listing of third-party libraries (high-priority items marked with *):
> 
> qtbase:
>   ANGLE (*)
>   ATSPI2
I take at-spi-2. It's pure headers (actually just a few enums) and for now we 
are fine. Since it's not bleeding into our public api we can update as needed 
(if they should add a new enum value that we want to use).

>   DES
>   Easing equations
>   Freetype (*)
>   Harfbuzz
>   IAccessible2
>   libjpeg (*)
>   libpng (*)
>   MD4
>   MD5
>   PCRE (*)
>   pixman
>   SHA-1
>   SHA-2
>   SHA-3
>   Sqlite (*)
>   Wintab
>   XCB
>   zlib (*)
> qtimageformats:
>   libmng
>   libtiff
> qtjsbackend:
>   V8
> qtscript:
>   JavaScriptCore
-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] R: [QT5] Configure error in QUrl

[Matteo Brichese]

Hi, I'm trying to link my system GL libraries in my rootfs but I've got the 
same error, even my GL lib (ubuntu 12.04 with no proprietary driver) contains 
"#include "

I've this situation:
matteo@openembeddedpc:~/sysroot/usr/include$ ls -l | grep GL
drwxr-xr-x  2 matteo matteo   4096 Mar 13 19:53 EGL
drwxr-xr-x  3 matteo matteo   4096 Mar 13 20:03 GL
drwxr-xr-x  2 matteo matteo   4096 Mar 13 19:53 GLES
drwxr-xr-x  2 matteo matteo   4096 Mar 13 19:53 GLES2

Inside GL:
matteo@openembeddedpc:~/sysroot/usr/include/GL$ find | grep X11 *
glext.h:#define GL_MATRIX11_ARB   0x88CB
glext.h:#define GL_SYNC_X11_FENCE_EXT 0x90E1
glx.h:#include 
glx.h:#include 
glxint.h:#include 
glxint.h:#include 

Inside EGL:
matteo@openembeddedpc:~/sysroot/usr/include/EGL$ find | grep X11 *
eglplatform.h:/* X11 (tentative)  */
eglplatform.h:#include 
eglplatform.h:#include 

This is with nVidia driver, but if I look inside my ubuntu system I've the same 
situation even with Vesa driver.

So, you say that in the Mesa driver I don't have the X11 include inside EGL/GL 
folder?
---
Matteo Brichese
Software Engineer
mbrich...@came.it
Came Cancelli Automatici S.p.A.
www.came.com

Da: development-bounces+mbrichese=came...@qt-project.org 
[development-bounces+mbrichese=came...@qt-project.org] per conto di Thiago 
Macieira [thiago.macie...@intel.com]
Inviato: venerdì 22 marzo 2013 16.32
A: development@qt-project.org
Oggetto: Re: [Development] [QT5] Configure error in QUrl

On sexta-feira, 22 de março de 2013 15.29.45, Matteo Brichese wrote:
> >>On sexta-feira, 22 de março de 2013 15.20.03, Matteo Brichese wrote:
> >> Hi, the EGL is provided by nvidia, so I don't think that I could get any
> >> mod.
> >
> >Can you compile Qt with the Mesa headers?
>
> I think yes, but compiling with Mesa header I will be able to have hardware
> acceleration from qt?

That's how you run, not how you compile.

As far as I know, the Mesa libraries are binary compatible with any other
vendor's, so you can replace them at runtime with an implementation with
hardware acceleration.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged

[Frederik Gladhorn]

Torsdag 21. mars 2013 20.27.33 skrev Oswald Buddenhagen:
> hi,
> 
> On Thu, Mar 21, 2013 at 02:33:30PM +, Qi Liang wrote:
> > I think it's important, your commits in stable branch perhaps lost
> > after dev branch merged. [...]
> 
> to preclude further pointless panicking, i simply re-did the merge
> and diffed the result.
> 
> the hunk that was already identified as lost was indeed a simple
> mis-merge.
> 
> i also identified a second commit which appears to have been mis-merged
> (comment added to original change).
> 
> background:
> 
> the merge was originally done by sergio (who also introduced the
> mistakes, which is somewhat understandable, given how many merges there
> were to do, and under which (perceived) time pressure).
> 
> i amended and "rebased" the merge, and in the process accidentally
> "stole" the attribution. later i reviewed the merge and missed the
> mis-merges (mostly due to git's retarded (non-)display of conflict
> resolution diffs).
> 
> end of story. now move on.

I agree, there is no real damage done, we fixed up where the merges went 
wrong. My personal pain point was that the whole merge was a bit 
uncoordinated.
As someone who has enjoyed merging branches lately, I can completely 
understand that it goes wrong, I messed up a few times too, especially in the 
beginning.

I just have a few notes for those doing the merge:
* be careful when doing merges; take time to actually review merges
* don't disable unit tests because they block a merge, chances are your merge 
is wrong (this should be a no-brainer...)
* if you haven't done much merging, grab someone else to resolve the 
conflicts, peer-merging is much more fun and less frustrating
* check why you have a conflict, digging through git history is fun anyway
* don't be ashamed to ask others who are responsible for the conflict, they 
will help you resolve it properly
* don't keep on including more and more commits in your merge, it's just going 
to give you more breakage, it's fine to do two merge commits instead - there 
is no requirement to take HEAD of one branch, it's bad enough that the target 
branch is a moving target

In this particular case, I would have appreciated more coordination. The merge 
was started when the stable->dev merges were all done but qtbase which was 
known not to integrate. The same problems broke the other direction, 
unsurprisingly. We could have taken much less time by choosing a good set of 
dev branch sha1s. Updating the merge with a few commits afterwards is no big 
deal, the diff will be small and things will go smother.

Let's keep it rolling :)

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] R: [QT5] Configure error in QUrl

[Thiago Macieira]

On sexta-feira, 22 de março de 2013 17.02.28, Matteo Brichese wrote:
> Inside GL:
> matteo@openembeddedpc:~/sysroot/usr/include/GL$ find | grep X11 *
> glext.h:#define GL_MATRIX11_ARB   0x88CB
> glext.h:#define GL_SYNC_X11_FENCE_EXT 0x90E1
> glx.h:#include 
> glx.h:#include 
> glxint.h:#include 
> glxint.h:#include 

The two defines are normal. The rest are GLX, which is X-specific anyway.

> Inside EGL:
> matteo@openembeddedpc:~/sysroot/usr/include/EGL$ find | grep X11 *
> eglplatform.h:/* X11 (tentative)  */
> eglplatform.h:#include 
> eglplatform.h:#include 

A slightly longer paste:

#ifdef MESA_EGL_NO_X11_HEADERS

typedef void*EGLNativeDisplayType;
typedef khronos_uint32_t EGLNativePixmapType;
typedef khronos_uint32_t EGLNativeWindowType;

#else

/* X11 (tentative)  */
#include 
#include 

typedef Display *EGLNativeDisplayType;
typedef Pixmap   EGLNativePixmapType;
typedef Window   EGLNativeWindowType;

#endif /* MESA_EGL_NO_X11_HEADERS */

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fixing file dialog performance on Windows

[Sérgio Martins]

On Thursday, March 21, 2013 05:05:00 Shaw Andy wrote:
> > The file dialog takes up to 30 seconds to be usable if we're listing
> > files on a USB or remote share with 10k files.
> > 
> > 
> > The bottlenecks are QFileIconProvider::icon(const QFileInfo &info) and
> > QFileInfo::isSymLink().
> > 
> > 
> > I solved the icon problem by looking them up in the registry, by
> > extension, and caching them.
> 
> 
> I assume that for executables you look it up directly or is that stored in
> the registry too?

For .exe and .ico files, it will go through the current code path.
 

Regards,
-- 
Sérgio Martins | sergio.mart...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] File Selectors API, still for 5.1?

[Alan Alpert]

There are a few questions left on the QFileSelectors API addition,
https://codereview.qt-project.org/#change,48334 :

1) Did it miss the feature freeze for 5.1?
It did not merge into dev before the dev->stable merge, so it has
technically missed the freeze. But I'd like to ask for a special
exception, on the following two grounds. Firstly, since before the
freeze the change has only been blocked on documentation and naming
comments (relevant to a quality product, but not really affecting
stability).

Secondly, this is time-sensitive. At least Plasma and BlackBerry
already have conflicting schemes to provide this functionality on top
of Qt 4. A disruptive change to their file structures is only going to
work on a major version change, like when they start using Qt 5 (both
aim to start with 5.1 I believe). Missing this window means that they
both continue to use their own conflicting directory structures in
their next major versions, which is a blow to cross-platform
application development.

This exception is of course contingent on reviewers agreeing that it's
done; currently that appears to just mean agreement on a class name.
Obviously there can't be an exception to the freeze for a feature
which can't merge because it's not done.

If it doesn't get a feature freeze exception, we at least need to
support it being implemented by others in QML (because while doing
this kind of thing yourself with just C++ is fairly easy, it's really
hard to reach into the QML engine to have this effect applied to QML
files). This could either mean moving QFileSelectors to QtQml (which
would mean giving up on all the non-QML usecases, like the res: scheme
in the original thread) or have QML use an abstract class which can
later be powered by QFileSelectors (but in the interim will lead all
platforms to implement their own conflicting schemes).

2) What to call it?
Oswald suggested "QPathSelector. or QPathSwitch[er]. or
QPathMultiplexer."  I'm still leaning towards QFileSelectors, but I'd
also be happy with Q[File|Path]Switcher or QPathMultiplexer. I know
that everyone has an opinion on naming matters, is there something
even better that we haven't thought of yet?

3) Why directories? This change wasn't discussed on the ML yet, and is
a key difference from the consensus reached in
http://lists.qt-project.org/pipermail/development/2013-January/009359.html
.

In one of the patch sets, the form changed from f...@selector.png to
+selector/file.png . Feedback from designers in BlackBerry suggested
that they were more comfortable with directories, especially when
using it to swap out graphical assets for device variants (which can
lead to a lot of selected files). It's much easier for them to deal
with a group of selected files via directory, which I presume is
because from a GUI file manager you don't have the shell globbing that
I'm accustomed to using. The switch from @ to + is because that works
with my shell auto-complete (~ is already special, @ makes it think
it's part of a URL). Having a special character in the directory name
helps reduce the risk of accidental collisions, and makes selector
directories clear compared to normal directories.

4) One question (sort-of) that came up in the review (from Jędrzej):
"Without runtime detection of a selector value change, the
QFileSelectors is just a workaround for a deployment problem. It
solves issues that can be solved by an installer script or even by a
dynamically loaded QResource." This goes beyond deployment, and so
also solves some issues that cannot be solved by an installer script
or dynamically loaded QResource. It's a little confusing that one of
the main selectors is "platform" - that's more for consistency (so
that you can place your platform-specific selectors inside the
platform selectors) than because deploying different files to
different platforms is too hard right now.

The loading of graphical assets to match the state at application
launch can involve factors that are not known at deployment time, for
example the current theme (one of the things that BlackBerry currently
uses selectors for:
https://developer.blackberry.com/cascades/documentation/ui/resolution/using_static_asset.html
). Arguably responding to theme and resolution in an application
should be done dynamically, not statically, however that is a lot
harder to do (and for minimal gains in some situations). Until we have
a dynamic solution, offering a simple static solution is still a
marked improvement. The dynamic solution could still make use of
QFileSelectors, if we increase the ability for selectors to update
when re-queried at runtime (compatible with the current API). I'd
argue that it's not worth waiting for the dynamic solution to be fully
conceptualized before providing a static solution, because the static
solution provides value now and the dynamic solution is still very far
away.

Dynamically loaded QResources can provide similar functionality, but
not entirely the same. Even for the ov

[Development] Proposition for a new Q_OS_ define

[Jake Thomas Petroules]

I'd like to suggest that we add a new Q_OS_ define.

Currently, for Apple platforms, we have:

Q_OS_DARWIN
Q_OS_DARWIN32
Q_OS_DARWIN64
Q_OS_IOS
Q_OS_MAC
Q_OS_MAC32
Q_OS_MAC64
Q_OS_MACX

The first three are very straightforward. Q_OS_DARWIN is defined for both Apple 
platforms, OS X and iOS, with specific defines for 32 and 64 bit. iOS -- also 
straightforward; means iOS.

Then we get confusing. You'd think Q_OS_MAC is defined for OS X only, but it's 
just a synonym for Darwin, which makes it mostly useless. Further confusing is 
Q_OS_MACX which even more strongly implies that  it refers to OS X, but again 
it's simply a synonym for Darwin.

This results in a ton of #if defined(Q_OS_MAC) && !defined(Q_OS_IOS), which is 
very counterproductive. I propose that we add a Q_OS_OSX define (and Q_OS_OSX32 
/ Q_OS_OSX64) which is only defined for OS X. This would be quite helpful, I 
think.

Any objections? If not, dev or stable?
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development