Re: [Development] Does iMX6 support EGL on X11 feature?

[Alexander Nassian]

Did you have a look on QChart.js?
Otherwise you could just wrap Qwt in a QQuickPaintedItem to integrate that 
single QWidget component in the otherwise QtQuick UI.

Beste Grüße / Best regards,
Alexander Nassian

> Am 22.03.2019 um 20:02 schrieb Denis Shienkov :
> 
> Hi, 
> 
> Yes, but Qt Quick has not any good plotting library (as my app draw 
> "real-time" curves). QtCharts in not an option. :) 
> 
> I thought that maybe I could use the OpenGL widget in QtWidgets app to render 
> a curves there (e.g. with Qwt). But in this case I need in the working OpenGL 
> on X11 (which is not exists).
> 
> 
> 22.03.2019 21:29, Alexander Nassian пишет:
>> Then you should go with EGL and QtQuick if you want to utilize the GPU. X11 
>> is mostly a horrible idea on embedded systems (and in general too if you 
>> would ask me). Widgets are drawn by the CPU as far as I know.
>> 
>> Beste Grüße / Best regards,
>> Alexander Nassian

-- 













—


bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach

Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747

Geschäftsführer: Alexander Nassian, Markus Pfaffinger



http://www.bitshift-dynamics.de 


Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90


Allgemeine Anfragen: 
i...@bitshift-dynamics.com 
Technischer 
Support: supp...@bitshift-dynamics.com 

Buchhaltung: 
invo...@bitshift-dynamics.com 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Does iMX6 support EGL on X11 feature?

[Denis Shienkov]

> EGLFS

It does not allow to mix the QWidgets and QOpenglWidgets

> EGL/Wayland

here I'm not sure.


22.03.2019 22:28, Konstantin Tokarev пишет:

BTW, if your main concern is the performance of real-time plotting, it's 
extremely unlikely
that you'll get better results on EGL/X11 than on EGLFS or EGL/Wayland. Note 
that you
can use QWidgets on any of these platforms without restrctions.


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

Re: [Development] Does iMX6 support EGL on X11 feature?

[Konstantin Tokarev]

BTW, if your main concern is the performance of real-time plotting, it's 
extremely unlikely
that you'll get better results on EGL/X11 than on EGLFS or EGL/Wayland. Note 
that you
can use QWidgets on any of these platforms without restrctions.

-- 
Regards,
Konstantin

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

Re: [Development] Does iMX6 support EGL on X11 feature?

[Konstantin Tokarev]

22.03.2019, 22:21, "Denis Shienkov" :
> Yes, it was 'wayland'.. I tried with any options.. E.g. with X11 it fails as:
>
> main.cpp:16:50: error: cannot convert 'Display* {aka _XDisplay*}' to 
> 'EGLNativeDisplayType {aka _FBDisplay*}' in initialization
>>  EGLNativeDisplayType egldpy = XOpenDisplay("");
>
> it wants framebuffer??

Seems so

> so, I don't know what need to build EGL it with X11 on iMX6.

I never worked with iMX6, but I guess it may require X11-specific version of 
Vivante driver,
similarly to Mali


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Does iMX6 support EGL on X11 feature?

[Denis Shienkov]

Yes, it was 'wayland'.. I tried with any options.. E.g. with X11 it 
fails as:


main.cpp:16:50: error: cannot convert 'Display* {aka _XDisplay*}' to 
'EGLNativeDisplayType {aka _FBDisplay*}' in initialization

>  EGLNativeDisplayType egldpy = XOpenDisplay("");

it wants framebuffer?? so, I don't know what need to build EGL it with 
X11 on iMX6.


22.03.2019 22:04, Konstantin Tokarev пишет:


22.03.2019, 19:11, "Denis Shienkov" :

Hi all,

I'm trying to build a Yocto image, but the config tests fails on 'executing 
config test egl-x11' test with:


In file included from main.cpp:7:0:
main.cpp: In function 'int main(int, char**)':
main.cpp:15:20: error: cannot convert 'EGLNativeDisplayType {aka wl_display*}' 
to 'Display* {aka _XDisplay*}' in initialization
   Display *dpy = EGL_DEFAULT_DISPLAY;
  ^
In file included from 
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
   from 
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
   from main.cpp:7:
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
 note: class type 'wl_display' is incomplete
   typedef struct wl_display *  EGLNativeDisplayType;

it seems like your EGL implementation is configured to use Wayland instead of 
X11


--
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Does iMX6 support EGL on X11 feature?

[Konstantin Tokarev]

22.03.2019, 19:11, "Denis Shienkov" :
> Hi all,
>
> I'm trying to build a Yocto image, but the config tests fails on 'executing 
> config test egl-x11' test with:
>
>> In file included from main.cpp:7:0:
>> main.cpp: In function 'int main(int, char**)':
>> main.cpp:15:20: error: cannot convert 'EGLNativeDisplayType {aka 
>> wl_display*}' to 'Display* {aka _XDisplay*}' in initialization
>>  Display *dpy = EGL_DEFAULT_DISPLAY;
>> ^
>> In file included from 
>> /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
>>  from 
>>/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
>>  from main.cpp:7:
>> /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
>>  note: class type 'wl_display' is incomplete
>>  typedef struct wl_display *  EGLNativeDisplayType;

