from:"Denis"


> 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?

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?


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

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] QT_XCB_NATIVE_PAINTING makes worse that without of it

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?

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

[Development] QT_XCB_NATIVE_PAINTING makes worse that without of it

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] Continuous Integration for 3rd party projects using Qt

2019-03-18 Thread Denis Kormalev

Different compilers and qt versions are easily solvable with multiple docker 
images (that can be generated using single Dockerfile with arguments). 
In this case in CI itself all you need is just to build in each of them in 
common way (ideally you just put your build script as entry point and run 
docker container. After it finishes you’ll have all the artifacts to check).

--
Regards,
Denis Kormalev

> On Mar 17, 2019, at 11:49 PM, Uwe Rathmann  wrote:
> 
> Hi,
> 
> thanks for the all the hints in this thread - I will check them if I 
> can't find a service, that is more specific:
> 
> a)
> 
> The very first of my problems is to know about the platforms I need to 
> test. I guess the list of all operating system and compiler combinations 
> can be found somewhere in the Qt docs, but considering, that only on 
> "Linux" you have to consider gcc/icc/clang - for gcc only you have 
> v4/5/6/7/8 ...
> 
> b)
> 
> Furthermore a project like Qwt supports all Qt versions >= 4.4. Even, 
> when limiting the tests to a set of relevant versions - let's say 
> 4.8/5.6/5.9/5.12 - complexity grows significantly.
> 
> --
> 
> My guess is that setting up all the build environments for a) is what has 
> been solved with Coin. Actually I'm not interested in "continous" - it 
> would be good enough to compile all my stuff once in a while ?
> 
> Uwe
> 
> 
> 
> ___
> 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] Continuous Integration for 3rd party projects using Qt

2019-03-17 Thread Denis Kormalev

Travis can cover macosx, linux (and using docker it can cover different 
environments/compilers and packaging for various distribs) and android (with 
linux as host). Appveyor can cover Windows builds.

--
Regards,
Denis Kormalev

> On Mar 17, 2019, at 9:03 AM, Bernhard B  wrote:
> 
> Why not use one of the continous integration services like travis-ci or 
> circle-ci?
> 
> Cheers,
> Bernhard
> 
> Uwe Rathmann mailto:uwe.rathm...@tigertal.de>> 
> schrieb am So., 17. März 2019, 14:55:
> Hi,
> 
> all arguments for doing Continuous Integration for Qt ( https://
> blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ 
> <http://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/> ) are 
> also 
> valid for 3rd party code using Qt.
> 
> F.e. with Qwt ( https://qwt.sourceforge.io <https://qwt.sourceforge.io/> ) 
> I'm supporting trillions of 
> environments I have never seen myself. Actually I'm using Linux/gcc only 
> - the rest is crossing my fingers and hoping for bug reports.
> 
> So what I'm looking for is a service, where I can upload my project to be 
> built in all official combinations supported by Qt - like it is done for 
> the Qt code.
> 
> Is such a service available or - if not - would it be possible to open 
> your CI system for community projects using Qt ?
> 
> Uwe 
> 
> ___
> Development mailing list
> Development@qt-project.org <mailto:Development@qt-project.org>
> https://lists.qt-project.org/listinfo/development 
> <https://lists.qt-project.org/listinfo/development>
> ___
> 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] Looking for Feedback QDeferred

2019-03-03 Thread Denis Kormalev

Hi,

Sorry for the kinda late response, but you probably would also like to check 
https://github.com/dkormalev/asynqro <https://github.com/dkormalev/asynqro> for 
ideas about API improvements. 

--
Regards,
Denis Kormalev

> On Feb 12, 2019, at 1:38 AM, Juan Gonzalez Burgos  
> wrote:
> 
> Hi,
> 
> Looking at it with the “Qt Creator” hat on, i.e. with the mindset of “could 
> we replace what we do in Qt Creator with our extension of QtConcurrent".
> (http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/runextensions.h
>  
> <http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/runextensions.h>
>  adds the convenience and actual runnable based around QFuture and 
> QFutureInterface.)
> I suppose this is a very UI-interaction focused, and high-level view on 
> things ;) but it is something that the 
> QFuture/QFutureInterface/QFutureWatcher API supports.
> 
> Wow, first of all thanks for taking the time for this awesome feedback. 
> I guess the QFuture/QFutureWatcher design was driven by Qt's needs as I 
> developed QDeferred for my very own needs. I suppose one just have to use the 
> tool that best fits the problem.
> 
> 1) I think the chaining/promises style is an improvement to the need to 
> always use QFutureWatcher. We more often need to carry a QFutureWatcher 
> member around than I like (even with a helper function Utils::onResultReady, 
> the moment you need to handle various signals you’ll want to stick to a 
> single QFutureWatcher)
> 
> Agree. There are use cases where QFutureWatcher is better.
> 
> 2) We use QFuture/QFutureInterface for a generic progress UI. Basically you 
> tell a central progress UI manager about your QFuture, and that shows a 
> progress bar for it, including a cancel button.
> 
> What about multiple “subscribers” to a task? The progress UI needs to act on 
> progress info, and finished / success status changes. On a glance I didn’t 
> see if that is possible with your API.
> 
> Yes is possible to have multiple subscribers, thank you for pointing at it, I 
> forgot to mention it explicitly in the readme. It is done as follows:
> 
>   QDeferred defer = myMethod()
>   .done([](int val) {
>   
>   })
>   .fail([](int val) {
> 
>   });
> 
>   // we can pass "defer" around since is a explicitly shared object
>   // ...
> 
>   // subscribe elsewhere
>   defer
>   .done([](int val) {
> 
>   })
>   .fail([](int val) {
> 
>   });
> 
> And if the QDeferred was already resolved/rejected when a new subscription is 
> done, then the callback is called inmediatly (depending on the 
> connection-type, more on this later). I will add this to the document. 
> 
> I didn’t see cancel functionality in your work, do you have thoughts on this?
> 
> I didn't think of this, haven't had the need but it is a great idea! I think 
> it should not be too hard to implement. Maybe an API method called "cancel" 
> and a callback called "cancelled" so we know when the process has actually 
> been cancelled,
> 
> The implementation for progress seems to be a bit awkward in comparison to 
> QFutureInterface, and doesn’t seem to be separate from the result type? 
> Progress can be pretty separate from actual result producing, i.e. a file 
> system search will be able to provide very fine grained progress information, 
> but might only report a handful of results.
> 
> Yes and no, actually this was a hard decision for me. One main differentator 
> with QDeferred is that there are N result types, so we could get around the 
> issue as follows:
> 
>   QDeferred defer = myMethod()
>   .progress([](QByteArray result, int progress, QString message) {
>   Q_UNUSED(result);
>   qDebug() << "Progress" << progress << "% , details :" << 
> message;
>   })
>   .done([](QByteArray result, int progress, QString message) {
>   Q_UNUSED(progress, message);
>   // do something with the QByteArray results
>   });
> 
> The fact that you have N result types does not mean you have to use all of 
> them in every callback. You could use some of them for progress info and some 
> others for results. I know this might come as "akward", but what actually 
> constitute a "progress"? At some point I though of adding a specialized  
> or  API for the progress but decided not to because it would be 
> limiting. E.g. one of my use cases was to bring large chunks of historic data 
> from a server, and the "progress" for that use case was partial data blocks 
> which I

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

2019-01-07 Thread Denis Kormalev

I would at least suggest to answer Ekkehard and BogDan in QTBUG-72687. They are 
waiting for 4 days for answer from you.

--
Regards,
Denis Kormalev

> On Jan 7, 2019, at 12:08 AM, Aleksey Kontsevich  wrote:
> 
> Very strange. May I move them to P0-Blocker then? :)
> 
> -- 
> Best regards,
> Aleksey
> Linked in  https://www.linkedin.com/in/alekseykontsevich
> 
> 
> 07.01.2019, 07:37, "Jani Heikkinen" :
>>>  -Original Message-
>>>  From: Development  On Behalf Of
>>>  Aleksey Kontsevich
>>>  Sent: lauantai 5. tammikuuta 2019 12.23
>>>  To: ekke ; developm...@lists.qt-project.org
>>>  Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
>>>  started
>>> 
>>>  Hi,
>>> 
>>>  What about QTBUG-72687 and QTBUG-72227?
>> 
>> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.
>> 
>> br,
>> Jani
> ___
> 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] Build system for Qt 6

2018-12-18 Thread Denis Shienkov

> preferably one that doesn't involve Qt specific stuff

A main point is that we discuss about using the CMake as an 'advanced' 
buld system in context of Qt.

> Please show a concrete example

I already provided that example - it is cross-compilation. You can try 
to cross-compile a simple application using CMake && Creator for the 
Yocto target.

I'm, as a developer want to see a perfect integration between Qt stuff 
&& CMake, because they (Qt managers) decided to choose the CMake. But 
I'm don't see that it work at all. So, why I need to believe them? How 
much time I need to wait until it will be fixed? Why I need to spent my 
time at attempt to fix it (to lookup in CMake's magic macroses,  tricks, 
to rake its ugly syntax and so on)? I' don't think that CMake is a right 
choose for a Qt developers.

Maybe, if in my case I never faced with my issue, I would be not so 
negative (maybe even I would be closed my eyes to ugly CMake syntax and 
so on).

Another issue it is that I need force to lookup a some CMake toolchains 
in different github projects from custom peoples (e.g. for 
Android/iOS/Keil/IAR toolchains). I mean, that it is not official 
CMake's stuff (I know, that IAR toolchain already has ben added to 
CMake, but I not sure that it will work too). Why I need to use for this 
custom stuff? I'm even not sure that it will work.

Of course, I can write a own stuff (toolchain file or something else) on 
CMake, but it is soo ugly. In my case I just will take QBS and do al 
what I need in 100 times fastest and shorter  and clearer and will not 
worry at all (what and I do).

If Qt maintainers says that they will not remove the QtCreator && QBS 
integration in future (I'm about QBS project manager plugin), then I 
will not worry (don't care) about CMake. I will use QBS in any case.

I tried both CMake && QBS and I can say that for me QBS is a best 
option. I'm not an expert, I'm just a user (consumer) of Qt && QtCreator 
product.

Denis

18.12.2018 21:42, Matthew Woehlke пишет:

On 16/12/2018 12.00, Denis Shienkov wrote:

As we all can see, the CMake loses even QBS. We need to spent a tens of
hours/days to find out the solution, using CMake's , but with QBS same
issue solves for 30 mins or work immediatelly.  Its very funny.

Really? Because *I* don't see that.

This still sounds like FUD. Please show a concrete example (preferably
one that doesn't involve Qt specific stuff, because that's not an
entirely fair comparison) of a problem which a user who is *equally
skilled* (or unskilled) with either tool can solve easily with QBS but
cannot solve easily with CMake.

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

Re: [Development] Build system for Qt 6

2018-12-16 Thread Denis Shienkov

> I work in the Anaconda Distribution as a software packager and spend 
a significant amount of my working day battling cmake.

As we all can see, the CMake loses even QBS. We need to spent a tens of 
hours/days to find out the solution, using CMake's , but with QBS same 
issue solves for 30 mins or work immediatelly.  Its very funny.

> As I say it's "ok" for developers but not for packagers.

Neh.. No, it also is not 'ok' for developers too. :)

16.12.2018 16:21, Ray Donnelly пишет:
I'll not going to do this for you, sorry. I also pointed out the lack 
of isolation from system libraries by default as a major problem.

Take any complex project and try it. Basically very few will work on 
all generators. In particular ide generators cannot express complex 
build dependencies very well and any use of scripts will tend not to 
work unless you hardcore them for each one. I'm not in a position to 
investigate this. I just want build tools to get out of my way. I work 
in the Anaconda Distribution as a software packager and spend a 
significant amount of my working day battling cmake. As I say it's 
"ok" for developers but not for packagers.

On Sun, Dec 16, 2018, 6:05 AM Alexander Neundorf  wrote:

Hi,

On 2018 M12 15, Sat 14:49:16 CET Ray Donnelly wrote:
> On Sat, Dec 15, 2018, 6:35 AM Alexander Neundorf
mailto:neund...@kde.org> wrote:
> > On 2018 M10 30, Tue 18:33:03 CET NIkolai Marchenko wrote:
> > > > Thus this investment would be at the expense of other
things we’d like
> >
> > to
> >
> > > do, like improving our IDE, working on rearchitecting and
cleaning up
> > > our
> > > core frameworks for Qt 6 or the design tooling we are currently
> > > investing
> > > into. The Qt Company believes that those other investments
are more
> > > important for the future of Qt than our choice of build tool.
> > >
> > > I don't understand. Will it not be a return on the
investment when
> > > people
> > > use Qt "because their build tool is the best around" ?
> > > Project files are at the root of every project. There are
all sorts of
> >
> > good
> >
> > > IDEs around but ppl mostly are forced to use CMAKE which no
one seems to
> > > like.
> >
> > I do like it :-P
> > CMake can generate not only Makefiles and ninja files, but
also project
> > files for
> > IDEs (Visual Studio, XCode, Eclipse).
> > With the addition of "server mode" 2 or 3 years ago or so now
also a tight
> > integration with IDEs is possible. I think QtCreator and/or
KDevelop make
> > use
> > of this.
> > So, when using cmake the developer is free to chose whether he
wants to
> > use
> > simply an editor and make/ninja, or a full IDE.
>
> In my experience with cmake any non trivial implementation only
tends to
> work with the generator(s) the developer tested against most
recently.

Which features are not working for which generators ?
As far as I know the ASM support may not really be working with
the Visual
Studio generators. Is there more ?
IMO those are issues/bugs, and developers who want to use these
generators
should put some effort into getting this fixed.

Alex

___
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 && QtCreator cross-compilation for ARM fails

2018-12-13 Thread Denis Shienkov

> And it would be much worse for QBS, which requires much more from Qt than
> QMake. It requires QML, JavaScript, etc.

So what? A GCC too compiles with GCC... For me, as a developer it is not a
big problem and not a my. A worse problem is in CMake's ideology.

QBS just work immediatelly! Unlike of CMake! And a fact that the QBS's
just work cover all CMake's bootstrap crap. CMake has no one agvantage for
developers!



чт, 13 дек. 2018 г. в 15:02, Denis Shienkov :

> > Once you have the cross toolchain configured properly, which is a
> one-time
> > setup effort, CMake will just work, too.
>
> Will just work? What??! HAHA. Are you kidding?
>
> Why I need to configure something? Why I need to create an additional
> CMake's scripts, config files, toolchains and etc?
>
> I already have added all required cross-compilation stuff (toolchain &&
> rootfs) to
> QtCreator. With QBS && QMake it works immediatelly! But for CMake I need
> in
> additional unknown things.
>
> And is it user friendly?
>
> The Qt's PR peoples (especially the CMake maintainers) are praised that
> they
> have added a lot of CMake && QtCreator integration improvements. But, I
> don't
> see any results related event to a simple cross-compilation issues! It is
> nonsense!
>
> How much the users need to wait for improvements for this (and other)
> issues with
> CMake? It completelly gets stuck for a working process.
>
> Where is CMake advantages? I see only regressions! And it is reality!
>
> чт, 13 дек. 2018 г. в 13:48, Christian Gagneraud :
>
>> On Thu, 13 Dec 2018 at 12:27, Kevin Kofler 
>> wrote:
>> Hi Kevin,
>> > > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS?
>> >
>> > Because CMake is a widespread tool written in C++/STL
>>
>> Some people are scared of the wolf, i'm scared of the sheepple.
>>
>> > (so, unlike QBS, it
>> > does not depend on Qt, which would mean a circular dependency when
>> building
>> > Qt),
>>
>> qmake has this problem, yet it's been packaged for 10+ years without a
>> problem.
>>
>> > widely packaged for GNU/Linux distributions, and with binaries for
>> > Windows and macOS shipped by CMake upstream (Kitware) themselves. It
>> has a
>> > live upstream at Kitware, so Qt does not have to maintain it. And it is
>> > already widely used in the Qt and KDE community.
>>
>> What a bunch of cheap free statements, w/o proper comparison.
>>
>> >
>> > QBS, on the other hand, is a custom tool, in practice only used by Qt
>> and a
>> > few Qt-using projects (I know the aim is to support also non-Qt
>> projects,
>> > but this is not really used in the wild), which requires constant
>> > maintenance effort from the Qt project.
>>
>> Can you point me to something that shows the Qt "project" contributing
>> to the Qt "company" on that very particular topic?
>> The Qt Company has been looking for "employees" to work on Qbs for
>> month before dropping it, apparently nobody responded, or something...
>>
>> > >  From my point of view, the CMake it is a crap...
>> >
>> > CMake is not a "crap", it is a powerful tool, almost as easy to use as
>> > QMake, but a lot more flexible and powerful.
>>
>> Cmake is crap, it is a macro based language, like it's good to be back
>> in the 80's.
>> It has no semantic, and no concept apart form 'macro', the syntax
>> sucks, big time, every thing is just 'expression', read that one:
>>
>> https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions
>> And read that again and again, until you brain says: 'Actually, CMake
>> is "crap"!'
>>
>> >
>> > > I know, that I'm not a CMake expert, but Why I need to spent a lot
>> time
>> > > to make the CMake working wich an unknown result,
>> > > instead of just using QBS? Cross-compilation with QBS works
>> > > immediatelly, but with CMake sucks!
>> >
>> > Once you have the cross toolchain configured properly, which is a
>> one-time
>> > setup effort, CMake will just work, too.
>>
>> Oh yeah! Unless you hit some bugs, like, CMake-based cross-compilation
>> doesn't actually exists (yet) on Windows:
>>
>> https://github.com/Kitware/CMake/commit/5f0f84c7e0630d7b8190c18badd5a68e2dd08ff7
>>
>> I'm telling you: with CMake, it's 1988 Christmas, right now!
>>
>> Chris.
>> ___
>> 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 && QtCreator cross-compilation for ARM fails

2018-12-13 Thread Denis Shienkov

 > Once you have the cross toolchain configured properly, which is a
one-time
> setup effort, CMake will just work, too.

Will just work? What??! HAHA. Are you kidding?

Why I need to configure something? Why I need to create an additional
CMake's scripts, config files, toolchains and etc?

I already have added all required cross-compilation stuff (toolchain &&
rootfs) to
QtCreator. With QBS && QMake it works immediatelly! But for CMake I need in
additional unknown things.

And is it user friendly?

The Qt's PR peoples (especially the CMake maintainers) are praised that they
have added a lot of CMake && QtCreator integration improvements. But, I
don't
see any results related event to a simple cross-compilation issues! It is
nonsense!

How much the users need to wait for improvements for this (and other)
issues with
CMake? It completelly gets stuck for a working process.

Where is CMake advantages? I see only regressions! And it is reality!

чт, 13 дек. 2018 г. в 13:48, Christian Gagneraud :

> On Thu, 13 Dec 2018 at 12:27, Kevin Kofler  wrote:
> Hi Kevin,
> > > PS: WTF? Why the Qt's management choosed the CMake's instead of QBS?
> >
> > Because CMake is a widespread tool written in C++/STL
>
> Some people are scared of the wolf, i'm scared of the sheepple.
>
> > (so, unlike QBS, it
> > does not depend on Qt, which would mean a circular dependency when
> building
> > Qt),
>
> qmake has this problem, yet it's been packaged for 10+ years without a
> problem.
>
> > widely packaged for GNU/Linux distributions, and with binaries for
> > Windows and macOS shipped by CMake upstream (Kitware) themselves. It has
> a
> > live upstream at Kitware, so Qt does not have to maintain it. And it is
> > already widely used in the Qt and KDE community.
>
> What a bunch of cheap free statements, w/o proper comparison.
>
> >
> > QBS, on the other hand, is a custom tool, in practice only used by Qt
> and a
> > few Qt-using projects (I know the aim is to support also non-Qt projects,
> > but this is not really used in the wild), which requires constant
> > maintenance effort from the Qt project.
>
> Can you point me to something that shows the Qt "project" contributing
> to the Qt "company" on that very particular topic?
> The Qt Company has been looking for "employees" to work on Qbs for
> month before dropping it, apparently nobody responded, or something...
>
> > >  From my point of view, the CMake it is a crap...
> >
> > CMake is not a "crap", it is a powerful tool, almost as easy to use as
> > QMake, but a lot more flexible and powerful.
>
> Cmake is crap, it is a macro based language, like it's good to be back
> in the 80's.
> It has no semantic, and no concept apart form 'macro', the syntax
> sucks, big time, every thing is just 'expression', read that one:
>
> https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#output-expressions
> And read that again and again, until you brain says: 'Actually, CMake
> is "crap"!'
>
> >
> > > I know, that I'm not a CMake expert, but Why I need to spent a lot time
> > > to make the CMake working wich an unknown result,
> > > instead of just using QBS? Cross-compilation with QBS works
> > > immediatelly, but with CMake sucks!
> >
> > Once you have the cross toolchain configured properly, which is a
> one-time
> > setup effort, CMake will just work, too.
>
> Oh yeah! Unless you hit some bugs, like, CMake-based cross-compilation
> doesn't actually exists (yet) on Windows:
>
> https://github.com/Kitware/CMake/commit/5f0f84c7e0630d7b8190c18badd5a68e2dd08ff7
>
> I'm telling you: with CMake, it's 1988 Christmas, right now!
>
> Chris.
> ___
> 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] CMake && QtCreator cross-compilation for ARM fails

2018-12-11 Thread Denis Shienkov

Hi guys.

I have the Qt project, based on both QMake and QBS. This project should
be targeted on a Apalis iMX6 board with BSP Linux, generated from Yocto.
Also I have a Yocto SDK which is added to QtCreator (as a configured
Kits). The QMake and QBS doing the ARM cross-compilation from the
QtCreator like a sharm, but the CMake fails on the configure step:

The ASM compiler identification is GNU Found assembler:

/mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gccThe
C compiler identification is GNU 6.4.0 The CXX compiler
identification is GNU 6.4.0 Check for working C compiler:

/mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gccCheck
for working C compiler:

/mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
—
broken CMake Error at
/usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler

«/mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc»

is not able to compile a simple test program.

It fails with the following output:

Change Dir:
/tmp/QtCreator-iobfII/qtc-cmake-wCnOwxuI/CMakeFiles/CMakeTmp Run
Build

Command:«/mnt/data/Yocto-miatech/sdks/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/bin/make»
«cmTC_afb4e/fast» /lib/ld-linux-armhf.so.3: No such file or directory

CMake will not be able to correctly generate this project. Call
Stack (most recent call first): CMakeLists.txt:22 (project)

Configuring incomplete, errors occurred! See also
«/tmp/QtCreator-iobfII/qtc-cmake-wCnOwxuI/CMakeFiles/CMakeOutput.log».
See also
«/tmp/QtCreator-iobfII/qtc-cmake-wCnOwxuI/CMakeFiles/CMakeError.log».
CMake Project parsing failed.

I tried even specify the cmake's toolcain file from the QtCreator settings:

"
CMAKE_TOOLCHAIN_FILE =
/mnt/data/Yocto-miatech/sdks/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake

PS: WTF? Why the Qt's management choosed the CMake's instead of QBS?
From my point of view, the CMake it is a crap...
I know, that I'm not a CMake expert, but Why I need to spent a lot time
to make the CMake working wich an unknown result,
instead of just using QBS? Cross-compilation with QBS works
immediatelly, but with CMake sucks!

This is my soul cry ... guys, what are you doing?

Denis

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

[Development] How to use Q_IMPORT_PLUGIN macro together with *.pri files?

2018-11-03 Thread Denis Shienkov

Hi guys,

I need to create a 'static' plugin for the iOS, using qmake.
A problem is that the qmake can't generate a valid XCode project file,
using dependencies.

See, e.g. this bug: https://bugreports.qt.io/browse/QTBUG-71566.
So, I can't use XCode to deliver my application to AppStore.

Instead of using a static plugins I want to include and compile my plugins
via
my-plugin.pri files.

But it does not work, because linking failed when I use this code:

...

Q_IMPORT_PLUGIN(MyPlugin)

...

with an error, like:

Undefined symbols for architecture x86_64:

"qt_static_plugin_BasicToolsPlugin()", referenced from:

StaticBasicToolsPluginPluginInstance::StaticBasicToolsPluginPluginInstance()
in main.o

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

Is any workaround to avoid this and to use a 'static' plugins in a fom of a
*.pri files?

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

[Development] QtConcurrent replacement candidate

2018-10-31 Thread Denis Kormalev

Hi,

As part of our work projects we have a framework (named Proof and partly open 
sourced). Most part of it is not really interesting outside of our industry, 
but one of its basic ideas is heavy usage of future/promise technology with API 
similar to one used in Scala. We also have tasks scheduling helpers that are 
based on these futures.
I would like to ask Qt community if Qt itself needs QFuture/QtConcurrent 
redoing and replacing with something similar to what we do. 
If community will find it interesting I'm more than happy to implement it and 
do everything to make it as part of Qt someday.
Current API is a bit specific for our projects and of course need to be 
reworked, but main idea can be seen from examples listed at 
https://github.com/opensoft/proofseed#futures-examples 
<https://github.com/opensoft/proofseed#futures-examples> .
Future/Promise API can be seen at 
https://github.com/opensoft/proofseed/blob/develop/include/proofseed/future.h 
<https://github.com/opensoft/proofseed/blob/develop/include/proofseed/future.h> 
. Main idea is that all interaction is done via QSharedPointer wrappers. I 
assume it is not the best way to do it and probably FutureSP should be named 
Future (with protected inheritance from QSharedPointer and having all methods 
from Future) and Future should be named something like FutureData. 
Tasks scheduling is done mostly via run() function specified at 
https://github.com/opensoft/proofseed/blob/develop/include/proofseed/tasks.h#L181
 
<https://github.com/opensoft/proofseed/blob/develop/include/proofseed/tasks.h#L181>
 . 
Future also has negative class named Failure, which in case of Qt adoption 
probably should be just a QVariant (current implementation is, as I mentioned 
previously, a bit specific for our projects).

Anyway, I would like to start a discussion if Qt community thinks that 
something like that could be useful as part of Qt itself. In this case I can 
work on basic API with having Future inherited from QSharedPointer and show it 
for early API review.
I never did anything greater than bugfixes for Qt, so I would also need few 
recommendations about where to start (I assume I will need a repo in qt 
playground for stuff like that).

Another question is about legal stuff. This library is BSD-3 licensed and I 
assume I will need some documents from my company if this implementation will 
be heavily similar to existing library. If anyone can advise (again, of course 
if Qt community will find it interesting) I would really appreciate it. 2

--
Regards,
Denis Kormalev

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

Re: [Development] Build system for Qt 6

2018-10-30 Thread Denis Shienkov

Hi all, my personal things:

Welcome to the era of stagnation and dinosaurs. The new
"revolutioning" Qt6 will be released semi-dead. It will
be overgrowned with mold, moss and fungi in the form of
CMake. This will not be a new life, but it will be an
attempt to prolong the convulsions.

A real new life could give the QBS, that pushed be a new
branch of the spiral of development. It would stimulate
be the QBS integration with others IDE and etc.

PS: I don't know, what is it: or an "effective management"
or an "evil intent" or an  "CMake lobby", or "not enough
money". Perhaps the thesis that "Millions of flies cannot
be mistaken when they choose shit" works here.

Anyway, RIP QBS, You were a great friend, I never forget you.
I drink Vodka and grieve about the innocently murdered projects
for the sake of conjuncture.

== R I P, QBS ==