it seems like your EGL implementation is configured to use Wayland instead of 
X11


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Does iMX6 support EGL on X11 feature?

[Denis Shienkov]

Hi,

Yes, but Qt Quick has not any good plotting library (as my app draw 
"real-time" curves). QtCharts in not an option. :)


I thought that maybe I could use the OpenGL widget in QtWidgets app to 
render a curves there (e.g. with Qwt). But in this case I need in the 
working OpenGL on X11 (which is not exists).



22.03.2019 21:29, Alexander Nassian пишет:

Then you should go with EGL and QtQuick if you want to utilize the GPU. X11 is 
mostly a horrible idea on embedded systems (and in general too if you would ask 
me). Widgets are drawn by the CPU as far as I know.

Beste Grüße / Best regards,
Alexander Nassian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

[Denis Shienkov]

Yes, I know that. But in my case Qt builds without of EGL on X11 support 
(by unknow reason this test fails). And any of QwtPlot{OpenGL|GL}Canvas 
does not work at all.


22.03.2019 19:27, Konstantin Tokarev пишет:

You may want to try using QwtPlotOpenGLCanvas on your device

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

Re: [Development] Does iMX6 support EGL on X11 feature?

[Alexander Nassian]

Then you should go with EGL and QtQuick if you want to utilize the GPU. X11 is 
mostly a horrible idea on embedded systems (and in general too if you would ask 
me). Widgets are drawn by the CPU as far as I know.

Beste Grüße / Best regards,
Alexander Nassian