IMHO, :(

вт, 30 окт. 2018 г. в 12:08, Richard Weickelt :

>
> > Qbs is something that has been developed almost exclusively by The Qt
> > Company. As such, TQtC had to also look at it from a business perspective
> > and how it fits into the larger picture of making Qt successful. To make
> > a long story short, while Qbs is pretty cool and interesting technology,
> > it doesn’t really help us expand the Qt ecosystem and usage.
>
> Qbs has made the development of multi-platform applications with multiple
> libraries a breeze for me. Even projects that contain firmware for
> different
> target architectures in addition to a Qt application are no problem at all
> with Qbs. Thanks to Qbs, I can focus on code and not on the build system. I
> achieve more in less time.
>
> I always thought that Qbs was a great example for using QML.
>
> > To make Qbs really successful would require a rather large effort and
> > investment in promoting it towards the larger C++ ecosystem as a new
> > build tool. At the same time it has to be an open source product to stand
> > any chance in the market. Together this makes it challenging for TQtC to
> > see how to recover that investment. Thus this investment would be at the
> > expense of other things we’d like to do, like improving our IDE, working
> > on rearchitecting and cleaning up our core frameworks for Qt 6 or the
> > design tooling we are currently investing into. The Qt Company believes
> > that those other investments are more important for the future of Qt than
> > our choice of build tool.
>
> It seems that Qbs never got much traction within the Qt Company either.
> Outside the regular blog posts, I don't see any attempt to promote Qbs
> anywhere. Correct me if I'm wrong. I may have noticed that Jake Petroules
> did his best to get the word out, but I guess that was his private mission
> rather than his official role in the Qt Company. What I can't complain
> about
> is the unprecedented dedication and professionalism of Christian, Jörg and
> Jake on this project. Also all support questions were answered in lightning
> speed.
>
> > As such, we were left with the question on whether we need Qbs as the
> > build system for Qt 6 or whether cmake (as the other alternative) would
> > be up to the task.
> > [..]
> > Given that we are confident we can build Qt 6 with cmake, I believe that
> > it makes most sense to follow down that route. In case you’re interested,
> > you can have a look at the cmake prototype code for qtbase on Gerrit in
> > the wip/cmake branch. Please also let us know if you’re interested in
> > helping with the effort of porting Qt’s build system over to cmake.
> >
> > We have been developing Qbs over the last years, and as such are
> > committed to it for some more time. We are planning on another feature
> > release in the first quarter of next year and will support it in Qt
> > Creator for at least another year. Qbs is open source and if someone
> > wants to take over and develop it further let us know as well. I’d also
> > like to use this place to thank Christian and Jörg for all their great
> > work on Qbs  (and of course also anybody else who contributed to it).
>
> How can we leverage from the next half year to smoothly turn Qbs into a
> community-owned OS project? Does anybody know a positive role-model for
> this?
>
> I don't want to miss out on the productivity gains I've made with Qbs, but
> on the other hand I have very little free time. However, I would
> voluntarily
> contribute to the documentation of Qbs.
>
> Richard
>
>
> ___
> 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] Does QGeoPositionInfoSource work from an Android service?

2018-10-25 Thread Denis Shienkov

Alex,

I have created a bug: https://bugreports.qt.io/browse/QTBUG-71396
Please look on...

Denis

чт, 25 окт. 2018 г. в 9:42, Alex Blasche :

> Hi Denis,
>
> At least in the past it worked as I remember having tested the use case.
> Do you have a backtrace?
>
> And yes, Ryan's comment is correct in that you are missing essential error
> checking in your code.
>
> --
> Alex
>
> ____
> From: Denis Shienkov 
> Sent: Wednesday, 24 October 2018 6:31:59 PM
> To: development@qt-project.org; Alex Blasche; BogDan Vatra
> Subject: Does QGeoPositionInfoSource work from an Android service?
>
> Hi all,
>
> I tried to make it work from the Android service:
>
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
>
> Q_LOGGING_CATEGORY(APP, "bug.svc")
>
>
> int main(int argc, char *argv[])
>
> {
>
> QAndroidService::setAttribute(Qt::AA_EnableHighDpiScaling);
>
> QAndroidService app(argc, argv);
>
>
> qCDebug(APP) << "I'm service";
>
>
> const auto t = new QTimer(qApp);
>
> QCoreApplication::connect(t, ::timeout, []() {
>
> static int counter = 0;
>
> qCWarning(APP) << "CNT:" << counter;
>
> ++counter;
>
> });
>
> t->start(1000);
>
>
> const auto ps = QGeoPositionInfoSource::createDefaultSource(qApp);
>
> QCoreApplication::connect(ps, ::positionUpdated,
>
>   [=](const QGeoPositionInfo ) {
>
> const auto coord = update.coordinate();
>
> qCDebug(APP) << "CRD:" << coord;
>
> });
>
> ps->setUpdateInterval(3000);
>
> ps->startUpdates();
>
>
> return app.exec();
>
> }
>
> but a service, seems, crashed at all (at least I did not see any debugging
> log from the logcat).
>
> But if I try to cemment out all code, related to the locations, and keep a
> code with the timer,
> then I see the counters output.
>
> I tried it on Android x86 && Qt 5.11.2 && Android API 21.
>
> E.g. from here:
> https://stackoverflow.com/questions/13345002/locationmanager-in-service
> I see that it is possible to wotk with Android's LocationManager from the
> service... BUT,
> it does not work with QGeoPositionInfoSource!
>
> BR,
> Denis
>
>
>
>
> ___
> 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

[Development] Does QGeoPositionInfoSource work from an Android service?

2018-10-24 Thread Denis Shienkov

Hi all,

I tried to make it work from the Android service:

#include 

#include 

#include 

#include 


Q_LOGGING_CATEGORY(APP, "bug.svc")


int main(int argc, char *argv[])

{

QAndroidService::setAttribute(Qt::AA_EnableHighDpiScaling);

QAndroidService app(argc, argv);


qCDebug(APP) << "I'm service";


const auto t = new QTimer(qApp);

QCoreApplication::connect(t, ::timeout, []() {

static int counter = 0;

qCWarning(APP) << "CNT:" << counter;

++counter;

});

t->start(1000);


const auto ps = QGeoPositionInfoSource::createDefaultSource(qApp);

QCoreApplication::connect(ps, ::positionUpdated,

  [=](const QGeoPositionInfo ) {

const auto coord = update.coordinate();

qCDebug(APP) << "CRD:" << coord;

});

ps->setUpdateInterval(3000);

ps->startUpdates();


return app.exec();

}


but a service, seems, crashed at all (at least I did not see any debugging
log from the logcat).

But if I try to cemment out all code, related to the locations, and keep a
code with the timer,
then I see the counters output.

I tried it on Android x86 && Qt 5.11.2 && Android API 21.

E.g. from here:
https://stackoverflow.com/questions/13345002/locationmanager-in-service
I see that it is possible to wotk with Android's LocationManager from the
service... BUT,
it does not work with QGeoPositionInfoSource!

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

Re: [Development] Qt Android Service

2018-10-12 Thread Denis Shienkov

Hmm... Maybe anybody can share a *real* simple working example on Qt 5.11?
(with sources)? :)

пт, 12 окт. 2018 г. в 16:58, Jason H :

> I would not attribute this to Qt without a thorough investigation. My only
> use of serves on Android was a Qt app with a normal Android service. As I
> understand it, you can't have both Qt App and service in the same app.
> Something simple like a manifest error is more likely the issue, but
> without more detail, helping is impossible.
>
>
> *Sent:* Friday, October 12, 2018 at 9:49 AM
> *From:* "Mikhail Svetkin" 
> *To:* denis.shien...@gmail.com
> *Cc:* development@qt-project.org
> *Subject:* Re: [Development] Qt Android Service
> I have tried a year ago. It was ok, but unfortunately i don't remember
> version of Qt.
>
> Best regards,
> Mikhail
>
> On Fri, 12 Oct 2018 at 15:45, Denis Shienkov 
> wrote:
>
>> Hi guys.
>>
>> Does anybody tried to create and start the Android Service using Qt?
>>
>> I tried this example:
>>
>> * https://github.com/bbernhard/qtandroidservices_example ,
>>
>> and also have read this reccomendations from KDAB:
>>
>> * https://www.kdab.com/qt-android-create-android-service-using-qt/
>>
>> But a service do not start at all.
>>
>> I use Qt 5.11.2.
>>
>> Is it possible at all, or it broken as usual in Qt?
>>
>> BR,
>> Denis
>> ___
>> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt Android Service

2018-10-12 Thread Denis Shienkov

Hi guys.

Does anybody tried to create and start the Android Service using Qt?

I tried this example:

* https://github.com/bbernhard/qtandroidservices_example ,

and also have read this reccomendations from KDAB:

* https://www.kdab.com/qt-android-create-android-service-using-qt/

But a service do not start at all.

I use Qt 5.11.2.

Is it possible at all, or it broken as usual in Qt?

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

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-09-10 Thread Denis Shienkov

Ok, I have compiled my Qt 5.11.1 with native XCB painting support, using
following configure options:

-system-freetype \
-fontconfig \
-xcb-native-painting \

but I don't see any differences using the QT_XCB_NATIVE_PAINTING=1 or
without of it.
The CPU usage still is a big ~71% in both cases.

How I can know that the QT_XCB_NATIVE_PAINTING are applied?

Denis


пн, 10 сент. 2018 г. в 14:36, Denis Shienkov :

> I even have added this:
>
> -xcb-native-painting \
>
> as described in qtbase/dist/changes-5.10.0 , but it has not effect too..
> no any errors printed out.
>
>
>
> пн, 10 сент. 2018 г. в 14:29, Denis Shienkov :
>
>> > --feature-xcb-native-painting
>>
>> I have added this to my configure script, but it has not any effects, it
>> does not show an additional errors at configure time.
>> Besides, I have not found this 'feature-xcb-native-painting' pattern in
>> qt5 sources:
>>
>>  grep -rn . -e 'feature-xcb-native-painting'
>>
>> Denis
>>
>>
>> пн, 10 сент. 2018 г. в 14:04, Dominik Holland <
>> dominik.holl...@pelagicore.com>:
>>
>>> Hi,
>>>
>>> try to pass --feature-xcb-native-painting to configure. That should
>>> enable it or atleast explain what's missing.
>>>
>>> Dominik
>>>
>>>
>>> Am 09/10/2018 um 12:59 PM schrieb Denis Shienkov:
>>> > Hi guys,
>>> >
>>> > does this mean (for Qt 5.11.1 config output):
>>> >
>>> >   X11:
>>> > Using system-provided XCB libraries .. no
>>> > EGL on X11 ... yes
>>> > Xinput2 .. no
>>> > XCB XKB .. yes
>>> > XLib . yes
>>> > XCB render ... yes
>>> > XCB GLX .. yes
>>> > XCB Xlib . yes
>>> > Using system-provided xkbcommon .. no
>>> > Native painting (experimental) ... no
>>> >
>>> > that this required *native painting* feature is not configured
>>> > successfully?
>>> >
>>> > Denis
>>> >
>>> > чт, 6 сент. 2018 г. в 0:02, Thiago Macieira >> > <mailto:thiago.macie...@intel.com>>:
>>> >
>>> > On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
>>> > > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
>>> > > >> It also raises questions about the status of the X11 paint
>>> > engine.
>>> > > >> Several bugs have been closed because of not fixing the X11
>>> paint
>>> > > >> engine anymore.
>>> > > >
>>> > > > This being the reason why the X11 engine is not good for
>>> everyone.
>>> > >
>>> > > O.k. - but that does not answer my question regarding the status
>>> > of the
>>> > > code ?
>>> >
>>> > I'm guessing it's
>>> > "Experimental, use at your own risk, please report bugs, don't
>>> > expect quick
>>> > turnaround time."
>>> >
>>> > --
>>> > Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com
>>> >
>>> >   Software Architect - Intel Open Source Technology Center
>>> >
>>> >
>>> >
>>> > ___
>>> > Development mailing list
>>> > Development@qt-project.org <mailto: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
>>>
>>> ___
>>> 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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-09-10 Thread Denis Shienkov

I even have added this:

-xcb-native-painting \

as described in qtbase/dist/changes-5.10.0 , but it has not effect too.. no
any errors printed out.



пн, 10 сент. 2018 г. в 14:29, Denis Shienkov :

> > --feature-xcb-native-painting
>
> I have added this to my configure script, but it has not any effects, it
> does not show an additional errors at configure time.
> Besides, I have not found this 'feature-xcb-native-painting' pattern in
> qt5 sources:
>
>  grep -rn . -e 'feature-xcb-native-painting'
>
> Denis
>
>
> пн, 10 сент. 2018 г. в 14:04, Dominik Holland <
> dominik.holl...@pelagicore.com>:
>
>> Hi,
>>
>> try to pass --feature-xcb-native-painting to configure. That should
>> enable it or atleast explain what's missing.
>>
>> Dominik
>>
>>
>> Am 09/10/2018 um 12:59 PM schrieb Denis Shienkov:
>> > Hi guys,
>> >
>> > does this mean (for Qt 5.11.1 config output):
>> >
>> >   X11:
>> > Using system-provided XCB libraries .. no
>> > EGL on X11 ... yes
>> > Xinput2 .. no
>> > XCB XKB .. yes
>> > XLib . yes
>> > XCB render ... yes
>> > XCB GLX .. yes
>> > XCB Xlib ..... yes
>> > Using system-provided xkbcommon .. no
>> > Native painting (experimental) ... no
>> >
>> > that this required *native painting* feature is not configured
>> > successfully?
>> >
>> > Denis
>> >
>> > чт, 6 сент. 2018 г. в 0:02, Thiago Macieira > > <mailto:thiago.macie...@intel.com>>:
>> >
>> > On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
>> > > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
>> > > >> It also raises questions about the status of the X11 paint
>> > engine.
>> > > >> Several bugs have been closed because of not fixing the X11
>> paint
>> > > >> engine anymore.
>> > > >
>> > > > This being the reason why the X11 engine is not good for
>> everyone.
>> > >
>> > > O.k. - but that does not answer my question regarding the status
>> > of the
>> > > code ?
>> >
>> > I'm guessing it's
>> > "Experimental, use at your own risk, please report bugs, don't
>> > expect quick
>> > turnaround time."
>> >
>> > --
>> > Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com>
>> >   Software Architect - Intel Open Source Technology Center
>> >
>> >
>> >
>> > ___
>> > Development mailing list
>> > Development@qt-project.org <mailto: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
>>
>> ___
>> 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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-09-10 Thread Denis Shienkov

Hi guys,

does this mean (for Qt 5.11.1 config output):

  X11:
Using system-provided XCB libraries .. no
EGL on X11 ... yes
Xinput2 .. no
XCB XKB .. yes
XLib . yes
XCB render ... yes
XCB GLX .. yes
XCB Xlib . yes
Using system-provided xkbcommon .. no
Native painting (experimental) ... no

that this required *native painting* feature is not configured
successfully?

Denis

чт, 6 сент. 2018 г. в 0:02, Thiago Macieira :

> On Wednesday, 5 September 2018 12:57:39 PDT Uwe Rathmann wrote:
> > On Wed, 05 Sep 2018 09:55:41 -0700, Thiago Macieira wrote:
> > >> It also raises questions about the status of the X11 paint engine.
> > >> Several bugs have been closed because of not fixing the X11 paint
> > >> engine anymore.
> > >
> > > This being the reason why the X11 engine is not good for everyone.
> >
> > O.k. - but that does not answer my question regarding the status of the
> > code ?
>
> I'm guessing it's
> "Experimental, use at your own risk, please report bugs, don't expect
> quick
> turnaround time."
>
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-09-05 Thread Denis Shienkov

> Using Qwt with a current Qt version seems to run
the same ways as with Qt4/X11 without any problems.

Uwe, wow :) What Qt5 version are you use?

Denis

ср, 5 сент. 2018 г. в 12:31, Uwe Rathmann :

> On Wed, 05 Sep 2018 09:56:36 +0100, Sérgio Martins via Development wrote:
>
> >> What needs to be done to make it become effective ?
> >
> > export QT_XCB_NATIVE_PAINTING=1
>
> I did a quick check with using QPainter on a QPixmap and indeed it runs
> the X11 paint engine. Using Qwt with a current Qt version seems to run
> the same ways as with Qt4/X11 without any problems.
>
> So this is great news - at least for me, others might be aware of this
> option for a longer time.
>
> I also googled for QT_XCB_NATIVE_PAINTING without almost no results. I
> understand, that reverting a decision is not stuff for big announcements,
> but for such an important improvement: has it been communicated at least
> somewhere ?
>
> It also raises questions about the status of the X11 paint engine.
> Several bugs have been closed because of not fixing the X11 paint engine
> anymore.
>
> Does it make sense to write bug reports, when it behaves not according to
> the specs - or when it differs from what the raster paint engine does ?
>
> Uwe
>
> ___
> 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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-09-05 Thread Denis Shienkov

Hi,

> added the native X11 graphicssystem support from Qt4 to Qt5

According to that commit (and next depends commits), seems this porting is
not completed yet to Qt5.
So, it is interest to know: can we use it in current time, and since what
of Qt version? Is it work at all as in Qt4?

And, as Uwe said: how we can enable this feature, what needs to do?

Denis


ср, 5 сент. 2018 г. в 9:01, Uwe Rathmann :

> On Tue, 04 Sep 2018 20:51:38 +0200, Martin Koller wrote:
>
> > added the native X11 graphicssystem support from Qt4 to Qt5
>
> Very cool.
>
> Andrew told me that there were 2 concurrent attempts to revive X11 as the
> situation for running widget applications on remote desktops is simply
> not good, when using Raster. But I never realized, that finally something
> went into the Qt code base.
>
> What needs to be done to make it become effective ?
>
> Uwe
>
>
> ___
> 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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-09-04 Thread Denis Shienkov


Uwe,

> Don't forget to set the graphic system to "native" - the default 
since 4.8 is raster


How I can do it for Qt4?  Do you mean, I need to specify an appropriate 
'-platform' option

before starting of my application on Qt4?

PS: Many thanks for your help. Of course I will create an additional 
questions

in 'Qwt' topic of qtcentre forum when the time comes. :)

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

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-09-04 Thread Denis Shienkov

Hi, guys.

Many thanks for your help.

But a problem is that I already have a QtWidgets-based application. And 
porting to the QtQuick

+ hacking with custom QuickPlots (or other stuff) will take a lot of time.

Uwe,
what if I try to back-port my application from Qt5 to Qt4 with X11 
support (on iMX6).
As I understand, then I do not need to specify the OpenGL Widgets with 
Qt4. Is it?

Is it will help? Or do I need to use the QtQuick anyway?

Denis

04.09.2018 12:00, Arno Rehn пишет:

Hi everyone,

because I've hit the same issues on an embedded platform with eglfs 
(was the Raspberry Pi, not iMX6), I've thrown together some classes 
for native QtQuick/OpenGL plotting. Performance on the Raspberry Pi is 
excellent from my experience (5% CPU usage on the R-Pi with a 
continuously updated plot).

Repository: https://gitlab.com/qtquickplot/qtquickplot
Blog entry with some explanations: 
http://www.arnorehn.de/blog/2014/12/quickplot-a-collection-of-native-qtquick-plot-items/

Regards,

Am 29.08.2018 um 19:49 schrieb Denis Shienkov:

Hi,

 > have you tried QOpenGlWidget ?

It does not work together (can't be mixed) with an usual QtWidgets 
using the 'eglfs' backend.

 > QtCharts to be more QtQuicker and more featured

As I see from the QtCharts sources, it also renders via 
QGraphicsScene && QGraphicsWidget even in QtQuick.

29.08.2018 18:56, Vlad Stelmahovsky пишет:

have you tried QOpenGlWidget ?

otherwise you dont have other options: plain QWidget's does not HW 
accelerated

or, you can extend QtCharts to be more QtQuicker and more featured. 
everyone will be happy :)

On 8/29/18 11:39 AM, Denis Shienkov wrote:

Hi all.

I have an Apalis iMX6 board with the Yocto's image with the working 
'eglfs' and 'linuxfb'  backends (without of X11 support).

I need to create a 'pure' QtWidgets application, where I need to 
use a real-time plotting with the Qwt library (using the Qt Quick 
is not an option, as there the QtCharts is not ready for usage) .

But, I'm sadly surprised that a 2D painting takes ~100% CPU loading 
as with the 'eglfs' and as with 'linuxfb' backends. It is not an 
acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% 
CPU loading.

Is any workarounds for this? Maybe I need to re-build the Yocto's 
image to enable the X11 'xcb' support?

BR,
Denis

___
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

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

Re: [Development] Configure Qt gerrit git ssh access via Tor on Linux

2018-09-02 Thread Denis Shienkov

Wow, now it does work with following config:

[code]
Host codereview.qt-project.org
Port 29418
User 
Ciphers +aes256-cbc
ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
[/code]

Many thanks to all for help! :)

Denis

вс, 2 сент. 2018 г. в 13:18, Denis Shienkov :

> Hi Andre,
>
> > Please note that you can always use git and Gerrit with HTTPS, the
> HTTPS password is in your personal settings page in Gerrit. I've already
> used that in environments where SSH was blocked.
>
> But the HTTPS access also is blocked for me(us),  the
> https://codereview.qt-project.org/ site does not open too. So, it is
> possible that and git over http will be blocked too (I did not checked yet).
>
> Denis
>
> 02.09.2018 12:16, André Hartmann пишет:
>
> Hi Denis and Konstantin,
>
> I've run into problems on Debian testing recently and it appears to have
> been the same problem as you're having. Perhaps you could try something
> like this:
>
> GIT_SSH_COMMAND="ssh -c aes256-cbc" 
>
>
> Looks like https://bugreports.qt.io/browse/QTQAINFRA-1530
>
> It's been a month or so, but as far as I can remember this solved it for
> me.
>
>
> Probably you got an SSH client update...
>
> Please note that you can always use git and Gerrit with HTTPS, the HTTPS
> password is in your personal settings page in Gerrit. I've already used
> that in environments where SSH was blocked.
>
> Best regards,
> André
>
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Configure Qt gerrit git ssh access via Tor on Linux

2018-09-02 Thread Denis Shienkov


Hi Andre,

> Please note that you can always use git and Gerrit with HTTPS, the 
HTTPS password is in your personal settings page in Gerrit. I've already 
used that in environments where SSH was blocked.


But the HTTPS access also is blocked for me(us),  the 
https://codereview.qt-project.org/ site does not open too. So, it is 
possible that and git over http will be blocked too (I did not checked yet).


Denis


02.09.2018 12:16, André Hartmann пишет:

Hi Denis and Konstantin,

I've run into problems on Debian testing recently and it appears to 
have been the same problem as you're having. Perhaps you could try 
something like this:


GIT_SSH_COMMAND="ssh -c aes256-cbc" 


Looks like https://bugreports.qt.io/browse/QTQAINFRA-1530

It's been a month or so, but as far as I can remember this solved it 
for me.


Probably you got an SSH client update...

Please note that you can always use git and Gerrit with HTTPS, the 
HTTPS password is in your personal settings page in Gerrit. I've 
already used that in environments where SSH was blocked.


Best regards,
André


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

[Development] Configure Qt gerrit git ssh access via Tor on Linux

2018-09-02 Thread Denis Shienkov


Hi guys.

I need to use the tor to avoid a blocking of the 
codereview.qt-project.org (in my country sad).
The git-ssh configuration described here: 
http://wiki.qt.io/Setting_up_Gerrit

I need to do it on ArchLinux.
I successfully do it on Windows with following ~/.ssh/config:

[code]
Host codereview.qt-project.org
Port 29418
User 
ProxyCommand ncc -X 5 -x localhost:9050 %h %p
[/code]

but same config does not work with ArchLinux (where I just replace 'ncc' 
with 'nc'),

it returns with an error:

[quote]
    [denis@arch qtlocation]$ git fetch 
ssh://@codereview.qt-project.org:29418/qt/qtlocation 
refs/changes/92/237992/1 && git checkout FETCH_HEAD
    Unable to negotiate with UNKNOWN port 65535: no matching cipher 
found. Their offer: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc

    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.
[/quote]

Then I have created another config as described in "Setting_up_Gerrit":

[code]
Host http://codereview.qt-project.org-gerrit
    Hostname http://codereview.qt-project.org
    Port 29418
    User 
    Ciphers +aes256-cbc
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa.pub
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
[/code]

then It returns with another error:

[quote]
    [denis@arch qtlocation]$ git fetch 
ssh://@codereview.qt-project.org:29418/qt/qtlocation 
refs/changes/92/237992/1 && git checkout FETCH_HEAD
    Unable to negotiate with 54.229.21.112 port 29418: no matching 
cipher found. Their offer: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc

    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.
[/quote]

Of course, I have added the SSH-keys to the my gerrit profile, have 
installed and started the tor service (via systemctl), and have 
installed the socat && openbsd-netcat.


PS: I have checked the tor service via chromium browser with configured 
socks5 proxy.


Could someone help me please?

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

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

2018-08-30 Thread Denis Shienkov

Hi Uwe,

many thanks for your help! :)

Yeah, seems that Qt5 && X11 && 'xcb' backend with the Qwt 6.2 and
QwtPlotOpenGLCanvas
does help a bit. The iMX6 CPU usage now is ~50% (instead of previous 100%).

PS: But compilation for latest Qwt version from trunk r2921 fails, please
look on this my post:
https://www.qtcentre.org/threads/69743-Qwt-6-3-0-(from-qwt-code-r2921-trunk)-compilation-fails-on-Ubuntu-18-04?p=303603#post303603

BR,
Denis

чт, 30 авг. 2018 г. в 10:46, Uwe Rathmann :

> On Wed, 29 Aug 2018 16:43:40 +0300, Denis Shienkov wrote:
>
> > So, there are no way to improve an acceleration and to minimize the CPU
> > loading?
>
> It depends on the requirements of your application, but when it comes to
> oscilloscope alike widgets your best choice is Qt4/X11.
>
> The X11 paint engine is hardware accelerated, it even allows painting
> outside of paint events - what is important for incremental painting.
>
> ( The fact, that Qt 4.8 prefers using raster with the argument of
> performance it is totally nonsense, when it comes to any sort of vector
> graphics. )
>
> Furthermore the X11 paint engine simply has a better quality. The sort of
> bugs coming and going with the various Qt versions is a nightmare for any
> sort of graphics framework. Actually my job for today is to find a work
> around for this one: https://bugreports.qt.io/browse/QTBUG-70101
>
> --
>
> If you need to go with Qt5 I would recommend to use a platform that
> allows for using QOpenGlWidget - X11 again is IMHO not a bad choice.
> Actually one of our terminals is a iMX6, where we do this ( because we
> needed VNC support ).
>
> Next I recommend Qwt from SVN trunk, where you can simply assign a
> QwtPlotOpenGLCanvas to achieve hardware acceleration. The quality of the
> OpenGL paint engine is not as good as X11 or Raster, but for a
> oscilloscope things usually do not need to be pixel perfect.
>
> --
>
> Finally you should not ignore algorithmic options to reduce what has to
> be painted. How to optimize the rendering process is often quite
> individual, but often QwtPlotCurve::FilterPointsAggressive ( since Qwt
> 6.2 ) has a significant effect in oscilloscope alike applications.
>
> In fact I have been contacted quite often with oscilloscope applications
> struggling with performance issues and often it could be solved on a
> algorithmic level.
>
> As an inspiration you could also try to run the oscilloscope demo of Qwt
> on your board. You will notice, that it runs with almost no CPU usage
> because it mostly paints incrementally. Of course this only works because
> the design of the user interface is made for this, but maybe you can do
> something similar.
>
> Uwe
>
>
> ___
> 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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

Hi,

> have you tried QOpenGlWidget ?

It does not work together (can't be mixed) with an usual QtWidgets using 
the 'eglfs' backend.

> QtCharts to be more QtQuicker and more featured

As I see from the QtCharts sources, it also renders via QGraphicsScene 
&& QGraphicsWidget even in QtQuick.

29.08.2018 18:56, Vlad Stelmahovsky пишет:

have you tried QOpenGlWidget ?

otherwise you dont have other options: plain QWidget's does not HW 
accelerated

or, you can extend QtCharts to be more QtQuicker and more featured. 
everyone will be happy :)

On 8/29/18 11:39 AM, Denis Shienkov wrote:

Hi all.

I have an Apalis iMX6 board with the Yocto's image with the working 
'eglfs' and 'linuxfb'  backends (without of X11 support).

I need to create a 'pure' QtWidgets application, where I need to use 
a real-time plotting with the Qwt library (using the Qt Quick is not 
an option, as there the QtCharts is not ready for usage) .

But, I'm sadly surprised that a 2D painting takes ~100% CPU loading 
as with the 'eglfs' and as with 'linuxfb' backends. It is not an 
acceptable, because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU 
loading.

Is any workarounds for this? Maybe I need to re-build the Yocto's 
image to enable the X11 'xcb' support?

BR,
Denis

___
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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

> Most Qt widgets are not drawn using opengl but instead are rasterized.  I
was surprised when I first learned this as well.

So, there are no way to improve an acceleration and to minimize the CPU
loading?