> Am 22.03.2019 um 17:06 schrieb Denis Shienkov :
> 
> Hi all,
> 
> I'm trying to build a Yocto image, but the config tests fails on 'executing 
> config test egl-x11' test with:
> 
> > In file included from main.cpp:7:0:
> > main.cpp: In function 'int main(int, char**)':
> > main.cpp:15:20: error: cannot convert 'EGLNativeDisplayType {aka 
> > wl_display*}' to 'Display* {aka _XDisplay*}' in initialization
> >  Display *dpy = EGL_DEFAULT_DISPLAY;
> > ^
> > In file included from 
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
> >  from 
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
> >  from main.cpp:7:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
> >  note: class type 'wl_display' is incomplete
> >  typedef struct wl_display *  EGLNativeDisplayType;
> > ^~
> > main.cpp:16:50: error: cannot convert 'Display* {aka _XDisplay*}' to 
> > 'EGLNativeDisplayType {aka wl_display*}' in initialization
> >  EGLNativeDisplayType egldpy = XOpenDisplay("");
> >   ^
> > In file included from main.cpp:9:0:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/X11/Xlib.h:255:8:
> >  note: class type 'Display {aka _XDisplay}' is incomplete
> >  struct _XDisplay;  /* Forward declare before use for C++ */
> > ^
> > main.cpp:17:11: error: cannot convert 'EGLNativeDisplayType {aka 
> > wl_display*}' to 'Display* {aka _XDisplay*}' in assignment
> >  dpy = egldpy;
> >^~
> > In file included from 
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
> >  from 
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
> >  from main.cpp:7:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
> >  note: class type 'wl_display' is incomplete
> >  typedef struct wl_display *  EGLNativeDisplayType;
> > ^~
> > main.cpp:18:42: error: invalid conversion from 'Window {aka long unsigned 
> > int}' to 'EGLNativeWindowType {aka wl_egl_window*}' [-fpermissive]
> >  EGLNativeWindowType w = XCreateWindow(dpy, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> > 0, 0);
> >  
> > ~^~
> > main.cpp:19:26: error: invalid conversion from 'EGLNativeWindowType {aka 
> > wl_egl_window*}' to 'Window {aka long unsigned int}' [-fpermissive]
> >  XDestroyWindow(dpy, w);
> >   ^
> > In file included from main.cpp:9:0:
> > /mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/X11/Xlib.h:2243:12:
> >  note:   initializing argument 2 of 'int XDestroyWindow(Display*, Window)'
> >  extern int XDestroyWindow(
> > ^~
> > Makefile:174: recipe for target 'main.o' failed
> > make: *** [main.o] Error 1
> test config.qtbase_gui.tests.egl-x11 FAILED
> 
> so, my quiestion is: Is it possible to use an OpenGL on X11 with XCB backend? 
> I need to accelerate the QWidgets application in some way... :(
> 
> DR,
> Denis
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 













—


bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach

Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747

Geschäftsführer: Alexander Nassian, Markus Pfaffinger



http://www.bitshift-dynamics.de 


Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90


Allgemeine Anfragen: 
i...@bitshift-dynamics.com 
Technis

Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

[Konstantin Tokarev]

22.03.2019, 19:22, "Denis Shienkov" :
> Hmmm.. thanks.. it is very bad... :(
>
> My goal it is to accelerate my QWidget application in some way... I use the 
> QWT library to render a curves..
>
> That ~30% CPU loading occured even at a low "frame-rate" (about ~2 updates 
> per second)... But I need about 20-30 updates per second... In this case the 
> CPU load increases up to 100% and the UI freezes.. It is wery bad, because on 
> Desktop-systems the CPU load is ~0%.
>
> Is any suggestions to minimize the CPU load on iMX6 target (using QWidget 
> application)? Maybe is it possible to use an OpenGL at all with X11? Or 
> something else? Because any other suggestions related to the application code 
> optimization has not sense (because there are the QWT library already is 
> optimized). Re-writing an application to Quick is not an option too...

You may want to try using QwtPlotOpenGLCanvas on your device


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

[Konstantin Tokarev]

22.03.2019, 19:08, "Allan Sandfeld Jensen" :
> On Freitag, 22. März 2019 12:46:59 CET Denis Shienkov wrote:
>>  Hi guys.
>>
>>  I have iMX6 board with Qt 5.11.2 and Qt-widgets based application. I have
>>  compiled my Qt with an 'xcb_native_painting' option.
>>
>>  I was hoping that this would speed up my UI and reduce the load on the CPU,
>>  but I was greatly mistaken:
>>
>>  When the QT_XCB_NATIVE_PAINTING is not set, I got following top:
>>
>>  * Xorg: 3.6 %
>>  * app: 12.8 %
>>
>>  When the QT_XCB_NATIVE_PAINTING is *set*, I got following top:
>>
>>  * Xorg: 23 %
>>  * app: 4.5 %
>>
>>  What? QT_XCB_NATIVE_PAINTING makes it worse in 2x-times... WTF?
>
> Sounds like XCB isn't as well optimized as Qt is ;)
>
> Note though, that there are number of techniques to make the native painting
> faster, such as always using qpixmap so the images stays buffered on the
> server side. You might be able to massage your program to be faster with
> native painting, but the whole reason for switching to Qt side painting was
> that for the average application developer Qt side was faster.

Native painting should be most beneficial when using remote X11

-- 
Regards,
Konstantin

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

Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

[Denis Shienkov]

Hmmm.. thanks.. it is very bad... :(

My goal it is to accelerate my QWidget application in some way... I use the
QWT library to render a curves..

That ~30% CPU loading occured even at a low "frame-rate" (about ~2 updates
per second)... But I need about 20-30 updates per second... In this case
the CPU load increases up to 100% and the UI freezes.. It is wery bad,
because on Desktop-systems the CPU load is ~0%.

Is any suggestions to minimize the CPU load on iMX6 target (using QWidget
application)? Maybe is it possible to use an OpenGL at all with X11? Or
something else? Because any other suggestions related to the application
code optimization has not sense (because there are the QWT library already
is optimized). Re-writing an application to Quick is not an option too...

BR,
Denis


пт, 22 мар. 2019 г. в 19:06, Allan Sandfeld Jensen :

> On Freitag, 22. März 2019 12:46:59 CET Denis Shienkov wrote:
> > Hi guys.
> >
> > I have iMX6 board with Qt 5.11.2 and Qt-widgets based application. I have
> > compiled my Qt with an 'xcb_native_painting' option.
> >
> > I was hoping that this would speed up my UI and reduce the load on the
> CPU,
> > but I was greatly mistaken:
> >
> > When the QT_XCB_NATIVE_PAINTING is not set, I got following top:
> >
> > * Xorg: 3.6 %
> > * app: 12.8 %
> >
> > When the QT_XCB_NATIVE_PAINTING is *set*, I got following top:
> >
> > * Xorg: 23 %
> > * app: 4.5 %
> >
> > What? QT_XCB_NATIVE_PAINTING makes it worse in 2x-times... WTF?
> >
> Sounds like XCB isn't as well optimized as Qt is ;)
>
> Note though, that there are number of techniques to make the native
> painting
> faster, such as always using qpixmap so the images stays buffered on the
> server side. You might be able to massage your program to be faster with
> native painting, but the whole reason for switching to Qt side painting
> was
> that for the average application developer Qt side was faster.
>
> 'Allan
>
>
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Does iMX6 support EGL on X11 feature?

[Denis Shienkov]

Hi all,

I'm trying to build a Yocto image, but the config tests fails on 'executing
config test egl-x11' test with:

> In file included from main.cpp:7:0:
> main.cpp: In function 'int main(int, char**)':
> main.cpp:15:20: error: cannot convert 'EGLNativeDisplayType {aka
wl_display*}' to 'Display* {aka _XDisplay*}' in initialization
>  Display *dpy = EGL_DEFAULT_DISPLAY;
> ^
> In file included from
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
>  from
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
>  from main.cpp:7:
>
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
note: class type 'wl_display' is incomplete
>  typedef struct wl_display *  EGLNativeDisplayType;
> ^~
> main.cpp:16:50: error: cannot convert 'Display* {aka _XDisplay*}' to
'EGLNativeDisplayType {aka wl_display*}' in initialization
>  EGLNativeDisplayType egldpy = XOpenDisplay("");
>   ^
> In file included from main.cpp:9:0:
>
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/X11/Xlib.h:255:8:
note: class type 'Display {aka _XDisplay}' is incomplete
>  struct _XDisplay;  /* Forward declare before use for C++ */
> ^
> main.cpp:17:11: error: cannot convert 'EGLNativeDisplayType {aka
wl_display*}' to 'Display* {aka _XDisplay*}' in assignment
>  dpy = egldpy;
>^~
> In file included from
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:38:0,
>  from
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/egl.h:39,
>  from main.cpp:7:
>
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/EGL/eglvivante.h:111:16:
note: class type 'wl_display' is incomplete
>  typedef struct wl_display *  EGLNativeDisplayType;
> ^~
> main.cpp:18:42: error: invalid conversion from 'Window {aka long unsigned
int}' to 'EGLNativeWindowType {aka wl_egl_window*}' [-fpermissive]
>  EGLNativeWindowType w = XCreateWindow(dpy, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0);
>
~^~
> main.cpp:19:26: error: invalid conversion from 'EGLNativeWindowType {aka
wl_egl_window*}' to 'Window {aka long unsigned int}' [-fpermissive]
>  XDestroyWindow(dpy, w);
>   ^
> In file included from main.cpp:9:0:
>
/mnt/data/Yocto-miatech/yocto-miatech/build-apalis-imx6/tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/5.11.2+gitAUTOINC+5b6eb8e247-r0/recipe-sysroot/usr/include/X11/Xlib.h:2243:12:
note:   initializing argument 2 of 'int XDestroyWindow(Display*, Window)'
>  extern int XDestroyWindow(
> ^~
> Makefile:174: recipe for target 'main.o' failed
> make: *** [main.o] Error 1
test config.qtbase_gui.tests.egl-x11 FAILED

so, my quiestion is: Is it possible to use an OpenGL on X11 with XCB
backend? I need to accelerate the QWidgets application in some way... :(

DR,
Denis
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

[Allan Sandfeld Jensen]

On Freitag, 22. März 2019 12:46:59 CET Denis Shienkov wrote:
> Hi guys.
> 
> I have iMX6 board with Qt 5.11.2 and Qt-widgets based application. I have
> compiled my Qt with an 'xcb_native_painting' option.
> 
> I was hoping that this would speed up my UI and reduce the load on the CPU,
> but I was greatly mistaken:
> 
> When the QT_XCB_NATIVE_PAINTING is not set, I got following top:
> 
> * Xorg: 3.6 %
> * app: 12.8 %
> 
> When the QT_XCB_NATIVE_PAINTING is *set*, I got following top:
> 
> * Xorg: 23 %
> * app: 4.5 %
> 
> What? QT_XCB_NATIVE_PAINTING makes it worse in 2x-times... WTF?
> 
Sounds like XCB isn't as well optimized as Qt is ;)

Note though, that there are number of techniques to make the native painting 
faster, such as always using qpixmap so the images stays buffered on the 
server side. You might be able to massage your program to be faster with 
native painting, but the whole reason for switching to Qt side painting was 
that for the average application developer Qt side was faster.

'Allan



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

Re: [Development] CMake branch

[Tobias Hunger]

On Fri, Mar 22, 2019 at 12:53 PM Joerg Bornemann  wrote:
> I believe that this means a reduced feature set for the CMake port.

That's not what I wanted to say:-)

All buildsystems all have things where they are nice to use and other
areas where they are less nice.

I want a build system for Qt that uses the things that work well in
cmake... one that does not do things for the only reason that we did
it exactly like that with qmake. Things that make sense and where
there is no obvious nicer way to get a similar effect in cmake should
of course stay.

> What kind of things do we expect to go away that we take for granted
> with the current build?

I do not plan to test any platform that I have no compiler for, so I
expect things to break there. I hope those platforms that are relevant
for Qt 6 will eventually get fixed by people that know them well.

Things will change, but not all of them due to cmake:

* We will also try to move most of the 3rd party code out of the Qt
repositories -- as much as we can get away with. CMake is good at
finding stuff, but we do this mostly since Thiago has been pushing for
that even before we started with cmake.
* We will also lose the ability to build qt tools for a host machine
and then continue to build for a target machine. You will need a host
installation to cross-compile. But again that is not due to cmake, but
because Lars asked for this to avoid building host tools dozens of
times on the CI.
* Setting features, etc. will be done differently (via the cmake UIs).
* How to enable sanitizers, etc. will change to how you do that in cmake.
* I hope the builds will also become a bit more robust -- but not as
robust as you would have managed with qbs!
* Builds should be faster as well -- we remove 3rd party code, so
there is less to build in the first place;-)

There are lots more things.

> And even if that is the case, why can't the qmake part be kept separate
> and left alone?

Currently the cmake and qmake parts are completely separate in the
wip/cmake branch. But once cmake is functional I plan to remove the
.pro/.pri/.qrc files and update some things then.

E.g. we no longer need to bootstrap qmake, so we can remove some
defines from Qt Base that enable that.

In fact qmake does not even need to stay in qtbase when we can build
everything with cmake. So I would like to separate that out so that we
have the option of moving it into a separate repository. Whether or
not we will move qmake is not my decision to make, but I do want to
provide the option.

Best Regards,
Tobias
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Tobias Hunger]