PS: I tried to mix the OpenGL widgets with usual widgets, but the 'eglfs'
says that it is impossible to mix it. This is some sort of hopeless
situation. (((

BR,
Denis

ср, 29 авг. 2018 г. в 15:51, drwho :

> Hi Denis,
>
> Most Qt widgets are not drawn using opengl but instead are rasterized.  I
> was surprised when I first learned this as well.
> "QPainter <http://doc.qt.io/qt-5/qpainter.html>
> <http://doc.qt.io/qt-5/qpainter.html> provides API for drawing vector
> graphics, text and images onto different surfaces, or QPaintDevice
> <http://doc.qt.io/qt-5/qpaintdevice.html>
> <http://doc.qt.io/qt-5/qpaintdevice.html> instances, such as QImage
> <http://doc.qt.io/qt-5/qimage.html> <http://doc.qt.io/qt-5/qimage.html>,
> QOpenGLPaintDevice
> <http://doc.qt.io/qt-5/whatsnew50.html#qopenglpaintdevice>
> <http://doc.qt.io/qt-5/whatsnew50.html#qopenglpaintdevice>, QWidget
> <http://doc.qt.io/qt-5/qwidget.html> <http://doc.qt.io/qt-5/qwidget.html>,
> and QPrinter <http://doc.qt.io/qt-5/qprinter.html>
> <http://doc.qt.io/qt-5/qprinter.html>. The actual drawing happens in the
> QPaintDevice <http://doc.qt.io/qt-5/qpaintdevice.html>
> <http://doc.qt.io/qt-5/qpaintdevice.html>'s QPaintEngine
> <http://doc.qt.io/qt-5/qpaintengine.html>
> <http://doc.qt.io/qt-5/qpaintengine.html>. The software rasterizer and
> the OpenGL (ES) 2.0 back-ends are the two most important QPaintEngine
> <http://doc.qt.io/qt-5/qpaintengine.html>
> <http://doc.qt.io/qt-5/qpaintengine.html> implementations. *The raster
> paint engine is Qt’s software rasterizer, and is used when drawing on a
> QImage <http://doc.qt.io/qt-5/qimage.html>
> <http://doc.qt.io/qt-5/qimage.html> or QWidget
> <http://doc.qt.io/qt-5/qwidget.html> <http://doc.qt.io/qt-5/qwidget.html>.*
> Its strength over the OpenGL paint engine is its high quality when
> antialiasing is enabled, and a complete feature set.”
>
>
> On 29/08/18 06:21 AM, Denis Shienkov wrote:
>
> I even have created a simple test app, which re-fill the 1280x800 rect
> every 50 msec with the 'red' and 'green' colors.
>
> [code]
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
>  class Widget final : public QWidget
>
> {
>
> public:
>
> explicit Widget(QWidget *parent = nullptr);
>
> private:
>
> void paintEvent(QPaintEvent *event) final;
>
> void timerEvent(QTimerEvent *event) final;
>
> };
>
>  Widget::Widget(QWidget *parent)
>
> : QWidget(parent)
>
> {
>
> startTimer(50);
>
> }
>
>  void Widget::paintEvent(QPaintEvent *event)
>
> {
>
> QPainter p(this);
>
> static bool toggled = false;
>
> const auto color = (toggled) ? QColor(Qt::red) : QColor(Qt::green);
>
> const auto rect = event->rect();
>
> p.fillRect(rect, color);
>
> toggled = !toggled;
>
> }
>
>  void Widget::timerEvent(QTimerEvent *event)
>
> {
>
> Q_UNUSED(event);
>
> update();
>
> }
>
>  int main(int argc, char *argv[])
>
> {
>
> QApplication app(argc, argv);
>
> Widget w;
>
> w.setMinimumSize(1280, 800);
>
> w.show();
>
> return app.exec();
>
> }
>
> [/code]
>
> And then I see that the Desktop PC has the ~0% CPU load, but the iMX6 has
> ~50% CPU load. WTF?
>
> BR,
> Denis
>
>
>
> ср, 29 авг. 2018 г. в 12:39, Denis Shienkov :
>
>> Hi all.
>>
>> I have an Apalis iMX6 board with the Yocto's image with the working
>> 'eglfs' and 'linuxfb'  backends (without of X11 support).
>>
>> I need to create a 'pure' QtWidgets application, where I need to use a
>> real-time plotting with the Qwt library (using the Qt Quick is not an
>> option, as there the QtCharts is not ready for usage) .
>>
>> But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as
>> with the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable,
>> because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading.
>>
>> Is any workarounds for this? Maybe I need to re-build the Yocto's image
>> to enable the X11 'xcb' support?
>>
>> BR,
>> Denis
>>
>>
>>
>
> ___
> Development mailing 
> listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
>
>
> ___
> 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] iMX6 EGLGS 2D (QtWidgets) painting acceleration

I even have created a simple test app, which re-fill the 1280x800 rect
every 50 msec with the 'red' and 'green' colors.

[code]

#include 

#include 

#include 

#include 


class Widget final : public QWidget

{

public:

explicit Widget(QWidget *parent = nullptr);

private:

void paintEvent(QPaintEvent *event) final;

void timerEvent(QTimerEvent *event) final;

};


Widget::Widget(QWidget *parent)

: QWidget(parent)

{

startTimer(50);

}


void Widget::paintEvent(QPaintEvent *event)

{

QPainter p(this);

static bool toggled = false;

const auto color = (toggled) ? QColor(Qt::red) : QColor(Qt::green);

const auto rect = event->rect();

p.fillRect(rect, color);

toggled = !toggled;

}


void Widget::timerEvent(QTimerEvent *event)

{

Q_UNUSED(event);

update();

}


int main(int argc, char *argv[])

{

QApplication app(argc, argv);

Widget w;

w.setMinimumSize(1280, 800);

w.show();

return app.exec();

}

[/code]

And then I see that the Desktop PC has the ~0% CPU load, but the iMX6 has
~50% CPU load. WTF?

BR,
Denis



ср, 29 авг. 2018 г. в 12:39, Denis Shienkov :

> Hi all.
>
> I have an Apalis iMX6 board with the Yocto's image with the working
> 'eglfs' and 'linuxfb'  backends (without of X11 support).
>
> I need to create a 'pure' QtWidgets application, where I need to use a
> real-time plotting with the Qwt library (using the Qt Quick is not an
> option, as there the QtCharts is not ready for usage) .
>
> But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as
> with the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable,
> because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading.
>
> Is any workarounds for this? Maybe I need to re-build the Yocto's image to
> enable the X11 'xcb' support?
>
> BR,
> Denis
>
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

Hi all.

I have an Apalis iMX6 board with the Yocto's image with the working 'eglfs'
and 'linuxfb'  backends (without of X11 support).

I need to create a 'pure' QtWidgets application, where I need to use a
real-time plotting with the Qwt library (using the Qt Quick is not an
option, as there the QtCharts is not ready for usage) .

But, I'm sadly surprised that a 2D painting takes ~100% CPU loading as with
the 'eglfs' and as with 'linuxfb' backends. It is not an acceptable,
because, e.g. on Desktop Linux/Windows it takes ~4-5% CPU loading.

Is any workarounds for this? Maybe I need to re-build the Yocto's image to
enable the X11 'xcb' support?

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

[Development] Create native FileDialog for Android

2018-08-10 Thread Denis Shienkov


Hi guys,

Is it possible to add an own code to use the Android's native file 
picker dialog?


For example, I want (I think) to use a following framework (it 
introduced to Android since v4.4):

https://developer.android.com/guide/topics/providers/document-provider

But a problem is that an Android's platform plugin from the:

qtbase\src\plugins\platforms\android\qandroidplatformtheme.cpp

ignores a file dialogs at all:

{code}
QPlatformDialogHelper 
*QAndroidPlatformTheme::createPlatformDialogHelper(QPlatformTheme::DialogType 
type) const

{
    switch (type) {
    case MessageDialog:
    return new 
QtAndroidDialogHelpers::QAndroidPlatformMessageDialogHelper;

    default:
    return 0;
    }
}
{code}

So, is it possible to override this behavior somehow? Or e.g. to create 
an own

QAndroidPlatformTheme ? It it possible in Qt at all?

PS: What is reason that the Android's theme does not support the Color 
&& File Dialogs?


BR,
Denis


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

Re: [Development] Qt 6 buildsystem support requirements

2018-07-31 Thread Denis Shienkov


Hi guys,

Is there are any list of options from which it is possible to choose?

As for me, is it prefferable variant will be *QBS* (it is best from the 
best).


I'm do not like nor CMake, nor QMake, nor Autotools, nor something else.

BR,
Denis



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

[Development] Free VPN server required

2018-04-25 Thread Denis Shienkov

Hi guys,

Is it possible to pick-up a free VPN server on your side (on Qt-company
side) and give for some maintainers the login/password (e.g. for me)?

Because reason is that (ours russian goverment) blockes the some other
resources. The Qt resources fall into this by accident, and then it is not
possible to contribute to Qt at all (the git && qt doc and other Qt's
resources are blocked). (((

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

Re: [Development] Stepping down as maintainer

2018-03-20 Thread Denis Shienkov

Hi.

Maybe, you can to consider some "yum-yum" for attraction of community 
maintainers?

For example, to allow them to use the commercial license in own 
purposes, or, something else. ;)

20.03.2018 11:09, Tuukka Turunen пишет:

Hi,

It would be very good to get more contributors and maintainers also from the 
community and companies who offer Qt services. Lately we have had some 
community maintainers step down and replaced by people from The Qt Company. 
This is fine to some degree, but we should also have new persons from the 
community and ecosystem step up.

Overall the amount of community contributions to Qt is still around the same 
30% as it has been. So we have not been getting any better or worse in that 
regard.

Yours,

Tuukka

On 19/03/2018, 19.33, "Development on behalf of Sune Vuorela" 
<development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of nos...@vuorela.dk> 
wrote:

 On 2018-03-19, Denis Shienkov <denis.shien...@gmail.com> wrote:
 > As I can see recently, is is not a good tendence in Qt... Many peoples
 > leaves from Qt.. What happens? Or I'm mistake? :)

 Let's do some math.

 There is around 160 maintainer positions in Qt (a quick count of  on

 the maintainers wiki page)

 Many maintainers are a maintainer as part of their job duties. Not many

 people these days have the same job for more than 5-6 years. If it takes
 1-2 years to get to a state to become maintainer, that leaves around 4
 years as a maintainer.

 If we assume that the maintainer is around for 4 years and there is

 effective 10 months per year, then we should have 4 replacement
 maintainers each month.

 I'm not sure I see something worrying in numbers alone.

 /Sune

 ___

 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

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

Re: [Development] Stepping down as maintainer

2018-03-19 Thread Denis Shienkov


Hi all,

As I can see recently, is is not a good tendence in Qt... Many peoples 
leaves from Qt.. What happens? Or I'm mistake? :)



19.03.2018 15:39, Gunnar Sletta пишет:

Hi,

After quite some time of not being active in Qt, I am now formally stepping 
down as maintainer. It has been a great ride, but I simply don't have time to 
follow up Gui and Scene Graph and it makes sense that the people who are active 
in these areas also become the go-to guys.

I've already spoken with Eskil and Lars, and propose the following list of 
people to formally take over my areas:

Tor Arne Vestby - QPA and window system integration
Laszlo Agocs - OpenGL/Vulkan
Eirik Aavitsland - Image Formats and QPainter
Andy Nichols - Scene Graph

(Other specific maintainers in QtGui stay unchanged)

Thanks,
Gunnar
___
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] Goodbye

2018-02-10 Thread Denis Shienkov


Wow, Jake, what will be with QBS?

BR,

Denis


09.02.2018 23:14, Jake Petroules пишет:

Steve Jobs once said:


“I have looked in the mirror every morning and asked myself: "If today were the last day of my 
life, would I want to do what I am about to do today?" And whenever the answer has been 
"No" for too many days in a row, I know I need to change something.”


After 8 years of Qt, it's time to say goodbye. Both from my employment in The 
Qt Company and my roles in the Qt Project. I'd like to thank those of you in 
the company and in the Qt Project who have supported me over the years in 
various ways. It's been a great adventure. Friday, February 23rd will be my 
last day.

I hereby relinquish my role as Maintainer of Apple build system support across 
all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my 
replacement), and my role as Maintainer of the Apple watchOS platform 
(nominating Tor Arne Vestbø as my replacement).

Please feel free to contact me at jake.petrou...@petroules.com if you have any 
questions, comments, or otherwise.

I wish you all the best.

Sincerely,
Jake Petroules
___
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] New Qt snapshots available

2018-01-26 Thread Denis Shienkov

Ok, thanks.

2018-01-26 11:02 GMT+03:00 Eike Ziller <eike.zil...@qt.io>:

>
>
> > On 25. Jan 2018, at 16:50, Denis Shienkov <denis.shien...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > What about adding the snapshots of QtC 4.5.1 and 4.6.x to the
> MaintenanceTool?
> >
> > Because it is ugly to install some future QtC's snapshots separatelly.
> > What if I want to upgrade QtC to next snapshot version?
> >
> > E.g. I do not want to have a more than one installed QtC instance,
> > or, e.g. I want to uncheck/uninstall a default QtC.
> >
> > Is it possible to make this more flexible for MaintenanceTool?
>
> It got more flexible recently (we released the 4.5 beta & rc through the
> online installer), and we are working on making it more flexible (like
> making Qt Creator optional).
> We currently do not have concrete plans for providing Qt Creator
> _snapshots_, though I’d love to provide something. I’m not sure if
> providing daily automated snapshots is feasible though, since we do not
> want to break online installations (this is not about providing a broken Qt
> Creator, it is more about breaking the user’s installation in the whole
> when we adapt something there).
>
> Br, Eike
>
> > BR,
> > Denis
> >
> > 25.01.2018 16:08, Jani Heikkinen пишет:
> >> Hi,
> >>
> >> We have published online snapshots for Qt 5.10.1 and Qt 5.11 Alpha. You
> can find those from 'Preview' node in online installer
> >>
> >> br,
> >> Jani
> >>
> >>
> >> ___
> >> 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
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> 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
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to use ANDROID_EXTRA_PLUGINS property in qmake projects

2018-01-19 Thread Denis Shienkov

I have found a solution and have updated the bug, where I added
a source project with correct solution:

https://bugreports.qt.io/browse/QTBUG-65864

Maybe it will helps to anybody else.

PS: Needs to extend a doc about using of the ANDROID_EXTRA_PLUGINS anyway...

PS2: Also, the qmake copies this library twice to the android-build
directory...

19.01.2018 13:15, Denis Shienkov пишет:

Hi all.

I have created a custom qt-positioning plugin, which just
every second provides a new fake position/coordinate.

This plugin work perfectly e.g. on Windows, but it does not
work on Android, as it does not loaded, because it wrongly
deployed to APK file.

I have read about the ANDROID_EXTRA_PLUGINS property:
http://doc.qt.io/qt-5/deployment-android.html. But there
are no any examples how to use this property (nor in examples,
not in google). It is unclear at all how to use this property.

I have tried different combinations, but it does not work at
all. I have tried to specify a different output paths to my
plugin (as a full paths, as a directory only and so on).

I have found only one similar issue on stackoverflow:
https://stackoverflow.com/questions/47061829/how-to-deploy-qt-imageformats-plugins-on-android

but from there it is unclear what I need to add to the
ANDROID_EXTRA_PLUGINS property (or a directory path or
a full path... a path to where?).

I have created a bug https://bugreports.qt.io/browse/QTBUG-65864
with an test project.

Whether someone has experience of creation of
a custom Qt plugins for Android?

BR,
Denis

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

[Development] How to use ANDROID_EXTRA_PLUGINS property in qmake projects

2018-01-19 Thread Denis Shienkov


Hi all.

I have created a custom qt-positioning plugin, which just
every second provides a new fake position/coordinate.

This plugin work perfectly e.g. on Windows, but it does not
work on Android, as it does not loaded, because it wrongly
deployed to APK file.

I have read about the ANDROID_EXTRA_PLUGINS property:
http://doc.qt.io/qt-5/deployment-android.html. But there
are no any examples how to use this property (nor in examples,
not in google). It is unclear at all how to use this property.

I have tried different combinations, but it does not work at
all. I have tried to specify a different output paths to my
plugin (as a full paths, as a directory only and so on).

I have found only one similar issue on stackoverflow:
https://stackoverflow.com/questions/47061829/how-to-deploy-qt-imageformats-plugins-on-android

but from there it is unclear what I need to add to the
ANDROID_EXTRA_PLUGINS property (or a directory path or
a full path... a path to where?).

I have created a bug https://bugreports.qt.io/browse/QTBUG-65864
with an test project.

Whether someone has experience of creation of
a custom Qt plugins for Android?

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

Re: [Development] Mismatch of display resolutions and window sizes in Android applications

2018-01-15 Thread Denis Shienkov

Hi,

> This is by design for Qt::AA_EnableHighDpiScaling: you get the logical
window size.

Yes, seems it is. I did not know that. Now, I do not use
Qt::AA_EnableHighDpiScaling
at all, because I need to operate with a real resolutions.

Many thanks, anyway. :)

2018-01-15 17:12 GMT+03:00 Morten Sørvig <morten.sor...@qt.io>:

> This is by design for Qt::AA_EnableHighDpiScaling: you get the logical
> window size. The
> physical size can be computed by multiplying with QQuickWindow::
> effectiveDevicePixelRatio().
>
> For QtLocation it looks like you have to enable high-dpi tiles by setting
> “osm.mapping.highdpi_tiles"
> (or a similar option, depending on which tile provider you are using).
>
> Morten
>
>
> > On 13 Jan 2018, at 19:27, Denis Shienkov <denis.shien...@gmail.com>
> wrote:
> >
> > The problem was in Qt::AA_EnableHighDpiScaling option.
> >
> > 13.01.2018 19:34, Denis Shienkov пишет:
> >> Hi all.
> >>
> >> Rigth now I faced with the strange issue is that the QML
> >> window size (screen) does not correspond to the display
> >> resolution.
> >>
> >> For example, I have the "ASUS ZenFone 4 Max ZC554KL"
> >> smartphone which has display resolution as 1280x720 pixels.
> >>
> >> But if I run there the QML application and try to print out
> >> the ApplicationWindow size, then it is 360x568 or 640x288
> >> pixels, depends on orientation. O_o
> >>
> >> I have checked the same and on other smartphones, and see
> >> that there the situation is similar. E.g. for the
> >> "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got
> >> 320x460 or 533x247 pixels of my ApplicationWindow.
> >>
> >> For example if try to use the QtLocation module, then any
> >> maps looks ugly.
> >>
> >> It is very bad surprise for me... Because, seems, now I can
> >> not write any applications with high resolusion (or, at least
> >> to operate with a real resolutions from my QML code).
> >>
> >> Is there are any tricks to fix it?
> >>
> >> PS: Some Android's firmwares (e.g. Cyanogen)  allows to change
> >> the DPI, and with the minimum DPI the ApplicationWindow size
> >> increases a bit.. But it is not an option anyway.
> >>
> >> BR,
> >> Denis
> >
> > ___
> > 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Mismatch of display resolutions and window sizes in Android applications

2018-01-13 Thread Denis Shienkov


The problem was in Qt::AA_EnableHighDpiScaling option.


13.01.2018 19:34, Denis Shienkov пишет:


Hi all.

Rigth now I faced with the strange issue is that the QML
window size (screen) does not correspond to the display
resolution.

For example, I have the "ASUS ZenFone 4 Max ZC554KL"
smartphone which has display resolution as 1280x720 pixels.

But if I run there the QML application and try to print out
the ApplicationWindow size, then it is 360x568 or 640x288
pixels, depends on orientation. O_o

I have checked the same and on other smartphones, and see
that there the situation is similar. E.g. for the
"Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got
320x460 or 533x247 pixels of my ApplicationWindow.

For example if try to use the QtLocation module, then any
maps looks ugly.

It is very bad surprise for me... Because, seems, now I can
not write any applications with high resolusion (or, at least
to operate with a real resolutions from my QML code).

Is there are any tricks to fix it?

PS: Some Android's firmwares (e.g. Cyanogen)  allows to change
the DPI, and with the minimum DPI the ApplicationWindow size
increases a bit.. But it is not an option anyway.

BR,
Denis



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

[Development] Mismatch of display resolutions and window sizes in Android applications

2018-01-13 Thread Denis Shienkov


Hi all.

Rigth now I faced with the strange issue is that the QML
window size (screen) does not correspond to the display
resolution.

For example, I have the "ASUS ZenFone 4 Max ZC554KL"
smartphone which has display resolution as 1280x720 pixels.

But if I run there the QML application and try to print out
the ApplicationWindow size, then it is 360x568 or 640x288
pixels, depends on orientation. O_o

I have checked the same and on other smartphones, and see
that there the situation is similar. E.g. for the
"Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got
320x460 or 533x247 pixels of my ApplicationWindow.

For example if try to use the QtLocation module, then any
maps looks ugly.

It is very bad surprise for me... Because, seems, now I can
not write any applications with high resolusion (or, at least
to operate with a real resolutions from my QML code).

Is there are any tricks to fix it?

PS: Some Android's firmwares (e.g. Cyanogen)  allows to change
the DPI, and with the minimum DPI the ApplicationWindow size
increases a bit.. But it is not an option anyway.

BR,
Denis

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

Re: [Development] qmake's custom install failed on Android


This solution:

https://stackoverflow.com/questions/25929467/qt-android-location-of-java-files-common-to-different-projects

does not work as well.


12.01.2018 23:00, Denis Shienkov пишет:


> you can use COPIES

It does not work as well if the ANDROID_PACKAGE_SOURCE_DIR is defined.


12.01.2018 22:31, Denis Shienkov пишет:


In a real project I need to copy an external *.java
files to the android-build/src/org directory.

Now, if I use the INSTALLS as following:

    gst_java.files = 
$$libs_sourcedir/$$GST_SUPPORT_TARGET/android-sources/src/org/freedesktop/$$GST_MODULE_NAME/GStreamer.java

    gst_java.path = /src/org/freedesktop/$$GST_MODULE_NAME
    INSTALLS += gst_java

then the resulting files are not copied to the
android-build/src/org/freedesktop/ if the
ANDROID_PACKAGE_SOURCE_DIR variable is defined.

I doo not know how to use and ANDROID_PACKAGE_SOURCE_DIR
and INSTALLS together...


12.01.2018 21:49, Oswald Buddenhagen пишет:

On Fri, Jan 12, 2018 at 08:58:16PM +0300, Denis Shienkov wrote:

I need to use the INSTALLS feature on Android project
to copy of some files to the desired location.

foo_bar.path = $$OUT_PWD/foobar
INSTALLS += foo_bar


that's positively wrong.
for a non-install shadow build, you can use COPIES (if you do that
outside qt, you're doing it at your own risk; it doesn't work with the
IDE generators).
an actual INSTALLS would never point into OUT_PWD, i.e., the build dir.
___
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] qmake's custom install failed on Android


> you can use COPIES

It does not work as well if the ANDROID_PACKAGE_SOURCE_DIR is defined.


12.01.2018 22:31, Denis Shienkov пишет:


In a real project I need to copy an external *.java
files to the android-build/src/org directory.

Now, if I use the INSTALLS as following:

    gst_java.files = 
$$libs_sourcedir/$$GST_SUPPORT_TARGET/android-sources/src/org/freedesktop/$$GST_MODULE_NAME/GStreamer.java

    gst_java.path = /src/org/freedesktop/$$GST_MODULE_NAME
    INSTALLS += gst_java

then the resulting files are not copied to the
android-build/src/org/freedesktop/ if the
ANDROID_PACKAGE_SOURCE_DIR variable is defined.

I doo not know how to use and ANDROID_PACKAGE_SOURCE_DIR
and INSTALLS together...


12.01.2018 21:49, Oswald Buddenhagen пишет:

On Fri, Jan 12, 2018 at 08:58:16PM +0300, Denis Shienkov wrote:

I need to use the INSTALLS feature on Android project
to copy of some files to the desired location.

foo_bar.path = $$OUT_PWD/foobar
INSTALLS += foo_bar


that's positively wrong.
for a non-install shadow build, you can use COPIES (if you do that
outside qt, you're doing it at your own risk; it doesn't work with the
IDE generators).
an actual INSTALLS would never point into OUT_PWD, i.e., the build dir.
___
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] qmake's custom install failed on Android


In a real project I need to copy an external *.java
files to the android-build/src/org directory.

Now, if I use the INSTALLS as following:

    gst_java.files = 
$$libs_sourcedir/$$GST_SUPPORT_TARGET/android-sources/src/org/freedesktop/$$GST_MODULE_NAME/GStreamer.java

    gst_java.path = /src/org/freedesktop/$$GST_MODULE_NAME
    INSTALLS += gst_java

then the resulting files are not copied to the
android-build/src/org/freedesktop/ if the
ANDROID_PACKAGE_SOURCE_DIR variable is defined.

I doo not know how to use and ANDROID_PACKAGE_SOURCE_DIR
and INSTALLS together...


12.01.2018 21:49, Oswald Buddenhagen пишет:

On Fri, Jan 12, 2018 at 08:58:16PM +0300, Denis Shienkov wrote:

I need to use the INSTALLS feature on Android project
to copy of some files to the desired location.

foo_bar.path = $$OUT_PWD/foobar
INSTALLS += foo_bar


that's positively wrong.
for a non-install shadow build, you can use COPIES (if you do that
outside qt, you're doing it at your own risk; it doesn't work with the
IDE generators).
an actual INSTALLS would never point into OUT_PWD, i.e., the build dir.
___
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

[Development] qmake's custom install failed on Android


Hi all,

I need to use the INSTALLS feature on Android project
to copy of some files to the desired location.

For, example, this simple example fails at building for the install target:

QT += quick
CONFIG += c++11
SOURCES += main.cpp
RESOURCES += qml.qrc

foo_bar.files += $$PWD/main.cpp
foo_bar.path = $$OUT_PWD/foobar

INSTALLS += foo_bar

... with an error, like: "Unable to create a file or directory".

If I try to change the Android's kit to e.g. Windows's kit, then
my 'main.cpp' file copies fine.

Is it a bug? Or I do something wrong?

PS: I use Windows 10 host && Qt 5.9.3 for Android ARMv7 Kit.

BR,
Denis

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

Re: [Development] QMAKE_EXTRA_COMPILERS does not work on Android in case the ANDROID_PACKAGE_SOURCE_DIR is empty


I'm very sorry, it is my fail. :((


12.01.2018 18:22, Denis Shienkov пишет:

Hi all.

I need to use a custom target to build of external shared library *.so,
with a custom build system (e.g. using the NDK directly) and to link 
with.


I faced with a strange behavior of QMAKE_EXTRA_COMPILERS on Android,
which is that the qmake does not creates a "compiler_foo_" target in
the output Makefile for my target if the ANDROID_PACKAGE_SOURCE_DIR is
not set. So, the desired build step does not called at all. O_O

E.g. I have following rules in the *.pro file:

 ...
 android {

 foo.name = Foo compiler
 foo.input = FOO
 foo.output = FOO_PATH

 # Build command.
 foo.commands = (custom build command)

 # Custom additional cleanup targets.
 foo.clean += (custom cleanup command)

 foo.CONFIG += target_predeps

 QMAKE_EXTRA_COMPILERS += foo

 # Add the generated library into the resulting apk.
 ANDROID_EXTRA_LIBS = $$GST_MODULE_PATH

 }
 ...

In this case I see in Makefile following:

 ...
 compiler_foo_make_all:
 compiler_foo_clean:
    (set of custom cleanup commands)
 ...

But, if I try to add any not empty ANDROID_PACKAGE_SOURCE_DIR
to the *.pro file:

 ...
 android {
 ANDROID_PACKAGE_SOURCE_DIR = 

 
 
 }
 ...

then the resulting Makefile contains all what need:

 ...
 OBJECTS   =  ...
 ...
 compiler_gst_make_all: 
 compiler_gst_clean:
     (set of custom cleanup commands)
 ...
 : foo
     (set of custom build commands)
 ...

How can I fix it? Because in a real project I will to use
the QMAKE_EXTRA_COMPILERS in a 'static library' template project,
which does not contains any Android's java sources and so on.

BR,
Denis


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

[Development] QMAKE_EXTRA_COMPILERS does not work on Android in case the ANDROID_PACKAGE_SOURCE_DIR is empty


Hi all.