Am Freitag, den 22.03.2019, 10:45 + schrieb Jedrzej Nowacki:
>   I'm supporting Mikhail' proposal and I'm probably a bit guilty of the
> thread 
> too. As some of you know I'm not enthusiastic about any build system. I
> really 
> think that there are too complex for the purpose. What I care about is 
> shortening my development cycle and I can see how the cycle could be reduced 
> with ninja. I could try to help with porting to cmake, but I have nothing to 
> do in the wip branch. At the point in which cmake port works in at least on 
> one platfrom with developer build I do not see reason to not have it in 
> dev(*). 

So you are one of the people I referred to as wanting to work on Qt using cmake.
IMHO we can not support you at this time. 

>   I'm also a bit afraid that we are making the same delivery mistake as with 
> qbs.

We do the same mistake as we did with Qbs: We have way too few people working on
it to make it in time.

>  Everything is hidden behind an outdated feature branch. It requires quite 
> a mental effort to actually look there. By looking there you need to be 
> determined on working on the feature (there is nothing else there). 

Yes, that is the state we are in: You need to want to work on cmake to find the
branch interesting.

>   In addition seems that we go with a big bang approach, which worries me a 
> bit. Could you explain me why the temporary goal is to have two parallel
> build 
> systems?

Mostly to be able to compare results from qmake and cmake. It is pretty
convenient at this time.

>  Why we can not port stuff one by one and allow qmake to call cmake and 
> cmake to call qmake? For example why we can not already (*) require cmake to 
> build tests, moc, plugins and others?

*sigh* The task is hard enough already, please do not complicate it by requiring
qmake and cmake to seamlessly interact with each other at arbitrary points in
the build process.

>   There was also argument that we should not have cmake stuff in qt5 LTS. I
> do 
> not understand it, to be honest. That is really an implementation detail of 
> Qt.

A build system is *NOT* an implementation detail that is invisible to anybody
but developers of Qt.

Switching build systems does introduce a real risk to break a certain compilers,
setups and use-cases for all users and customers of Qt 5. We will also
definitely breaking each and every packaging script for Qt 5 out there in
existing. We break each and every instruction on how to build Qt 5 that was ever
published. We will also break all a lot of instructions on how to build against
Qt (probably even those that are concerned with cmake:-).

We should IMHO not expose our users and customers to such a risk in a minor
release. The only option to switch to an *exclusive* CMake based build system
that we have is IMHO Qt 6 (or Qt 7 if we miss that one).

But from what I understand this is not the proposal we are talking about. This
is about introducing cmake as a *secondary build system for Qt 5*, in
preparation for making it exclusive in Qt 6. I am fine with that.

As a secondary build systems our hands are much more tied with the cmake port
with regards to deviating from what qmake did than before.

I am also not at all enthusiastic about having to push all my CMake changes
through CI. That will eat a lot of extra time! I really do not understand how
you Qt developers can work like that...

>  We can have some transition scripts so configure && make && make install 
> somehow workflow works, but that is all.

Transition scripts work great, except when they don't:-/

qmake and cmake do moc differently, they handle .ui files differently. They
handle shared code much differently. There are lots of subtle differences all
over the place. Some will bite users, even when you try to hide all of that
behind transition scripts.

> (*) With assumption that we agree that cmake is the chosen one. I do not
> think 
> that the port needs to be ready before accepting it. In my opinion it is 
> enough to commit to it based on the state of the wip/cmake branch.

Please try to fix a bug in Qt with the wip/cmake branch and tell me how that
worked out for you. I doubt that you will enjoy that experience at this time.

>  So are we 
> sure that cmake is the way to go?

I think it is the only option we have right now.

>  If yes then let's go to dev.

... once we updated the wip/cmake branch to qt5/dev. Currently it is way behind.
Any help in getting that done is greatly appreciated.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Joerg Bornemann]

On 3/21/19 5:39 PM, Tobias Hunger wrote:

> We do not want to port all the qmake-quirks over to cmake. We get enough 
> quirks
> for free straight from cmake:-)

I believe that this means a reduced feature set for the CMake port.
What kind of things do we expect to go away that we take for granted 
with the current build?

And even if that is the case, why can't the qmake part be kept separate 
and left alone?


Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

[Denis Shienkov]

Hi guys.

I have iMX6 board with Qt 5.11.2 and Qt-widgets based application. I have
compiled my Qt with an 'xcb_native_painting' option.

I was hoping that this would speed up my UI and reduce the load on the CPU,
but I was greatly mistaken:

When the QT_XCB_NATIVE_PAINTING is not set, I got following top:

* Xorg: 3.6 %
* app: 12.8 %

When the QT_XCB_NATIVE_PAINTING is *set*, I got following top:

* Xorg: 23 %
* app: 4.5 %

What? QT_XCB_NATIVE_PAINTING makes it worse in 2x-times... WTF?

BR,
Denis
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Joerg Bornemann]

On 3/21/19 5:01 PM, Alex Blasche wrote:

   - We can synchronize CMakeFiles and *.pro files
>>> I do not understand this part.
>>   We can ask people to update CMakeFiles after updating pro files.
> 
> I don't think that you can make this a requirement at this point in time. You 
> may find super enthusiastic people but in general you cannot assume that they 
> stay in sync at this early point in time.

The experience in Qt Creator, which has qmake and qbs files, is that 
most people are making the effort to update both build systems. The 
missing adaptions to qbs files was always (and still is) done manually 
by Christian.

Take-away is that you can expect people helping keeping the CMake files 
up to date, but you won't get around fixing things yourself.


Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Jedrzej Nowacki]

On Friday, March 22, 2019 9:58:33 AM CET Simon Hausmann wrote:
> Am 21.03.19 um 15:54 schrieb Tobias Hunger:
> 
> > My idea was to ask for merging wip/cmake after
> > https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that
> > point
 the branch would be in a state where people can work on Qt (for
> > certain platforms) using cmake and do drive-by-contributions to cmake.
> > Right now it is more like working on CMake for Qt and doing
> > drive-by-contributions to Qt:-)>
> >
> >
> >> By doing the cmake work in a separate branch, we are keeping this hidden
> >> from
 everyone else. That was the right thing to do while we didn’t know
> >> if we want to go with it and what the structural implications of this
> >> change will be, but now we know, and it’s time to move this work into
> >> the mainline.
> > 
> > We have no decision from the Qt project yet. Submitting a patch for review
> > and
 getting that accepted would be such a decision:-) For this reason
> > alone I would very much welcome this proposal -- *if* we get volunteers
> > to help with keeping cmake up-to-date with qmake.
> >
> >
> >
> >
> > The wip/cmake branch is currently behind qt5/dev and we need to update it.
> > So if
 the Qt project decides to litter qtbase with CMakeLists.txt files
> > ASAP, then we will still need a while to send the actual patch for
> > review.
> >
> >
> 
> 
> Tobias' last paragraph is key here. For this proposal to be implemented, 
> a merge of wip/cmake with dev needs to be done, regardless. That works 
> needs to be done first. We need help.
> 
> 
> I like the overall idea of trying this out in dev - we should dare to do 
> this. If it doesn't work out and it slows everything down, then we can 
> still go back and branch off of dev. If it works out as planned and 
> yields more contributions, then we win. I think earlier last year we 
> never considered this even, but today the quality of the .pro file 
> converter has made this a possibility worth trying.
> 
> 
> It might be though that completing milestone 1 (QTBUG-73925) presents a 
> more sensible point of convergence where we could bring this into dev. 
> Mikhail, Jesus, what do you think?
> 
> 
> Simon

Hi,
 
  I'm supporting Mikhail' proposal and I'm probably a bit guilty of the thread 
too. As some of you know I'm not enthusiastic about any build system. I really 
think that there are too complex for the purpose. What I care about is 
shortening my development cycle and I can see how the cycle could be reduced 
with ninja. I could try to help with porting to cmake, but I have nothing to 
do in the wip branch. At the point in which cmake port works in at least on 
one platfrom with developer build I do not see reason to not have it in 
dev(*). 

  I'm also a bit afraid that we are making the same delivery mistake as with 
qbs. Everything is hidden behind an outdated feature branch. It requires quite 
a mental effort to actually look there. By looking there you need to be 
determined on working on the feature (there is nothing else there). 

  In addition seems that we go with a big bang approach, which worries me a 
bit. Could you explain me why the temporary goal is to have two parallel build 
systems? Why we can not port stuff one by one and allow qmake to call cmake and 
cmake to call qmake? For example why we can not already (*) require cmake to 
build tests, moc, plugins and others?

  There was also argument that we should not have cmake stuff in qt5 LTS. I do 
not understand it, to be honest. That is really an implementation detail of 
Qt. We can have some transition scripts so configure && make && make install 
somehow workflow works, but that is all.

(*) With assumption that we agree that cmake is the chosen one. I do not think 
that the port needs to be ready before accepting it. In my opinion it is 
enough to commit to it based on the state of the wip/cmake branch. So are we 
sure that cmake is the way to go? If yes then let's go to dev.

Cheers,
  Jędrek


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

Re: [Development] CMake branch

[Simon Hausmann]

Sure, we don't have to be super strict about those sub-tasks -- I'm sure 
Alexandru can be reasoned with so that we find a sub-set :). Right now a merge 
from wip/cmake to dev just wouldn't work at all anyway (it would break the 
cmake build).


Simon