I need to use a custom target to build of external shared library *.so,
with a custom build system (e.g. using the NDK directly) and to link with.

I faced with a strange behavior of QMAKE_EXTRA_COMPILERS on Android,
which is that the qmake does not creates a "compiler_foo_" target in
the output Makefile for my target if the ANDROID_PACKAGE_SOURCE_DIR is
not set. So, the desired build step does not called at all. O_O

E.g. I have following rules in the *.pro file:

 ...
 android {

 foo.name = Foo compiler
 foo.input = FOO
 foo.output = FOO_PATH

 # Build command.
 foo.commands = (custom build command)

 # Custom additional cleanup targets.
 foo.clean += (custom cleanup command)

 foo.CONFIG += target_predeps

 QMAKE_EXTRA_COMPILERS += foo

 # Add the generated library into the resulting apk.
 ANDROID_EXTRA_LIBS = $$GST_MODULE_PATH

 }
 ...

In this case I see in Makefile following:

 ...
 compiler_foo_make_all:
 compiler_foo_clean:
    (set of custom cleanup commands)
 ...

But, if I try to add any not empty ANDROID_PACKAGE_SOURCE_DIR
to the *.pro file:

 ...
 android {
 ANDROID_PACKAGE_SOURCE_DIR = 

 
 
 }
 ...

then the resulting Makefile contains all what need:

 ...
 OBJECTS   =  ...
 ...
 compiler_gst_make_all: 
 compiler_gst_clean:
     (set of custom cleanup commands)
 ...
 : foo
     (set of custom build commands)
 ...

How can I fix it? Because in a real project I will to use
the QMAKE_EXTRA_COMPILERS in a 'static library' template project,
which does not contains any Android's java sources and so on.

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

Re: [Development] [Android] Use pkg-config to link with external libraries in qmake project


Ohhh.. exactly, many thanks... :)


20.12.2017 13:53, Oswald Buddenhagen пишет:

On Wed, Dec 20, 2017 at 01:03:30PM +0300, Denis Shienkov wrote:

c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0


i really wouldn't expect this to work. ;)

the problems seems to be that pkg-config outputs the paths in a format
that cannot be possibly understood by the compiler. that's a bug in the
.pc files or pkg-config itself, i'd guess.


But, if I try to output message from my *.pro file:

message("bla $$INCLUDEPATH")

then I see an empty content of INCLUDEPATH...

What happens?


execution order happens. ;)

___
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] [Android] Use pkg-config to link with external libraries in qmake project


Next, I have modified the link_pkgconfig.prf to
add there a message output like:

...
INCLUDEPATH *= $$PKGCONFIG_INCLUDEPATH
DEFINES *= $$PKGCONFIG_DEFINES

message("bla $$INCLUDEPATH")
...

and I see required output:

Project MESSAGE: bla 
c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0

c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/glib-2.0
c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/lib/glib-2.0/include

all fine...

But, if I try to output message from my *.pro file:

message("bla $$INCLUDEPATH")

then I see an empty content of INCLUDEPATH...

What happens?

20.12.2017 12:55, Denis Shienkov пишет:


I even have tried following from the Windows cmd durectly:

set PATH=c:\pkgconfig\bin;%PATH%
set PKG_CONFIG_LIBDIR=c:/Android/gstreamer/armv7/lib/pkgconfig
set PKG_CONFIG_SYSROOT_DIR=c:/Android/gstreamer/armv7

pkg-config.exe --cflags gstreamer-1.0

Output is:

-pthread 
-Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0 
-Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/glib-2.0 
-Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/lib/glib-2.0/include


So, all include dirs are found, but the qmake's link_pkgconfig.prf 
skiped this.. :(



20.12.2017 12:35, Denis Shienkov пишет:


Hi Oswald,

Hmm.. many thanks for your hint, I have modified the
pkg-conf env variables to:

1. PKG_CONFIG_LIBDIR = c:\Android\gstreamer\armv7\lib\pkgconfig
 - a path to all *.pc files.

2. PKG_CONFIG_SYSROOT_DIR = c:\Android\gstreamer\armv7
 - a path to a 'fake' sysroot, which contains an 'include',
   'lib', 'etc' and other directories.

Now, the qmake eats it without warnings...
But, now, it does not detect the gst's include files,
like:

#include 

though they are present in:

c:\Android\gstreamer\armv7\include\gstreamer-1.0\gst\

:(


20.12.2017 12:04, Oswald Buddenhagen пишет:

On Wed, Dec 20, 2017 at 11:39:20AM +0300, Denis Shienkov wrote:

This says about the 'sysroot', but, I have no any sysroot for Android kit,


that's just implausible. you must have something that resembles a
sysroot, even if it's not declared as such. if you don't find anything
else, just use the directory that contains the lib and include
directories.

the code is in qt_functions.prf:pkgConfigExecutable(). here you see that
you will need to set %PKG_CONFIG_LIBDIR% and %PKG_CONFIG_SYSROOT_DIR% if
you qt build is not configured for pkg-config use to start with.
___
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] [Android] Use pkg-config to link with external libraries in qmake project


I even have tried following from the Windows cmd durectly:

set PATH=c:\pkgconfig\bin;%PATH%
set PKG_CONFIG_LIBDIR=c:/Android/gstreamer/armv7/lib/pkgconfig
set PKG_CONFIG_SYSROOT_DIR=c:/Android/gstreamer/armv7

pkg-config.exe --cflags gstreamer-1.0

Output is:

-pthread 
-Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0 
-Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/glib-2.0 
-Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/lib/glib-2.0/include


So, all include dirs are found, but the qmake's link_pkgconfig.prf 
skiped this.. :(



20.12.2017 12:35, Denis Shienkov пишет:


Hi Oswald,

Hmm.. many thanks for your hint, I have modified the
pkg-conf env variables to:

1. PKG_CONFIG_LIBDIR = c:\Android\gstreamer\armv7\lib\pkgconfig
 - a path to all *.pc files.

2. PKG_CONFIG_SYSROOT_DIR = c:\Android\gstreamer\armv7
 - a path to a 'fake' sysroot, which contains an 'include',
   'lib', 'etc' and other directories.

Now, the qmake eats it without warnings...
But, now, it does not detect the gst's include files,
like:

#include 

though they are present in:

c:\Android\gstreamer\armv7\include\gstreamer-1.0\gst\

:(


20.12.2017 12:04, Oswald Buddenhagen пишет:

On Wed, Dec 20, 2017 at 11:39:20AM +0300, Denis Shienkov wrote:

This says about the 'sysroot', but, I have no any sysroot for Android kit,


that's just implausible. you must have something that resembles a
sysroot, even if it's not declared as such. if you don't find anything
else, just use the directory that contains the lib and include
directories.

the code is in qt_functions.prf:pkgConfigExecutable(). here you see that
you will need to set %PKG_CONFIG_LIBDIR% and %PKG_CONFIG_SYSROOT_DIR% if
you qt build is not configured for pkg-config use to start with.
___
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] [Android] Use pkg-config to link with external libraries in qmake project


Hi Oswald,

Hmm.. many thanks for your hint, I have modified the
pkg-conf env variables to:

1. PKG_CONFIG_LIBDIR = c:\Android\gstreamer\armv7\lib\pkgconfig
 - a path to all *.pc files.

2. PKG_CONFIG_SYSROOT_DIR = c:\Android\gstreamer\armv7
 - a path to a 'fake' sysroot, which contains an 'include',
   'lib', 'etc' and other directories.

Now, the qmake eats it without warnings...
But, now, it does not detect the gst's include files,
like:

#include 

though they are present in:

c:\Android\gstreamer\armv7\include\gstreamer-1.0\gst\

:(


20.12.2017 12:04, Oswald Buddenhagen пишет:

On Wed, Dec 20, 2017 at 11:39:20AM +0300, Denis Shienkov wrote:

This says about the 'sysroot', but, I have no any sysroot for Android kit,


that's just implausible. you must have something that resembles a
sysroot, even if it's not declared as such. if you don't find anything
else, just use the directory that contains the lib and include
directories.

the code is in qt_functions.prf:pkgConfigExecutable(). here you see that
you will need to set %PKG_CONFIG_LIBDIR% and %PKG_CONFIG_SYSROOT_DIR% if
you qt build is not configured for pkg-config use to start with.
___
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

[Development] [Android] Use pkg-config to link with external libraries in qmake project


Hi all,

is it possible to use the pkg-config to build the
Android's applications?

e.g. I want to use the GStreamer for the Android
application, using the pkg-config.

I already have installed & configured the the Android
Kit, have downloaded the Gstreamer SDK for ARMv7 platform.

I use the Windows host, so, I have downloaded the
pkg-config 'lite' binary for windows and have added
the following env build variables into QtC:

1. PKG_CONFIG_PATH = c:\Android\gstreamer\armv7\lib\pkgconfig\
 - a path to my Android's GStreamer pkg-configurations installed.

2. PATH = c:\pkgconfig\bin;
 - a path to downloaded pkg-config executable.

When I try to open my qmake-based project, e.g. with
following content:

...
CONFIG += link_pkgconfig

PKGCONFIG += \
    gstreamer-1.0 \
    gstreamer-base-1.0 \
    gstreamer-video-1.0 \
    gstreamer-app-1.0
...

and to run the qmake, then I got the following errors:

"
Project WARNING: Cross compiling without sysroot. Disabling pkg-config.
Project WARNING: Cross compiling without sysroot. Disabling pkg-config.
Project ERROR: gstreamer-1.0 development package not found
"

This says about the 'sysroot', but, I have no any sysroot for Android kit,
besides the QtC 'sysroot' Kit's field is empty and not editable (it is
read-only).

So, my question is: how to use pkg-config && qmake && Android?

PS: I have use similar cinfiguration to build an applications
on Windows host (with pkg-config), and all be fines...

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

Re: [Development] How fast grab a QML item's content to image when it updates?


Now I tried to use the following code:

classBindableFbofinal:publicQSGBindable

{

public:

explicitBindableFbo(QOpenGLFramebufferObject*fbo)

:m_fbo(fbo)

{}

voidbind()constfinal{m_fbo->bind();}

private:

QOpenGLFramebufferObject*m_fbo=nullptr;

};

Grabber::Grabber(QQuickItem*parent)

:QQuickItem(parent)

{

setFlag(QQuickItem::ItemHasContents);

connect(this,::windowChanged,

this,::scheduleWindowChange);

}

voidGrabber::setSourceItem(QQuickItem*sourceItem)

{

if(sourceItem==m_sourceItem)

return;

m_sourceItem=sourceItem;

emitsourceItemChanged(m_sourceItem);

update();

}

QQuickItem*Grabber::sourceItem()const

{

returnm_sourceItem;

}

QSGNode*Grabber::updatePaintNode(QSGNode*oldNode,

UpdatePaintNodeData*updatePaintNodeData)

{

Q_UNUSED(updatePaintNodeData);

if(!m_sourceItem)

returnoldNode;

m_running=true;

constautoitemNode=QQuickItemPrivate::get(m_sourceItem)->itemNode();

constautoparentNode=itemNode->parent();

constautosiblingNode=itemNode->previousSibling();

if(parentNode)

parentNode->removeChildNode(itemNode);

constQScopedPointerrenderer(

QQuickItemPrivate::get(this)->

sceneGraphRenderContext()->createRenderer());

QSGRootNoderootNode;

rootNode.appendChildNode(itemNode);

renderer->setRootNode();

constQSizesize(m_sourceItem->width(),m_sourceItem->height());

renderer->setDeviceRect(size);

renderer->setViewportRect(size);

renderer->setProjectionMatrixToRect(QRectF(QPointF(),size));

renderer->setClearColor(Qt::transparent);

QOpenGLFramebufferObjectfbo(size);

renderer->renderScene(BindableFbo());

fbo.release();

rootNode.removeChildNode(itemNode);

if(parentNode){

if(siblingNode){

parentNode->insertChildNodeAfter(itemNode,siblingNode);

}else{

parentNode->prependChildNode(itemNode);

}

}

QElapsedTimeret;

et.start();

constQImageimage=fbo.toImage();//TOOLONG!

staticintcount=0;

qDebug()<<"Elapsed:"<<et.elapsed()<<count;

++count;

//image.save(tr("test%1.png").arg(count++));

returnoldNode;

}

voidGrabber::scheduleWindowChange(QQuickWindow*window)

{

disconnect(m_updateConnection);

if(window){

m_updateConnection=connect(window,::afterRendering,

this,::scheduleUpdate);

}

}

voidGrabber::scheduleUpdate()

{

if(!m_running)

update();

else

m_running=false;

}

Where for the 800x600 window, the elapsed time of  fbo.toImage() is 
around of ~8 msec
(with GPU rendering on Windows, as I assume). If try to expand a window 
to full screen

(1920x1080 in my case), then this time increases up to ~30 msec.

I'm not sure, is this code correct? Is this values correct? Could 
someone elaborate it?



12.12.2017 18:20, Shawn Rutledge пишет:

On 12 Dec 2017, at 14:53, Denis Shienkov <denis.shien...@gmail.com> wrote:


Did you try QQuickItem::grabToImage?

Of course, it is veeery slowly.

If the frame was rendered on the GPU, you have to download it from there, and 
that is slower than if you had rendered into CPU memory, as widgets do by 
default.  Thus the note in the docs:

   Note: This function will render the item to an offscreen surface and copy
   that surface from the GPU's memory into the CPU's memory, which can be
   quite costly. For "live" preview, use layers or ShaderEffectSource.

So, maybe try to get the GPU to do whatever comes next after you think you need 
to grab the frame?  grabToImage is more for archival, not for real-time effects 
(although I did use it recently to record an animated GIF; I could only get 
30FPS despite using a fairly powerful GPU, but that was good enough).

___
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] How fast grab a QML item's content to image when it updates?


> Did you try QQuickItem::grabToImage?

Of course, it is veeery slowly.


12.12.2017 16:40, Konstantin Tokarev пишет:


12.12.2017, 16:13, "Denis Shienkov" <denis.shien...@gmail.com>:

Hi all...

Is it possible to grab a QQuickItem content (e.g. with all sub-items)
when an item changes?

Did you try QQuickItem::grabToImage?


E.g. with widgets I use the following code:

bool MyWidget::event(QEvent *event)
{
  if (event->type() == QEvent::UpdateRequest)
  myGrab();
  return QWidget::event(event);
}

void MyWidget::myGrab()
{
  ...
  QBackingStore *store = backingStore();
  Q_ASSERT(store);

  QPaintDevice *pdev = store->paintDevice();
  const auto image = dynamic_cast(pdev);
  ...
}

it is very fast (as I know)...

But with the QML I got a troubles: I can 'grab' the sourceItem, using
the FBO and private functions, but the fbo::toImage() is too slow (~24
msecs),
and I don't know how to intercept the signal when a watched item updates:

Grabber::Grabber(QQuickItem *parent)
  : QQuickItem(parent)
{
  setFlag(QQuickItem::ItemHasContents);
}

// Where sourceItem - is a watched item.
void Grabber::setSourceItem(QQuickItem *sourceItem)
{
  if (sourceItem == m_sourceItem)
  return;
  m_sourceItem = sourceItem;
  emit sourceItemChanged(m_sourceItem);
  update();
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
    UpdatePaintNodeData *updatePaintNodeData)
{
  Q_UNUSED(updatePaintNodeData);

  if (!m_sourceItem)
  return oldNode;

  QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

  const QScopedPointer renderer(
  QQuickItemPrivate::get(this)->
  sceneGraphRenderContext()->createRenderer());

  renderer->setRootNode();

  const QSize size(m_sourceItem->width(), m_sourceItem->height());
  renderer->setDeviceRect(size);
  renderer->setViewportRect(size);
  renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
  renderer->setClearColor(Qt::transparent);

  QOpenGLFramebufferObject fbo(size);
  renderer->renderScene(BindableFbo());
  fbo.release();

  QElapsedTimer et;
  et.start();
  const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
  qDebug() << "Elapsed:" << et.elapsed();

  return oldNode;
}

it is very fast (as I know).

But with the QML I got a troubles: I can 'grub' an item, using the FBO,

but the toImage() method is too slow (~24 msecs), and I don't know how

to intercept a signal when the watched item updates:

Grabber::Grabber(QQuickItem *parent)
  : QQuickItem(parent)
{
  setFlag(QQuickItem::ItemHasContents);
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
    UpdatePaintNodeData *updatePaintNodeData)
{
  Q_UNUSED(updatePaintNodeData);

  if (!m_sourceItem)
  return oldNode;

  QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

  const QScopedPointer renderer(
  QQuickItemPrivate::get(this)->
  sceneGraphRenderContext()->createRenderer());

  renderer->setRootNode();

  const QSize size(m_sourceItem->width(), m_sourceItem->height());
  renderer->setDeviceRect(size);
  renderer->setViewportRect(size);
  renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
  renderer->setClearColor(Qt::transparent);

  QOpenGLFramebufferObject fbo(size);
  renderer->renderScene(BindableFbo());
  fbo.release();

  QElapsedTimer et;
  et.start();
  const QImage image = fbo.toImage(); // TOO LONG!
  qDebug() << "Elapsed:" << et.elapsed();

  return oldNode;
}

___
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] How fast grab a QML item's content to image when it updates?