From: Mikhail Svetkin
Sent: Friday, March 22, 2019 10:49
To: Simon Hausmann; development@qt-project.org
Subject: Re: [Development] CMake branch

I think it is not bad idea in general, but I think we need to wait only some of 
them (maybe only build qtsvg and qt5).

I think instead of creating new branches in qt5 and qtsvg we need to work in 
dev.


Best regards,
Mikhail

From: Development  on behalf of Simon 
Hausmann 
Sent: Friday, March 22, 2019 9:58 AM
To: development@qt-project.org
Subject: Re: [Development] CMake branch


Am 21.03.19 um 15:54 schrieb Tobias Hunger:
> My idea was to ask for merging wip/cmake after
> https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that 
> point
> the branch would be in a state where people can work on Qt (for certain
> platforms) using cmake and do drive-by-contributions to cmake. Right now it is
> more like working on CMake for Qt and doing drive-by-contributions to Qt:-)
>
>> By doing the cmake work in a separate branch, we are keeping this hidden from
>> everyone else. That was the right thing to do while we didn’t know if we want
>> to go with it and what the structural implications of this change will be, 
>> but
>> now we know, and it’s time to move this work into the mainline.
> We have no decision from the Qt project yet. Submitting a patch for review and
> getting that accepted would be such a decision:-) For this reason alone I 
> would
> very much welcome this proposal -- *if* we get volunteers to help with keeping
> cmake up-to-date with qmake.
>
>
> The wip/cmake branch is currently behind qt5/dev and we need to update it. So 
> if
> the Qt project decides to litter qtbase with CMakeLists.txt files ASAP, then 
> we
> will still need a while to send the actual patch for review.
>

Tobias' last paragraph is key here. For this proposal to be implemented,
a merge of wip/cmake with dev needs to be done, regardless. That works
needs to be done first. We need help.


I like the overall idea of trying this out in dev - we should dare to do
this. If it doesn't work out and it slows everything down, then we can
still go back and branch off of dev. If it works out as planned and
yields more contributions, then we win. I think earlier last year we
never considered this even, but today the quality of the .pro file
converter has made this a possibility worth trying.


It might be though that completing milestone 1 (QTBUG-73925) presents a
more sensible point of convergence where we could bring this into dev.
Mikhail, Jesus, what do you think?


Simon

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

[Development] Jira server (bugreports.qt.io) unavailable

[Alex Blasche]

We are experiencing problems with filters in Jira where items are not found 
anymore. We believe we have a solution for the problem but have to take the 
database down for about 20-30 min. This will start now. 

We are very sorry for the inconvenience.

--
Alex

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

Re: [Development] CMake branch

[Mikhail Svetkin]

I think it is not bad idea in general, but I think we need to wait only some of 
them (maybe only build qtsvg and qt5).

I think instead of creating new branches in qt5 and qtsvg we need to work in 
dev.


Best regards,
Mikhail

From: Development  on behalf of Simon 
Hausmann 
Sent: Friday, March 22, 2019 9:58 AM
To: development@qt-project.org
Subject: Re: [Development] CMake branch


Am 21.03.19 um 15:54 schrieb Tobias Hunger:
> My idea was to ask for merging wip/cmake after
> https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that 
> point
> the branch would be in a state where people can work on Qt (for certain
> platforms) using cmake and do drive-by-contributions to cmake. Right now it is
> more like working on CMake for Qt and doing drive-by-contributions to Qt:-)
>
>> By doing the cmake work in a separate branch, we are keeping this hidden from
>> everyone else. That was the right thing to do while we didn’t know if we want
>> to go with it and what the structural implications of this change will be, 
>> but
>> now we know, and it’s time to move this work into the mainline.
> We have no decision from the Qt project yet. Submitting a patch for review and
> getting that accepted would be such a decision:-) For this reason alone I 
> would
> very much welcome this proposal -- *if* we get volunteers to help with keeping
> cmake up-to-date with qmake.
>
>
> The wip/cmake branch is currently behind qt5/dev and we need to update it. So 
> if
> the Qt project decides to litter qtbase with CMakeLists.txt files ASAP, then 
> we
> will still need a while to send the actual patch for review.
>

Tobias' last paragraph is key here. For this proposal to be implemented,
a merge of wip/cmake with dev needs to be done, regardless. That works
needs to be done first. We need help.


I like the overall idea of trying this out in dev - we should dare to do
this. If it doesn't work out and it slows everything down, then we can
still go back and branch off of dev. If it works out as planned and
yields more contributions, then we win. I think earlier last year we
never considered this even, but today the quality of the .pro file
converter has made this a possibility worth trying.


It might be though that completing milestone 1 (QTBUG-73925) presents a
more sensible point of convergence where we could bring this into dev.
Mikhail, Jesus, what do you think?


Simon

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

Re: [Development] CMake branch

[Alexandru Croitor]

Hi,

You can find it here 
https://code.qt.io/cgit/qt/qtbase.git/tree/util/cmake/pro2cmake.py?h=wip/cmake