12.12.2017 16:13, Denis Shienkov пишет:

Hi all...

Is it possible to grab a QQuickItem content (e.g. with all sub-items)
when an item changes?

E.g. with widgets I use the following code:

bool MyWidget::event(QEvent *event)
{
    if (event->type() == QEvent::UpdateRequest)
    myGrab();
    return QWidget::event(event);
}

void MyWidget::myGrab()
{
    ...
    QBackingStore *store = backingStore();
    Q_ASSERT(store);

    QPaintDevice *pdev = store->paintDevice();
    const auto image = dynamic_cast(pdev);
    ...
}

it is very fast (as I know)...

But with the QML I got a troubles: I can 'grab' the sourceItem, using
the FBO and private functions, but the fbo::toImage() is too slow (~24 
msecs),

and I don't know how to intercept the signal when a watched item updates:

Grabber::Grabber(QQuickItem *parent)
    : QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents);
}

// Where sourceItem - is a watched item.
void Grabber::setSourceItem(QQuickItem *sourceItem)
{
    if (sourceItem == m_sourceItem)
    return;
    m_sourceItem = sourceItem;
    emit sourceItemChanged(m_sourceItem);
    update();
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
  UpdatePaintNodeData 
*updatePaintNodeData)

{
    Q_UNUSED(updatePaintNodeData);

    if (!m_sourceItem)
    return oldNode;

    QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

    const QScopedPointer renderer(
    QQuickItemPrivate::get(this)->
    sceneGraphRenderContext()->createRenderer());

    renderer->setRootNode();

    const QSize size(m_sourceItem->width(), m_sourceItem->height());
    renderer->setDeviceRect(size);
    renderer->setViewportRect(size);
    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
    renderer->setClearColor(Qt::transparent);

    QOpenGLFramebufferObject fbo(size);
    renderer->renderScene(BindableFbo());
    fbo.release();

    QElapsedTimer et;
    et.start();
    const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
    qDebug() << "Elapsed:" << et.elapsed();

    return oldNode;
}



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

[Development] How fast grab a QML item's content to image when it updates?


Hi all...

Is it possible to grab a QQuickItem content (e.g. with all sub-items)
when an item changes?

E.g. with widgets I use the following code:

bool MyWidget::event(QEvent *event)
{
    if (event->type() == QEvent::UpdateRequest)
    myGrab();
    return QWidget::event(event);
}

void MyWidget::myGrab()
{
    ...
    QBackingStore *store = backingStore();
    Q_ASSERT(store);

    QPaintDevice *pdev = store->paintDevice();
    const auto image = dynamic_cast(pdev);
    ...
}

it is very fast (as I know)...

But with the QML I got a troubles: I can 'grab' the sourceItem, using
the FBO and private functions, but the fbo::toImage() is too slow (~24 
msecs),

and I don't know how to intercept the signal when a watched item updates:

Grabber::Grabber(QQuickItem *parent)
    : QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents);
}

// Where sourceItem - is a watched item.
void Grabber::setSourceItem(QQuickItem *sourceItem)
{
    if (sourceItem == m_sourceItem)
    return;
    m_sourceItem = sourceItem;
    emit sourceItemChanged(m_sourceItem);
    update();
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
  UpdatePaintNodeData *updatePaintNodeData)
{
    Q_UNUSED(updatePaintNodeData);

    if (!m_sourceItem)
    return oldNode;

    QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

    const QScopedPointer renderer(
    QQuickItemPrivate::get(this)->
    sceneGraphRenderContext()->createRenderer());

    renderer->setRootNode();

    const QSize size(m_sourceItem->width(), m_sourceItem->height());
    renderer->setDeviceRect(size);
    renderer->setViewportRect(size);
    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
    renderer->setClearColor(Qt::transparent);

    QOpenGLFramebufferObject fbo(size);
    renderer->renderScene(BindableFbo());
    fbo.release();

    QElapsedTimer et;
    et.start();
    const QImage image = fbo.toImage(); // TOO LONG ~24 msec!
    qDebug() << "Elapsed:" << et.elapsed();

    return oldNode;
}

it is very fast (as I know).

But with the QML I got a troubles: I can 'grub' an item, using the FBO,

but the toImage() method is too slow (~24 msecs), and I don't know how

to intercept a signal when the watched item updates:

Grabber::Grabber(QQuickItem *parent)
    : QQuickItem(parent)
{
    setFlag(QQuickItem::ItemHasContents);
}

QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,
  UpdatePaintNodeData *updatePaintNodeData)
{
    Q_UNUSED(updatePaintNodeData);

    if (!m_sourceItem)
    return oldNode;

    QSGRootNode root;
root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());

    const QScopedPointer renderer(
    QQuickItemPrivate::get(this)->
    sceneGraphRenderContext()->createRenderer());

    renderer->setRootNode();

    const QSize size(m_sourceItem->width(), m_sourceItem->height());
    renderer->setDeviceRect(size);
    renderer->setViewportRect(size);
    renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));
    renderer->setClearColor(Qt::transparent);

    QOpenGLFramebufferObject fbo(size);
    renderer->renderScene(BindableFbo());
    fbo.release();

    QElapsedTimer et;
    et.start();
    const QImage image = fbo.toImage(); // TOO LONG!
    qDebug() << "Elapsed:" << et.elapsed();

    return oldNode;
}





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

Re: [Development] Future of QBS

2017-10-13 Thread Denis Shienkov

Hi all, my 5-cents:

QBS is better (best best) than CMake, IMHO, as CMake is too complicated.  :)

QBS needs still in BinaryFiles support (e.g. to allow todo patching, merge
for some output
files using custom algorithms), better QtC integration (e.g. with Android
&& iOS).

In other things QBS is very flexible, e.g. I have used it for creation of
some application's
Installers (for Windows), packing to archives, adding of additional rules
for creating of HEX,
MAP and so forth 'post build' things, and more more others (include
compiling a projects
for bare-metal architectures, e.g. AVR and so on). I don't know is it
possible to do it with
CMake with same as it simple in QBS (because CMake it is hell, IMHO).

Besides, AFAIK, Qt has the wip/qbs branch, where it builds with QBS instead
of qmake.

BR,
Denis

2017-10-13 18:30 GMT+03:00 Oswald Buddenhagen <oswald.buddenha...@qt.io>:

> On Fri, Oct 13, 2017 at 04:19:51PM +0100, Sergio Martins wrote:
> > On 2017-10-13 16:12, Thiago Macieira wrote:
> > > On Friday, 13 October 2017 07:56:47 PDT Sergio Martins wrote:
> > >> IMHO the qt-project is not in a position to reject Qt building with
> > >> qbs, simply because there's no other implementation, nobody is
> > >> going to port Qt to CMake (if you disagree start a new thread).
> > >
> > > There are volunteers to do that. They just need to know when they
> > > could start doing the work to make a proof of concept.
> >
> > Good to know Thiago. I'd say they should ask on the mailing lists
> > instead of waiting.
> >
> it already has been. we (the current maintianers of the qt build system,
> and really anyone with a grain of taste) are strongly biased against a
> cmake-based solution. in fact, we have rejected a cmake-based port of qt
> creator some years ago.
>
> ps: there is a qbs-specific mailing list (this is specifically not
> applicable to the above topic, but that's just a tangent to start with).
> ___
> 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] Unable to edit the Qt WIKI pages

2017-10-04 Thread Denis Shienkov

Hi,

> Did you to try to reload the page?

Oops, yes, seems the changes are applied (after re-loading of a page)..
thanks :)


2017-10-04 14:59 GMT+03:00 Nils Jeisecke via Development <
development@qt-project.org>:

> Hi,
>
> Am 03.10.2017 um 08:21 hat Denis Shienkov geschrieben:
> > now, for me, it it impossible to edit the Qt WIKI pages.. I always got an
> > errors like: "Your edit was aborted by an ArticleSave hook" and so on.
> What
> > happens?
> I've had the same problem. But somehow the change was applied contrary
> to what the error message said.
>
> Did you to try to reload the page?
>
> Quite irritating nevertheless.
>
> Nils
> ___
> 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

[Development] Unable to edit the Qt WIKI pages

2017-10-02 Thread Denis Shienkov


Hi all,

now, for me, it it impossible to edit the Qt WIKI pages.. I always got 
an errors like: "Your edit was aborted by an ArticleSave hook" and so 
on. What happens?


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

Re: [Development] MAINTAINERS: your action needed


https://codereview.qt-project.org/#/c/206395/

:)


22.09.2017 14:33, Jani Heikkinen пишет:

Use (which should be already in every changes file)


*   Qt 5.9.2 Changes
*


Jani

From: Denis Shienkov <denis.shien...@gmail.com>
Sent: Friday, September 22, 2017 2:31 PM
To: Jani Heikkinen; Edward Welbourne; development@qt-project.org
Subject: Re: [Development] MAINTAINERS: your action needed

  >  Let's use that one; it is now in every changes file

What's use? I do not understand.


22.09.2017 14:07, Jani Heikkinen пишет:

Hi all,

There has been different ways of doing this. I some modules there has been that 
library one, some other the one we used at this time. Let's use that one; it is 
now in every changes file

br,
Jani

From: Development <development-bounces+jani.heikkinen=qt...@qt-project.org> on behalf 
of Denis Shienkov <denis.shien...@gmail.com>
Sent: Friday, September 22, 2017 1:27 PM
To: Edward Welbourne; development@qt-project.org
Subject: Re: [Development] MAINTAINERS: your action needed

Previously, we (e.g. in qtserialport module) had this:


*   Library*


My question is: do we need to modify this "Qt 5.9.2 Changes" header? :)

BR,
Denis

22.09.2017 13:24, Edward Welbourne пишет:

Denis Shienkov (22 September 2017 11:39)

do we need to keep this:


*   Qt 5.9.2 Changes *


as is?

What were you thinking of changing about it ?

Eddy.

___
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] MAINTAINERS: your action needed


>  Let's use that one; it is now in every changes file

What's use? I do not understand.


22.09.2017 14:07, Jani Heikkinen пишет:

Hi all,

There has been different ways of doing this. I some modules there has been that 
library one, some other the one we used at this time. Let's use that one; it is 
now in every changes file

br,
Jani

From: Development <development-bounces+jani.heikkinen=qt...@qt-project.org> on behalf 
of Denis Shienkov <denis.shien...@gmail.com>
Sent: Friday, September 22, 2017 1:27 PM
To: Edward Welbourne; development@qt-project.org
Subject: Re: [Development] MAINTAINERS: your action needed

Previously, we (e.g. in qtserialport module) had this:


*   Library*


My question is: do we need to modify this "Qt 5.9.2 Changes" header? :)

BR,
Denis

22.09.2017 13:24, Edward Welbourne пишет:

Denis Shienkov (22 September 2017 11:39)

do we need to keep this:


*   Qt 5.9.2 Changes *


as is?

What were you thinking of changing about it ?

   Eddy.

___
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] MAINTAINERS: your action needed


Previously, we (e.g. in qtserialport module) had this:


*   Library*


My question is: do we need to modify this "Qt 5.9.2 Changes" header? :)

BR,
Denis

22.09.2017 13:24, Edward Welbourne пишет:

Denis Shienkov (22 September 2017 11:39)

do we need to keep this:


*   Qt 5.9.2 Changes *


as is?

What were you thinking of changing about it ?

Eddy.


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

Re: [Development] MAINTAINERS: your action needed