> On 22. Mar 2019, at 10:06, Julius Bullinger  
> wrote:
> 
> On 22.03.2019 09:58, Simon Hausmann wrote:
> 
>> I think earlier last year we never considered this even, but today
>> the quality of the .pro file converter has made this a possibility
>> worth trying.
> 
> Is this converter available somewhere? We're currently planning to migrate a 
> project from qmake to CMake, and evaluating the switch with such a converter 
> would be a tremendous help!
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] CMake branch

[Simon Hausmann]

Hi,

The script(s) are work in progress. You can find them in the util/cmake/ 
sub-directory of the wip/cmake branch of qtbase. There is one script for 
converting configure.json and one for converting .pro files. At the moment they 
are geared towards using the CMake functions we're developing in the same 
branch (in the cmake/ top-level sub-directory), but if you'd like to help make 
them work in a more general environment, then please don't hesitate to push 
patches to the wip/cmake branch in to Gerrit for review and pop by #qt-cmake on 
Freenode IRC for reviews :)


Simon

From: Development  on behalf of Julius 
Bullinger 
Sent: Friday, March 22, 2019 10:06
To: development@qt-project.org
Subject: Re: [Development] CMake branch

On 22.03.2019 09:58, Simon Hausmann wrote:

> I think earlier last year we never considered this even, but today
> the quality of the .pro file converter has made this a possibility
> worth trying.

Is this converter available somewhere? We're currently planning to
migrate a project from qmake to CMake, and evaluating the switch with
such a converter would be a tremendous help!
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] CMake branch

[Julius Bullinger]

On 22.03.2019 09:58, Simon Hausmann wrote:


I think earlier last year we never considered this even, but today
the quality of the .pro file converter has made this a possibility
worth trying.


Is this converter available somewhere? We're currently planning to 
migrate a project from qmake to CMake, and evaluating the switch with 
such a converter would be a tremendous help!

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

Re: [Development] CMake branch

[Simon Hausmann]

Am 21.03.19 um 15:54 schrieb Tobias Hunger:
> My idea was to ask for merging wip/cmake after
> https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that 
> point
> the branch would be in a state where people can work on Qt (for certain
> platforms) using cmake and do drive-by-contributions to cmake. Right now it is
> more like working on CMake for Qt and doing drive-by-contributions to Qt:-)
>
>> By doing the cmake work in a separate branch, we are keeping this hidden from
>> everyone else. That was the right thing to do while we didn’t know if we want
>> to go with it and what the structural implications of this change will be, 
>> but
>> now we know, and it’s time to move this work into the mainline.
> We have no decision from the Qt project yet. Submitting a patch for review and
> getting that accepted would be such a decision:-) For this reason alone I 
> would
> very much welcome this proposal -- *if* we get volunteers to help with keeping
> cmake up-to-date with qmake.
>
>
> The wip/cmake branch is currently behind qt5/dev and we need to update it. So 
> if
> the Qt project decides to litter qtbase with CMakeLists.txt files ASAP, then 
> we
> will still need a while to send the actual patch for review.
>

Tobias' last paragraph is key here. For this proposal to be implemented, 
a merge of wip/cmake with dev needs to be done, regardless. That works 
needs to be done first. We need help.


I like the overall idea of trying this out in dev - we should dare to do 
this. If it doesn't work out and it slows everything down, then we can 
still go back and branch off of dev. If it works out as planned and 
yields more contributions, then we win. I think earlier last year we 
never considered this even, but today the quality of the .pro file 
converter has made this a possibility worth trying.


It might be though that completing milestone 1 (QTBUG-73925) presents a 
more sensible point of convergence where we could bring this into dev. 
Mikhail, Jesus, what do you think?


Simon

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

Re: [Development] CMake branch

[Mårten Nordheim]

On 21.03.2019 19:10, André Pönitz wrote:
> On Thu, Mar 21, 2019 at 03:06:18PM +, Mikhail Svetkin wrote:
>>> I find it hard to believe that this improves the quality of Qt 5.14 or 5.15.
>>> Effectively you are proposing that we don't have any blocking CI for those 
>>> two
>>> Qt releases. Otherwise you would have to implement very intrinsic rules when
>>> to block and when not to block. Even seemingly innocent/unrelated doc 
>>> changes
>>> have been known to break Qt builds.
>>
>> I think maybe it is some kind of misunderstanding here.  The CI will be 
>> enable.
>> It will not test CMake.
> 
>> Even CMake won't be tested it will still need to go through the CI.
> 
> There's probably indeed a misunderstanding here, so please clarify:
> 
> I assume that currently changes to the cmake wip branch go into the repo
> directly, i.e.  with a delay in the range of seconds. Is that correct?

Yes

> I read the proposal so that after the proposed change it will just be
> staged together with all the other change to Qt base and will be subject
> to the normal restaging cycles as other qtbase changes, i.e. with a delay
> in the range of hours and days.  Is that interpretation correct?

Yes, even if it won't be tested on any of those integrations.

> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 

- Mårten Nordheim
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development