date:20210421

On Wednesday, 21 April 2021 10:39:01 PDT Giuseppe D'Angelo via Interest wrote:
> But no $X. I'm still not sure what $PROJ means.

The way the example was given, the string "$PROJ" will be written literally to 
the Makefile. Make will then interpret it as $(P)ROJ, which is likely not what 
you want.

$ gmake -f /dev/stdin <<<'all: ; @echo $PROJ'
ROJ
$ gmake -f /dev/stdin P=abc <<<'all: ; @echo $PROJ'
abcROJ


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

2021-04-21 Thread Elvis Stansvik

Den ons 21 apr. 2021 kl 20:43 skrev Elvis Stansvik :
>
> Den ons 21 apr. 2021 kl 19:49 skrev Jason H :
> >
> >
> >
> > > Sent: Wednesday, April 21, 2021 at 1:14 PM
> > > From: "Thiago Macieira" 
> > > To: interest@qt-project.org
> > > Subject: Re: [Interest] Help a unix guy on windows qmake
> > >
> > > On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > > > Now, when compiling, regardless of shadow build or not, refer to the 
> > > > libs by
> > > > adding to the project: +++ project.pro
> > > > + mingw {
> > > > + INCLUDEPATH += $PROJ/libraries/win/include
> > > > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > > > + }
> > > >
> > > > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build 
> > > > dir, be
> > > > it shadow or not. I don't want to copy the libraries to the shadow dir 
> > > > in
> > > > QMAKE_PRE_LINK because they *never* change.
> > >
> > > You're mixing environment variables and qmake variables. Qmake variables
> > > always start with a double dollar sign and are expanded by qmake when it
> > > writes the Makefile output. You can see their value with message().
> > >
> > > qmake does not expand environment variables at all.
> > >
> > > $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> > > Project MESSAGE: r = $X b
> > >
> > > The environment variables are written as-is to your Makefile. It's up to 
> > > you
> > > to write something that make will understand.
> > >
> > > $PROJ is not a valid environment variable expansion in Make.
> >
> >
> > Right. I used $PROJ for illustrative purposes. I guess the flaw in my 
> > thinking
> > is that when the shadow build is made, that there is some way to reference 
> > the
> > original location( other than ../project_name
> >
> > Maybe all I need is:
> > PROJ=../project
>
> I think you'd need to use $$_PRO_FILE_PWD_ for it to work in a shadow build 
> (?)
>
> E.g. assuming
>
> $PROJ/project.pro
> $PROJ/libraries/win/include/mylib.h
> $PROJ/libraries/win/x64/mylib.lib
>
> Something like
>
> mingw {
> INCLUDEPATH += $$_PRO_FILE_PWD_/libraries/win/include
> LIBS += $$_PRO_FILE_PWD_/libraries/win/x64
> }

Scratch my suggestion and just use $$PWD. I had misunderstood that variable.

The docs for it says it all: "Specifies the full path leading to the
directory containing the current file being parsed. This can be useful
to refer to files within the source tree when writing project files to
support shadow builds.", which sounds like what you need (and as
suggested by Jérôme in his mail.

Elvis

>
> Elvis
>
> >
> > Thank you for example. Very enlightening.
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

2021-04-21 Thread Jérôme Godbout

For my .pri and qmake build process (I haven’t move to cmake yet) I do some 
variable definition for the path:
AMOTUS_Qt_FILESYSTEM_PATH = $$clean_path($$PWD/../FileSystem)

So you could define a variable anywhere you are (relative to the .pro or .pri 
files). Might help finding your project root or define it.

This allows me to have a variable that point to some module folder later on. I 
can copy, include, etc files/folders based on those variables, also make 
conditional check if the variable is defined to include glue between module 
(extension modules with each other).

Something like:
contains(AMOTUS_SUBREPOS_OPTIONAL_NAMES, Amotus_Qt_FileSystem){
include($$AMOTUS_Qt_FILESYSTEM_PATH/Amotus_Qt_FileSystem.pri)
}

From: Interest  on behalf of Jason H 

Date: Wednesday, April 21, 2021 at 1:42 PM
To: Thiago Macieira 
Cc: interest@qt-project.org 
Subject: Re: [Interest] Help a unix guy on windows qmake

> Sent: Wednesday, April 21, 2021 at 1:14 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Help a unix guy on windows qmake
>
> On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > Now, when compiling, regardless of shadow build or not, refer to the libs by
> > adding to the project: +++ project.pro
> > + mingw {
> > + INCLUDEPATH += $PROJ/libraries/win/include
> > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > + }
> >
> > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, be
> > it shadow or not. I don't want to copy the libraries to the shadow dir in
> > QMAKE_PRE_LINK because they *never* change.
>
> You're mixing environment variables and qmake variables. Qmake variables
> always start with a double dollar sign and are expanded by qmake when it
> writes the Makefile output. You can see their value with message().
>
> qmake does not expand environment variables at all.
>
> $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> Project MESSAGE: r = $X b
>
> The environment variables are written as-is to your Makefile. It's up to you
> to write something that make will understand.
>
> $PROJ is not a valid environment variable expansion in Make.

Right. I used $PROJ for illustrative purposes. I guess the flaw in my thinking
is that when the shadow build is made, that there is some way to reference the
original location( other than ../project_name

Maybe all I need is:
PROJ=../project

Thank you for example. Very enlightening.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

2021-04-21 Thread Elvis Stansvik

Den ons 21 apr. 2021 kl 20:43 skrev Elvis Stansvik :
>
> Den ons 21 apr. 2021 kl 19:49 skrev Jason H :
> >
> >
> >
> > > Sent: Wednesday, April 21, 2021 at 1:14 PM
> > > From: "Thiago Macieira" 
> > > To: interest@qt-project.org
> > > Subject: Re: [Interest] Help a unix guy on windows qmake
> > >
> > > On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > > > Now, when compiling, regardless of shadow build or not, refer to the 
> > > > libs by
> > > > adding to the project: +++ project.pro
> > > > + mingw {
> > > > + INCLUDEPATH += $PROJ/libraries/win/include
> > > > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > > > + }
> > > >
> > > > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build 
> > > > dir, be
> > > > it shadow or not. I don't want to copy the libraries to the shadow dir 
> > > > in
> > > > QMAKE_PRE_LINK because they *never* change.
> > >
> > > You're mixing environment variables and qmake variables. Qmake variables
> > > always start with a double dollar sign and are expanded by qmake when it
> > > writes the Makefile output. You can see their value with message().
> > >
> > > qmake does not expand environment variables at all.
> > >
> > > $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> > > Project MESSAGE: r = $X b
> > >
> > > The environment variables are written as-is to your Makefile. It's up to 
> > > you
> > > to write something that make will understand.
> > >
> > > $PROJ is not a valid environment variable expansion in Make.
> >
> >
> > Right. I used $PROJ for illustrative purposes. I guess the flaw in my 
> > thinking
> > is that when the shadow build is made, that there is some way to reference 
> > the
> > original location( other than ../project_name
> >
> > Maybe all I need is:
> > PROJ=../project
>
> I think you'd need to use $$_PRO_FILE_PWD_ for it to work in a shadow build 
> (?)
>
> E.g. assuming
>
> $PROJ/project.pro
> $PROJ/libraries/win/include/mylib.h
> $PROJ/libraries/win/x64/mylib.lib
>
> Something like
>
> mingw {
> INCLUDEPATH += $$_PRO_FILE_PWD_/libraries/win/include
> LIBS += $$_PRO_FILE_PWD_/libraries/win/x64

Should have been LIBS += $$_PRO_FILE_PWD_/libraries/win/x64/mylib.lib

Elvis

> }
>
> Elvis
>
> >
> > Thank you for example. Very enlightening.
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

2021-04-21 Thread Elvis Stansvik

Den ons 21 apr. 2021 kl 19:49 skrev Jason H :
>
>
>
> > Sent: Wednesday, April 21, 2021 at 1:14 PM
> > From: "Thiago Macieira" 
> > To: interest@qt-project.org
> > Subject: Re: [Interest] Help a unix guy on windows qmake
> >
> > On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > > Now, when compiling, regardless of shadow build or not, refer to the libs 
> > > by
> > > adding to the project: +++ project.pro
> > > + mingw {
> > > + INCLUDEPATH += $PROJ/libraries/win/include
> > > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > > + }
> > >
> > > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, 
> > > be
> > > it shadow or not. I don't want to copy the libraries to the shadow dir in
> > > QMAKE_PRE_LINK because they *never* change.
> >
> > You're mixing environment variables and qmake variables. Qmake variables
> > always start with a double dollar sign and are expanded by qmake when it
> > writes the Makefile output. You can see their value with message().
> >
> > qmake does not expand environment variables at all.
> >
> > $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> > Project MESSAGE: r = $X b
> >
> > The environment variables are written as-is to your Makefile. It's up to you
> > to write something that make will understand.
> >
> > $PROJ is not a valid environment variable expansion in Make.
>
>
> Right. I used $PROJ for illustrative purposes. I guess the flaw in my thinking
> is that when the shadow build is made, that there is some way to reference the
> original location( other than ../project_name
>
> Maybe all I need is:
> PROJ=../project

I think you'd need to use $$_PRO_FILE_PWD_ for it to work in a shadow build (?)

E.g. assuming

$PROJ/project.pro
$PROJ/libraries/win/include/mylib.h
$PROJ/libraries/win/x64/mylib.lib

Something like

mingw {
INCLUDEPATH += $$_PRO_FILE_PWD_/libraries/win/include
LIBS += $$_PRO_FILE_PWD_/libraries/win/x64
}

Elvis

>
> Thank you for example. Very enlightening.
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs



On 4/21/2021 11:04 AM, Giuseppe D'Angelo wrote:

On 21/04/2021 17:42, Jason H wrote:

Personally, I think the exsting QtQuick element should be scrapped and
just focus on QML versions of the existing Widget functionality. I love
the QML syntax, hate that it's not just a layer on top of widgets.
That said, I still really like both.

Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?


Having had this conversation before in here, I believe he means exactly 
what Tweedle Dee and Tweedle Dum described to me as QML during dart 
league all of those years ago.


QML fully pre-compiles to Widgets.

Just a way of getting rid of .UI files that, during 4.x days had a 
history of getting corrupted. Yes, we recently had yet another instance 
of that in here where someone opened old 4.x era .UI files with 
current/recent Designer and the hidden deleted layout started kicking 
widgets that shouldn't be there into the running application.


A QML-like syntax that generated C++ source and header files for widgets 
much like happens with .UI, kicking JavaScript to the curb. You get the 
snap and feel of native binary without having to saddle an application 
with 2 VMs.



--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Nuno Santos

Boas Rui,

> On 21 Apr 2021, at 18:24, Rui Oliveira  wrote:
> I did notice your product line before, when you first answered me.  
> 
> I like the look! Would you like to tell a bit about your experience in moving 
> to Qt Quick? What were your main barriers?
> 

As I just mentioned in my last email, it is a mindset shift. When I started 
using QtQuick I was not aware that I really needed a new mindset to work with 
Qml. That took me a while.

Then possibilites are quite endless since you have a lot of data 
interoperability between C++ and Javascript on the Qml side. Some of this 
capabilities you will only learn later when you are confortable with the 
basics. 

Of course things can get complex, specially when you have to create your own 
scene graph nodes, to draw custom high performance views, just like the one you 
want to do for your application to display an FFT visualiser.


I believe the architecture will change from application to application and from 
developer to developer.

> And how much work was it to get this look?
> 

It really depends on the complexity of UI. But in general, 5x to 10x times of 
less with any other UI technology I have ever used.

For instance, TKFX, LK and DRC did not had designer. I have made the design 
while coding the apps. I would make visual improvements along the way, 
iteration by iteration. 

FRMS and K7D and ConnectionOpen have design work. I’ve set the building the 
blocks and the designer provided me the style. Then applied the style.

> They should give you a talk time at a Qt  days!
> 
Actually I had a chance to share my story 4 years ago at QtWS17 -> 
https://www.youtube.com/watch?v=vgBq4dMoI_g 


It is a bit outdated now. I only had 3 products back then! :)

Nuno

> Rui
> 
> Em 21/04/2021 17:31, Nuno Santos escreveu:
>> For me, the major benefit of Qml is speed. Before using Qml I’ve done a 
>> couple of years doing Qt Widgets. The glue code to make things work is a big 
>> pain. You can declare interfaces so easily in Qml, and still have the 
>> ability to quickly change everything without having to rewrite all the glue 
>> code. I’ve also coded native iOS and Android. Major pain with glue code 
>> again.
>> 
>> If you care about time to market, Qml is a definitely worth the investment. 
>> It is an investment because if you are still in the Widgets mindset, it will 
>> take you a while until you have a Quick mindset.
>> 
>> I realised that I could never maintain multiple code bases and make the 
>> product line grow, alone…. but with QtQuick I did. I’ve been using Qt Quick 
>> since 2014, 7 years now. In 7 years I’ve built 7 products:
>> 
>> www.imaginando.pt/products/drc 
>> www.imaginando.pt/products/frms 
>> www.imaginando.pt/products/k7d 
>> www.imaginando.pt/products/dlym 
>> www.imaginando.pt/products/lk 
>> www.imaginando.pt/products/tkfx 
>> www.connectionopen.com 
>> 
>> Most of this products are available for all platforms, Windows, Mac, iOS and 
>> Android, with a consistent look in all platforms.
>> 
>> Nuno
>> 
>>> On 21 Apr 2021, at 17:13, Rui Oliveira >> > wrote:
>>> 
>>> At least, it would be convenient to reap the benefits of QML: HW 
>>> acceleration, for example. 
>>> 
>>> I personally don't care for QML. I would prefer to write everything in C++. 
>>> But that's me. If there was a "no-QML-Quick-API" I'd be so much happy. No 
>>> more gluing code and properties and questions like 
>>> this:https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
>>>  
>>> 
>>> I could just use what I know: C++... The talk Volker linked in this thread 
>>> talks a lot about "working easily with your designers". But I'm just me... 
>>> So the team point is moot. I also don't have a background as frontend 
>>> engineer, so I never bothered to learn JS. I guess it's implicit that this 
>>> is another advantage of QML. Just take the armies of frontend devs that 
>>> exist in the web design market and employ them on GUI applications, cheaper 
>>> than a C++ programmer. Likewise, that sure is a reason of why Electron and 
>>> web backends on JS are so popular (and the results so disastrous, 
>>> sometimes). Some seem to agree with me: https://github.com/uwerat/qskinny 
>>> 
>>> But I think the "dream" is the same feature set as QWidgets as Qt Quick 
>>> Controls. And some things to make desktop usage actually decent, like 
>>> native dialogues and especially menus. So that on Macs the menu goes to the 
>>> top bar (also on some GNU/Linux graphical configurations),

Re: [Interest] Help a unix guy on windows qmake



> Sent: Wednesday, April 21, 2021 at 1:14 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Help a unix guy on windows qmake
>
> On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> > Now, when compiling, regardless of shadow build or not, refer to the libs by
> > adding to the project: +++ project.pro
> > + mingw {
> > + INCLUDEPATH += $PROJ/libraries/win/include
> > + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> > + }
> >
> > It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, be
> > it shadow or not. I don't want to copy the libraries to the shadow dir in
> > QMAKE_PRE_LINK because they *never* change.
>
> You're mixing environment variables and qmake variables. Qmake variables
> always start with a double dollar sign and are expanded by qmake when it
> writes the Makefile output. You can see their value with message().
>
> qmake does not expand environment variables at all.
>
> $ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
> Project MESSAGE: r = $X b
>
> The environment variables are written as-is to your Makefile. It's up to you
> to write something that make will understand.
>
> $PROJ is not a valid environment variable expansion in Make.


Right. I used $PROJ for illustrative purposes. I guess the flaw in my thinking
is that when the shadow build is made, that there is some way to reference the
original location( other than ../project_name

Maybe all I need is:
PROJ=../project

Thank you for example. Very enlightening.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake


On 21/04/2021 19:14, Thiago Macieira wrote:

qmake does not expand environment variables at all.

$ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
Project MESSAGE: r = $X b


AFAIK, there's distinct syntax for everything:

$$X is a qmake variable called X
$$(X) is an environment variable called X (evaluated when qmake is ran)
$(X) is an environment variable called X (evaluated when make is ran)

But no $X. I'm still not sure what $PROJ means.

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Thorsten Glaser

On Wed, 21 Apr 2021, Giuseppe D'Angelo via Interest wrote:

> I'm not sure where to find QML on desktop stories, there's however a showroom
> https://showroom.qt.io/ where people can leave links to their applications.

You can probably add MuseScore 4 to that list. Mu͒4 is not yet finished but
it’s definitely implementing quite a massive amount in QML. See
https://github.com/musescore/MuseScore/tree/master/src/appshell/qml and
other directories.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs


Olá Nuno,

I did notice your product line before, when you first answered me.

I like the look! Would you like to tell a bit about your experience in 
moving to Qt Quick? What were your main barriers? And how much work was 
it to get this look?


They should give you a talk time at a Qt  days!

Rui

Em 21/04/2021 17:31, Nuno Santos escreveu:
For me, the major benefit of Qml is speed. Before using Qml I’ve done 
a couple of years doing Qt Widgets. The glue code to make things work 
is a big pain. You can declare interfaces so easily in Qml, and still 
have the ability to quickly change everything without having to 
rewrite all the glue code. I’ve also coded native iOS and 
Android. Major pain with glue code again.


If you care about time to market, Qml is a definitely worth the 
investment. It is an investment because if you are still in the 
Widgets mindset, it will take you a while until you have a Quick mindset.


I realised that I could never maintain multiple code bases and make 
the product line grow, alone…. but with QtQuick I did. I’ve been using 
Qt Quick since 2014, 7 years now. In 7 years I’ve built 7 products:


www.imaginando.pt/products/drc 
www.imaginando.pt/products/frms 
www.imaginando.pt/products/k7d 
www.imaginando.pt/products/dlym 
www.imaginando.pt/products/lk 
www.imaginando.pt/products/tkfx 
www.connectionopen.com 

Most of this products are available for all platforms, Windows, Mac, 
iOS and Android, with a consistent look in all platforms.


Nuno

On 21 Apr 2021, at 17:13, Rui Oliveira > wrote:


At least, it would be convenient to reap the benefits of QML: HW 
acceleration, for example.


I personally don't care for QML. I would prefer to write everything 
in C++. But that's me. If there was a "no-QML-Quick-API" I'd be so 
much happy. No more gluing code and properties and questions like 
this: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
I could just use what I know: C++... The talk Volker linked in this 
thread talks a lot about "working easily with your designers". But 
I'm just me... So the team point is moot. I also don't have a 
background as frontend engineer, so I never bothered to learn JS. I 
guess it's implicit that this is another advantage of QML. Just take 
the armies of frontend devs that exist in the web design market and 
employ them on GUI applications, cheaper than a C++ programmer. 
Likewise, that sure is a reason of why Electron and web backends on 
JS are so popular (and the results so disastrous, sometimes). Some 
seem to agree with me: https://github.com/uwerat/qskinny


But I think the "dream" is the same feature set as QWidgets as Qt 
Quick Controls. And some things to make desktop usage actually 
decent, like native dialogues and especially menus. So that on Macs 
the menu goes to the top bar (also on some GNU/Linux graphical 
configurations), etc etc. When I look at frameworks from like the 
.net ecosystem, which is growing so fast, I see exactly that. 
Practical example: https://avaloniaui.net/ is totally rendered with 
SKIA#, but there is 
http://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/. 
Also, allowing the window to resize without it glitching all over, 
and other desktop/productivity things.


Or, in reverse, if the RHI backend for QWidgets really comes to life, 
and QWidgets keeps receiving some love to be up standard with the 
latest OSes, and receive a public RHI Painter API instead of 
QOpenGLWidget, and look decent on hi-dpi, that's a winning product 
right there. In my opinion, anyway...


That said, I wouldn't support scrapping what's already done. Just 
improving it. Like the native look and feel in QML actually going 
somewhere, and having a feature-equivalent set to QWidgets for 
desktop work.


Rui

Em 21/04/2021 16:48, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped 
and just focus on QML versions of the existing Widget 
functionality. I love the QML syntax, hate that it's not just a 
layer on top of widgets.

That said, I still really like both.


Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?

Thanks,


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org 
https://lists.qt-project.org/listinfo/interest



___
Interest mailing list

Re: [Interest] Help a unix guy on windows qmake

On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> Now, when compiling, regardless of shadow build or not, refer to the libs by
> adding to the project: +++ project.pro
> + mingw {
> + INCLUDEPATH += $PROJ/libraries/win/include
> + LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
> + }
> 
> It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, be
> it shadow or not. I don't want to copy the libraries to the shadow dir in
> QMAKE_PRE_LINK because they *never* change.

You're mixing environment variables and qmake variables. Qmake variables 
always start with a double dollar sign and are expanded by qmake when it 
writes the Makefile output. You can see their value with message().

qmake does not expand environment variables at all.

$ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
Project MESSAGE: r = $X b

The environment variables are written as-is to your Makefile. It's up to you 
to write something that make will understand.

$PROJ is not a valid environment variable expansion in Make.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

On Wednesday, 21 April 2021 09:54:09 PDT Jason H wrote:
> MinGW is not x64? It's running on a fairly recent windows 10 machine.

"mingw32" means "Minimal GNU for Win32" and Win32 is the name of the API set. 
It's historical and applies to 64-bit too. That's why the mkspecs for windows 
are win32-msvc, win32-mingw, win32-icc and the MinGW 64-bit compiler is called 
"x86_64-w64-mingw32-gcc.exe"

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake

On Wednesday, 21 April 2021 08:49:02 PDT Jason H wrote:
> I'm having a bugger of a time getting a project working under windows. I've
> been doit under mac and linux for the last many years. What is the proper
> scope? Allegedly these are listed in C:\Qt\$ver\$compiler\mkspecs, however
> there are no win64 ones. I'm using mingw.

Your spec is win32-mingw then.

> Why is there no $PROJ variable for linking when shadow building?

Because there's no such variable at all. See
https://doc.qt.io/qt-6/qmake-variable-reference.html

Note I assume you mean $$ everywhere you wrote $.

> $PWD resolves to the shadow build dir, it seems?

The directory from which qmake was run, yes.

> How do I properly refer LIBS to $PROJ/libraries/x64/mylib.lib?

Explain what the difficulty is to setting the variable LIBS.

> How do I properly refer INCLUDEPATH to $PROJ/libraries/mylib.h?

Ditto.

> You know what $PROJ means, but for some reason this concept doesn't exist in
> qmake yet?

No, I do not know what it means.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake



> Sent: Wednesday, April 21, 2021 at 12:04 PM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Help a unix guy on windows qmake
>
> On 21/04/2021 17:49, Jason H wrote:
> > What is the proper scope? Allegedly these are listed in 
> > C:\Qt\$ver\$compiler\mkspecs, however there are no win64 ones. I'm using 
> > mingw.
>
> mingw is the proper scope. When in doubt, look at Qt's own sources.
>
> > src/angle/src/libEGL/libEGL.pro
> > 19:mingw:equals(QT_ARCH, i386): DEF_FILE = 
> > $$ANGLE_DIR/src/libEGL/$${DEF_FILE_TARGET}_mingw32.def
> >
> > src/angle/src/libGLESv2/libGLESv2.pro
> > 9:mingw: equals(QT_ARCH, i386): DEF_FILE = 
> > $$ANGLE_DIR/src/libGLESv2/$${DEF_FILE_TARGET}_mingw32.def

MinGW is not x64? It's running on a fairly recent windows 10 machine.

> > Why is there no $PROJ variable for linking when shadow building?
> > $PWD resolves to the shadow build dir, it seems?
> > How do I properly refer LIBS to $PROJ/libraries/x64/mylib.lib?
> > How do I properly refer INCLUDEPATH to $PROJ/libraries/mylib.h?
> > You know what $PROJ means, but for some reason this concept doesn't exist 
> > in qmake yet?
>
> I... don't quite know what $PROJ means *for you*? :)
>
> Do you mean $$OUT_PWD? Do you mean $$shadowed($$PWD)?

% git clone project
% cd project
% export PROj=`pwd` # this is where I want to start the path for the .pro 
options below.
% mkdir $PROJ/libraries/win. ## developed on linux, add new platform: windows
% cp -r C:/blah/Vendor/win $PROJ/libraries/win ## copy vendor libraries
% git add .
% git commit -m "Add windows libraries"
% git push

Now, when compiling, regardless of shadow build or not, refer to the libs by 
adding to the project:
+++ project.pro
+ mingw {
+ INCLUDEPATH += $PROJ/libraries/win/include
+ LIBS += -L$PROJ/libraries/win/$ARCH -lvendor
+ }

It seems that $PWD ${PWD} or whatever ($${PWD}?) refer to the build dir, be it 
shadow or not. I don't want to copy the libraries
to the shadow dir in QMAKE_PRE_LINK because they *never* change.





___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

> On 21/04/2021 17:42, Jason H wrote:
> > Personally, I think the exsting QtQuick element should be scrapped and
> > just focus on QML versions of the existing Widget functionality. I love
> > the QML syntax, hate that it's not just a layer on top of widgets.
> > That said, I still really like both.
>
> Do you mean something like this
>
> https://github.com/KDAB/DeclarativeWidgets
>
> or actually reimplementing the widgets themselves?

There's a couple things going on here:
1. API
2. UI

Ideally the API should be widgets, the UI should be Quick.

* Making a library where QGraphicsProxyWidget seems like a right choice. (UI)
* I believe that there was some recent talk at reimplementing Qt Quick Controls 
with
  proper theming via 
https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
  also seems like a right (UI)
* The DeclarativeWidgets seems like what Qt should have done from the 
beginning. (API) (?)
  But... is not using QtQuick rendering. (Also there should be gallery!) 
"Declarative Widgets
allows you to use Qt Widgets with QML, but it does not use Qt Quick. 
Declarative Widgets is
still using the Qt Widgets rendering and wrapping platform native 
components under the hood,
whilst Qt Quick uses OpenGL for rendering (a software renderer is now 
available) and you had
to build your UI from basic components. Qt Quick Controls provide standard 
controls for Qt Quick."

And then there's https://github.com/uwerat/qskinny, kinda related but not.

It's a shame that the DeclarativeWidgets requires a supplemental commercial 
license (or GPL).
And looking up the commercial license cost is "contact sales" which means it's 
too expensive.
The motivation for use is "I rather the old API" but the interest level does 
not rise
to the level of "contacting sales". If it were transparently prices at the 
price of a
developer tool ($40-60) I could splurge. Think a Qt Marketplace offering?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Nuno Santos

For me, the major benefit of Qml is speed. Before using Qml I’ve done a couple 
of years doing Qt Widgets. The glue code to make things work is a big pain. You 
can declare interfaces so easily in Qml, and still have the ability to quickly 
change everything without having to rewrite all the glue code. I’ve also coded 
native iOS and Android. Major pain with glue code again.

If you care about time to market, Qml is a definitely worth the investment. It 
is an investment because if you are still in the Widgets mindset, it will take 
you a while until you have a Quick mindset.

I realised that I could never maintain multiple code bases and make the product 
line grow, alone…. but with QtQuick I did. I’ve been using Qt Quick since 2014, 
7 years now. In 7 years I’ve built 7 products:

www.imaginando.pt/products/drc 
www.imaginando.pt/products/frms 
www.imaginando.pt/products/k7d 
www.imaginando.pt/products/dlym 
www.imaginando.pt/products/lk 
www.imaginando.pt/products/tkfx 
www.connectionopen.com 

Most of this products are available for all platforms, Windows, Mac, iOS and 
Android, with a consistent look in all platforms.

Nuno

> On 21 Apr 2021, at 17:13, Rui Oliveira  wrote:
> 
> At least, it would be convenient to reap the benefits of QML: HW 
> acceleration, for example. 
> 
> I personally don't care for QML. I would prefer to write everything in C++. 
> But that's me. If there was a "no-QML-Quick-API" I'd be so much happy. No 
> more gluing code and properties and questions like this: 
> https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
>  
> 
> I could just use what I know: C++... The talk Volker linked in this thread 
> talks a lot about "working easily with your designers". But I'm just me... So 
> the team point is moot. I also don't have a background as frontend engineer, 
> so I never bothered to learn JS. I guess it's implicit that this is another 
> advantage of QML. Just take the armies of frontend devs that exist in the web 
> design market and employ them on GUI applications, cheaper than a C++ 
> programmer. Likewise, that sure is a reason of why Electron and web backends 
> on JS are so popular (and the results so disastrous, sometimes). Some seem to 
> agree with me: https://github.com/uwerat/qskinny 
> 
> But I think the "dream" is the same feature set as QWidgets as Qt Quick 
> Controls. And some things to make desktop usage actually decent, like native 
> dialogues and especially menus. So that on Macs the menu goes to the top bar 
> (also on some GNU/Linux graphical configurations), etc etc. When I look at 
> frameworks from like the .net ecosystem, which is growing so fast, I see 
> exactly that. Practical example: https://avaloniaui.net/ 
>  is totally rendered with SKIA#, but there 
> ishttp://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/ 
> . Also, 
> allowing the window to resize without it glitching all over, and other 
> desktop/productivity things. 
> 
> Or, in reverse, if the RHI backend for QWidgets really comes to life, and 
> QWidgets keeps receiving some love to be up standard with the latest OSes, 
> and receive a public RHI Painter API instead of QOpenGLWidget, and look 
> decent on hi-dpi, that's a winning product right there. In my opinion, 
> anyway...
> 
> That said, I wouldn't support scrapping what's already done. Just improving 
> it. Like the native look and feel in QML actually going somewhere, and having 
> a feature-equivalent set to QWidgets for desktop work. 
> 
> Rui
> 
> Em 21/04/2021 16:48, Giuseppe D'Angelo via Interest escreveu:
>> On 21/04/2021 17:42, Jason H wrote: 
>>> Personally, I think the exsting QtQuick element should be scrapped and just 
>>> focus on QML versions of the existing Widget functionality. I love the QML 
>>> syntax, hate that it's not just a layer on top of widgets. 
>>> That said, I still really like both. 
>> 
>> Do you mean something like this 
>> 
>> https://github.com/KDAB/DeclarativeWidgets 
>>  
>> 
>> or actually reimplementing the widgets themselves? 
>> 
>> Thanks, 
>> 
>> 
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org 
>> https://lists.qt-project.org/listinfo/interest 
>> 
> ___
> Interest mailing list
> Interest@qt-project.org
>

Re: [Interest] Squish for open source

2021-04-21 Thread Harri Porten


Hello Vadim,

Thanks for asking! We have provided non-commercial OSS projects with free 
licenses in the past. Please contact me off-list with information about 
your project. I'll see what can be done.


Harri.

On Mon, 19 Apr 2021, Vadim Peretokin wrote:


Following the news that Qt has acquired the excellent UI-based testing software 
Squish (https://www.qt.io/blog/quality-assurance-tools), could that offering be 
extended to
open source projects by QtC?

There's no real alternatives that I know of that can do UI-based testing for Qt 
Widgets projects - or if I haven't looked hard enough, happy to hear 
suggestions.

Best regards,
Vadim.




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

I'm amazed. The GldSrc and the Source engines aren't famous for being 
super easy to work with. And somehow Qt Quick can be integrated to make 
the menus? Damn, I'd like to see that source code.


Although, this reminded me of a related example: https://sciter.com/ 
(notice the first example in the image pane).


Also, this one: https://docs.ultralig.ht/docs/integrating-with-games

Interesting, and amazing, that these things are possible!


Em 21/04/2021 16:51, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 16:10, Rui Oliveira wrote:

Black Mesa Source?! Now that's an interesting one haha!



Yep, https://steamdb.info/depot/362894/ shows some familiar names in 
the installed libs. (That having been said, Qt is used only in the 
menus AFAIK :-))


Thanks,

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

At least, it would be convenient to reap the benefits of QML: HW 
acceleration, for example.


I personally don't care for QML. I would prefer to write everything in 
C++. But that's me. If there was a "no-QML-Quick-API" I'd be so much 
happy. No more gluing code and properties and questions like this: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
I could just use what I know: C++... The talk Volker linked in this 
thread talks a lot about "working easily with your designers". But I'm 
just me... So the team point is moot. I also don't have a background as 
frontend engineer, so I never bothered to learn JS. I guess it's 
implicit that this is another advantage of QML. Just take the armies of 
frontend devs that exist in the web design market and employ them on GUI 
applications, cheaper than a C++ programmer. Likewise, that sure is a 
reason of why Electron and web backends on JS are so popular (and the 
results so disastrous, sometimes). Some seem to agree with me: 
https://github.com/uwerat/qskinny


But I think the "dream" is the same feature set as QWidgets as Qt Quick 
Controls. And some things to make desktop usage actually decent, like 
native dialogues and especially menus. So that on Macs the menu goes to 
the top bar (also on some GNU/Linux graphical configurations), etc etc. 
When I look at frameworks from like the .net ecosystem, which is growing 
so fast, I see exactly that. Practical example: https://avaloniaui.net/ 
is totally rendered with SKIA#, but there is 
http://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/. Also, 
allowing the window to resize without it glitching all over, and other 
desktop/productivity things.


Or, in reverse, if the RHI backend for QWidgets really comes to life, 
and QWidgets keeps receiving some love to be up standard with the latest 
OSes, and receive a public RHI Painter API instead of QOpenGLWidget, and 
look decent on hi-dpi, that's a winning product right there. In my 
opinion, anyway...


That said, I wouldn't support scrapping what's already done. Just 
improving it. Like the native look and feel in QML actually going 
somewhere, and having a feature-equivalent set to QWidgets for desktop 
work.


Rui

Em 21/04/2021 16:48, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped 
and just focus on QML versions of the existing Widget functionality. 
I love the QML syntax, hate that it's not just a layer on top of 
widgets.

That said, I still really like both.


Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?

Thanks,


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Help a unix guy on windows qmake


On 21/04/2021 17:49, Jason H wrote:

What is the proper scope? Allegedly these are listed in 
C:\Qt\$ver\$compiler\mkspecs, however there are no win64 ones. I'm using mingw.


mingw is the proper scope. When in doubt, look at Qt's own sources.


src/angle/src/libEGL/libEGL.pro
19:mingw:equals(QT_ARCH, i386): DEF_FILE = 
$$ANGLE_DIR/src/libEGL/$${DEF_FILE_TARGET}_mingw32.def

src/angle/src/libGLESv2/libGLESv2.pro
9:mingw: equals(QT_ARCH, i386): DEF_FILE = 
$$ANGLE_DIR/src/libGLESv2/$${DEF_FILE_TARGET}_mingw32.def




Why is there no $PROJ variable for linking when shadow building?
$PWD resolves to the shadow build dir, it seems?
How do I properly refer LIBS to $PROJ/libraries/x64/mylib.lib?
How do I properly refer INCLUDEPATH to $PROJ/libraries/mylib.h?
You know what $PROJ means, but for some reason this concept doesn't exist in 
qmake yet?


I... don't quite know what $PROJ means *for you*? :)

Do you mean $$OUT_PWD? Do you mean $$shadowed($$PWD)?


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs


On 21/04/2021 16:10, Rui Oliveira wrote:

Black Mesa Source?! Now that's an interesting one haha!



Yep, https://steamdb.info/depot/362894/ shows some familiar names in the 
installed libs. (That having been said, Qt is used only in the menus 
AFAIK :-))


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Help a unix guy on windows qmake

I'm having a bugger of a time getting a project working under windows. I've 
been doit under mac and linux for the last many years.
What is the proper scope? Allegedly these are listed in 
C:\Qt\$ver\$compiler\mkspecs, however there are no win64 ones. I'm using mingw.

Why is there no $PROJ variable for linking when shadow building?
$PWD resolves to the shadow build dir, it seems?
How do I properly refer LIBS to $PROJ/libraries/x64/mylib.lib?
How do I properly refer INCLUDEPATH to $PROJ/libraries/mylib.h?
You know what $PROJ means, but for some reason this concept doesn't exist in 
qmake yet?







___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs


On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped and 
just focus on QML versions of the existing Widget functionality. I love 
the QML syntax, hate that it's not just a layer on top of widgets.

That said, I still really like both.


Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?

Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

You probably won't  -- it's too new. Unless you call automotive Infotainment consoles success stories.

The lack of proper QtQuick Controls (v2) held it back for a while.

Personally, I think the exsting QtQuick element should be scrapped and just focus on QML versions of the existing Widget functionality. I love the QML syntax, hate that it's not just a layer on top of widgets.

That said, I still really like both.

Sent: Wednesday, April 21, 2021 at 10:19 AM
From: eric.fedosej...@gmail.com
To: "'Jérôme Godbout'" , interest@qt-project.org
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

I took another look at the showcase and am still having trouble finding any substantial desktop application built with QML.

Desktops may now be a niche corner of the market, but they are still where most productivity occurs. Software is still being actively developed and sold for desktops and there remains a demand for a cross-platform desktop GUI solution.

Can QML be that solution? I am not sure because I cannot find any examples.

From: Jérôme Godbout 
Sent: Wednesday, April 21, 2021 9:23 AM
To: eric.fedosej...@gmail.com; interest@qt-project.org
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

You might want to give the showroom a look, some of them are Qml based:

https://showroom.qt.io/

Some use the Felgo layer:

https://felgo.com/resources/success-stories

http://en.esotericsoftware.com/forum/Facial-Animation-in-Qml-and-pushing-past-the-Spine-limits-3788

http://en.esotericsoftware.com/spine-runtimes#Qt%2FQML

https://opsensmedical.com/products/optomonitor/

https://www.kdab.com/development-resources/videos-webinars/demo-videos/

https://www.learnpyqt.com/examples/

Note: this is a personal point of view, strongly opinion ahead from that point

as for the Desktop application, the line is blurring more and more everyday (iPad and surface pro are good example that “desktop” is no more like it used to be for most people). The workstation is more for a specific corner case now a day. I would not limit myself to a few platforms, mobile and desktop are becoming a mix bag and removing platform is a bad future choice I think. I never liked the “native” look and feel, I prefer my user to be in my app feel across platform instead, they don’t get lost when using it on mobile, Mac OS or Windows… it doesn’t matter. Facebook, messenger, Google application, Apple application all tends to be this way too. The OS is just a low level tool/helper in the end, the actual work is made inside your application, the end user often care very little about the OS, as long as they can find and launch their app and do their stuff easily.

Jérôme Godbout, B. Ing.

Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114  

C: (581) 777-0050 
godbo...@dimonoff.com

dimonoff.com

1015 Avenue Wilfrid-Pelletier, 

Québec, QC G1W 0C4, 4e étage

From: Interest  on behalf of eric.fedosej...@gmail.com 
Date: Wednesday, April 21, 2021 at 8:37 AM
To: interest@qt-project.org 
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

Where are the examples of real QML desktop applications on The Qt Co. website? I did a quick walk through the customer showcase and cannot find them.

From: Interest  On Behalf Of Giuseppe D'Angelo via Interest
Sent: Monday, April 19, 2021 8:36 AM

This is false, as a quick walk through the customer showcase on TQC's website will show.

On 18/04/2021 14:50, Roland Hughes wrote:
> I guess QML is more present in embedded? Or maybe some entreprise
> stuff we don't know about...
> Just phones and John Deere.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread eric.fedosejevs

I took another look at the showcase and am still having trouble finding any
substantial desktop application built with QML.

Desktops may now be a niche corner of the market, but they are still where
most productivity occurs. Software is still being actively developed and
sold for desktops and there remains a demand for a cross-platform desktop
GUI solution.

Can QML be that solution? I am not sure because I cannot find any examples.

From: Jérôme Godbout  
Sent: Wednesday, April 21, 2021 9:23 AM
To: eric.fedosej...@gmail.com; interest@qt-project.org
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

You might want to give the showroom a look, some of them are Qml based:

https://showroom.qt.io/

Some use the Felgo layer:

https://felgo.com/resources/success-stories

http://en.esotericsoftware.com/forum/Facial-Animation-in-Qml-and-pushing-pas
t-the-Spine-limits-3788

http://en.esotericsoftware.com/spine-runtimes#Qt%2FQML

https://opsensmedical.com/products/optomonitor/

https://www.kdab.com/development-resources/videos-webinars/demo-videos/

https://www.learnpyqt.com/examples/

Note: this is a personal point of view, strongly opinion ahead from that
point

as for the Desktop application, the line is blurring more and more everyday
(iPad and surface pro are good example that desktop is no more like it
used to be for most people). The workstation is more for a specific corner
case now a day. I would not limit myself to a few platforms, mobile and
desktop are becoming a mix bag and removing platform is a bad future choice
I think. I never liked the native look and feel, I prefer my user to be in
my app feel across platform instead, they dont get lost when using it on
mobile, Mac OS or Windows it doesnt matter. Facebook, messenger, Google
application, Apple application all tends to be this way too. The OS is just
a low level tool/helper in the end, the actual work is made inside your
application, the end user often care very little about the OS, as long as
they can find and launch their app and do their stuff easily.

Jérôme Godbout, B. Ing.

Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114  

C: (581) 777-0050 
  godbo...@dimonoff.com

  dimonoff.com

1015 Avenue Wilfrid-Pelletier, 

Québec, QC G1W 0C4, 4e étage

From: Interest mailto:interest-boun...@qt-project.org> > on behalf of
eric.fedosej...@gmail.com 
mailto:eric.fedosej...@gmail.com> >
Date: Wednesday, April 21, 2021 at 8:37 AM
To: interest@qt-project.org 
mailto:interest@qt-project.org> >
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

Where are the examples of real QML desktop applications on The Qt Co.
website? I did a quick walk through the customer showcase and cannot find
them.

From: Interest mailto:interest-boun...@qt-project.org> > On Behalf Of Giuseppe D'Angelo
via Interest
Sent: Monday, April 19, 2021 8:36 AM

This is false, as a quick walk through the customer showcase on TQC's
website will show.

On 18/04/2021 14:50, Roland Hughes wrote:
> I guess QML is more present in embedded? Or maybe some entreprise 
> stuff we don't know about...
> Just phones and John Deere. 

___
Interest mailing list
Interest@qt-project.org  
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs


Hey Giuseppe, and discussion list!

I did watch all of those. In fact, my original post cites you directly, 
from a talk I believe to have happened in that event also.


Black Mesa Source?! Now that's an interesting one haha!

Anyway, some good information that I got here. Good to see someone from 
the Qt company acknowledge widgets, and that QML for the desktop app 
still needs some baking.


I'm still quite divided. I'm more inclined to widgets at this point, but 
it starts to look as the wrong bet... I guess we're at an interesting 
"middle" point, which is a bit weird.


Anyway, if the community in this mailing list wants to continue the 
discussion on these two technologies for the desktop, I welcome them.


If you want to discuss another things, change the subject title, because 
I get exited when I see answers to my post, which then aren't.


Rui

Em 21/04/2021 14:45, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 14:37, eric.fedosej...@gmail.com wrote:
Where are the examples of real QML desktop applications on The Qt Co. 
website? I did a quick walk through the customer showcase and cannot 
find them.


Well the question was about embedded :)

I'm not sure where to find QML on desktop stories, there's however a 
showroom https://showroom.qt.io/ where people can leave links to their 
applications.


These days you'll find QML in a bunch of a desktop applications, from 
Autodesk's to Zoom to Musiscore to VLC-next to Black Mesa Source. 
There's been a few  interesting talks at the past Qt Desktop Days 
(about Scrite, VLC, KDE and so on; check out the videos, they're all 
on Youtube) and some customer showcases at the past (in person) Qt 
World Summits.


Hope this helps,

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Question about QtDeclarative Internals

2021-04-21 Thread Volker Hilsheimer

> On 21 Apr 2021, at 15:48, Alex Shaw  wrote:
> 
> Hello,
> 
> I am relatively new to mailing lists, so if I am doing something wrong here 
> please forgive me.
> 
> Is this the place to ask questions about the internals of Qt modules?
> 
> More specifically:
> In QtDeclarative, can a QV4::ReturnedValue or a QV4::Value be converted into 
> an ExecutableCompilationUnit?
> 
> I'm trying to work on a patch for QJSEngine to allow modules to be registered 
> in C++ (similar to Node.js: import fs from "fs")
> The planned method is something along the lines of:
> void QJSEngine::registerModule(const QString , const QJSValue 
> )
> 
> I can see that behind the scenes, loadModule compiles a URL to an 
> ExecutableCompilationUnit, then saves it to a list of modules for future 
> lookup.
> I thought the easiest way to do what I need is to convert a QJSValue to an 
> internal QV4::Value, and from there into an ExecutableCompilationUnit.
> Is there any way of doing that?
> 

Hi Alex,

Welcome to the list! The “interest" list is primarily useful to discuss 
developing *with* Qt.

The development *of* Qt, which patching of QJSEngine would qualify as, is best 
discussed at

https://lists.qt-project.org/listinfo/development



Cheers,
Volker

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Question about QtDeclarative Internals


Hi Alex,

On 21/04/2021 15:48, Alex Shaw wrote:
I am relatively new to mailing lists, so if I am doing something wrong 
here please forgive me.


Is this the place to ask questions about the internals of Qt modules?


I'd actually recommend you to ask this question on the development@ 
mailing list. That's what most developers of Qt lurk. (interest@ is 
people who develop WITH Qt.)


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Question about QtDeclarative Internals

2021-04-21 Thread Alex Shaw

Hello,

I am relatively new to mailing lists, so if I am doing something wrong here
please forgive me.

Is this the place to ask questions about the internals of Qt modules?

More specifically:
In QtDeclarative, can a QV4::ReturnedValue or a QV4::Value be converted
into an ExecutableCompilationUnit?

I'm trying to work on a patch for QJSEngine to allow modules to be
registered in C++ (similar to Node.js: import fs from "fs")
The planned method is something along the lines of:
void QJSEngine::registerModule(const QString , const QJSValue
)

I can see that behind the scenes, loadModule compiles a URL to an
ExecutableCompilationUnit, then saves it to a list of modules for future
lookup.
I thought the easiest way to do what I need is to convert a QJSValue to an
internal QV4::Value, and from there into an ExecutableCompilationUnit.
Is there any way of doing that?

Thanks.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs


On 21/04/2021 14:37, eric.fedosej...@gmail.com wrote:

Where are the examples of real QML desktop applications on The Qt Co. website? 
I did a quick walk through the customer showcase and cannot find them.


Well the question was about embedded :)

I'm not sure where to find QML on desktop stories, there's however a 
showroom https://showroom.qt.io/ where people can leave links to their 
applications.


These days you'll find QML in a bunch of a desktop applications, from 
Autodesk's to Zoom to Musiscore to VLC-next to Black Mesa Source. 
There's been a few  interesting talks at the past Qt Desktop Days (about 
Scrite, VLC, KDE and so on; check out the videos, they're all on 
Youtube) and some customer showcases at the past (in person) Qt World 
Summits.


Hope this helps,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Jérôme Godbout

You might want to give the showroom a look, some of them are Qml based:
https://showroom.qt.io/

Some use the Felgo layer:
https://felgo.com/resources/success-stories

http://en.esotericsoftware.com/forum/Facial-Animation-in-Qml-and-pushing-past-the-Spine-limits-3788
http://en.esotericsoftware.com/spine-runtimes#Qt%2FQML

https://opsensmedical.com/products/optomonitor/
https://www.kdab.com/development-resources/videos-webinars/demo-videos/

https://www.learnpyqt.com/examples/

Note: this is a personal point of view, strongly opinion ahead from that point
as for the Desktop application, the line is blurring more and more everyday 
(iPad and surface pro are good example that “desktop” is no more like it used 
to be for most people). The workstation is more for a specific corner case now 
a day. I would not limit myself to a few platforms, mobile and desktop are 
becoming a mix bag and removing platform is a bad future choice I think. I 
never liked the “native” look and feel, I prefer my user to be in my app feel 
across platform instead, they don’t get lost when using it on mobile, Mac OS or 
Windows… it doesn’t matter. Facebook, messenger, Google application, Apple 
application all tends to be this way too. The OS is just a low level 
tool/helper in the end, the actual work is made inside your application, the 
end user often care very little about the OS, as long as they can find and 
launch their app and do their stuff easily.

Jérôme Godbout, B. Ing.

Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114
C: (581) 777-0050
godbo...@dimonoff.com
[signature_1674119260]
dimonoff.com
1015 Avenue Wilfrid-Pelletier,
Québec, QC G1W 0C4, 4e étage

From: Interest  on behalf of 
eric.fedosej...@gmail.com 
Date: Wednesday, April 21, 2021 at 8:37 AM
To: interest@qt-project.org 
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs
Where are the examples of real QML desktop applications on The Qt Co. website? 
I did a quick walk through the customer showcase and cannot find them.

From: Interest  On Behalf Of Giuseppe D'Angelo 
via Interest
Sent: Monday, April 19, 2021 8:36 AM

This is false, as a quick walk through the customer showcase on TQC's website 
will show.

On 18/04/2021 14:50, Roland Hughes wrote:
> I guess QML is more present in embedded? Or maybe some entreprise
> stuff we don't know about...
> Just phones and John Deere.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread eric.fedosejevs

Where are the examples of real QML desktop applications on The Qt Co. website? 
I did a quick walk through the customer showcase and cannot find them.

From: Interest  On Behalf Of Giuseppe D'Angelo 
via Interest
Sent: Monday, April 19, 2021 8:36 AM

This is false, as a quick walk through the customer showcase on TQC's website 
will show.

On 18/04/2021 14:50, Roland Hughes wrote:
> I guess QML is more present in embedded? Or maybe some entreprise 
> stuff we don't know about...
> Just phones and John Deere. 

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs



On 4/21/2021 7:17 AM, Vlad Stelmahovsky wrote:



On Wed, Apr 21, 2021 at 1:50 PM Roland Hughes 
mailto:rol...@logikalsolutions.com>> wrote:



On 4/21/2021 6:36 AM, Vlad Stelmahovsky wrote:

Using Electron has nothing to do with licensing issues. The issue
is common programming knowledge level is going down when
programmers paradise promised for newcomers: learn HTML
programming language (sic!) and you are rich
btw, is Electron licensed for use in medical devices?


The professional sound equipment company moved from Qt to Electron
because of licensing. They already had all of the C++ Qt
developers. They had to learn how to use Electron.


I have experience with a musicians related company, which just bought 
a license and that's it. no whining and excuses. they just have a real 
picture of their need and did what then have to do


We shall see. This company converted a very large installed base from Qt 
during the pandemic shutdown because of the licensing. They are a big 
name in professional sound and have quite a number of products. They 
make stuff for concert halls, high end theaters, and professional 
recording studios.


Personally I thought their code base was too extensive to ever leave. 
They bit the bullet.


Judging from the influx in the CopperSpice world, a lot of companies 
with projects large and small are biting the bullet.


Best regards,


--
Best regards,
Vlad


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Vlad Stelmahovsky

On Wed, Apr 21, 2021 at 1:50 PM Roland Hughes 
wrote:

>
> On 4/21/2021 6:36 AM, Vlad Stelmahovsky wrote:
>
> Using Electron has nothing to do with licensing issues. The issue is
> common programming knowledge level is going down when programmers paradise
> promised for newcomers: learn HTML programming language (sic!) and you are
> rich
> btw, is Electron licensed for use in medical devices?
>
>
> The professional sound equipment company moved from Qt to Electron because
> of licensing. They already had all of the C++ Qt developers. They had to
> learn how to use Electron.
>
>
> I have experience with a musicians related company, which just bought a
license and that's it. no whining and excuses. they just have a real
picture of their need and did what then have to do

-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs



On 4/20/2021 4:35 PM, Alexey Rusakov wrote:

Am I the only one to feel that Roland monopolises the mailing list again,
after a couple of years?


I'm sorry you feel that way. You can join the growing chorus to have 
Giuseppe D'Angelo placed on 18 month forced hibernation due to 
reprehensible behavior. His personal attacks and lashing out at people 
aren't adding anything to the conversation.


Given all of the graphing the OP is going to be doing with their 
implementation they are going to run headlong into the 
single-thread-i-ness of the main event loop. I ran into it with an 
embedded system where real-time live update graphing from a database had 
to be performed.  Setting up something for them to see that is a lot of 
work.


FeatherPad is in Ubuntu (and probably other distros) so with minimal 
effort someone can see the monkey pile effect on the single-thread-i-ness.


The OP asked a high level question which means that high level 
discussions about low level problems need to happen. I followed the link 
he provided and looked at the application type he wants to work on. If 
he doesn't design around the low level architectural issues 
(single-thread-i-ness of main event loop) he is going to have issues.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

On 4/21/2021 6:36 AM, Vlad Stelmahovsky wrote:
Using Electron has nothing to do with licensing issues. The issue is
common programming knowledge level is going down when programmers
paradise promised for newcomers: learn HTML programming language
(sic!) and you are rich

btw, is Electron licensed for use in medical devices?

The professional sound equipment company moved from Qt to Electron
because of licensing. They already had all of the C++ Qt developers.
They had to learn how to use Electron.

The "Explore this computer" app for Intel made the same move for the
same reason. A good number of KIOSK applications made the same move for
the same reason.

As to the licensing, if you can sufficiently distance the UI from the
code which must be deterministic, you can get away with a lot. There is
just a __lot__ of paperwork for RISK justification. I got a call from a
researcher/doctor touting the Johns Hopkins credentials wanting me to
work on a post-op patient monitor they were going to hook directly to a
Windows 10 desktop sans an intervening control unit. No, I did not take
the gig.

On Wed, Apr 21, 2021 at 1:30 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

LOL,

I never said it wasn't. I said phones and John Deere. My point was
this:

>That tiny subset on the Web site doesn't scratch the surface.

Of course the total number of embedded systems using Qt of any
flavor is going down as much of the market is moving to Electron
and other libraries given the licensing issues.

Automotive is a tiny subset of where Qt is historically used.

On 4/21/2021 6:26 AM, Vlad Stelmahovsky wrote:

With these numbers are you trying to convince me that QML is not
used in embedded? or what?

On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:

On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

It's completely true. That tiny subset on the Web site
doesn't scratch the surface. It certainly doesn't
encompass my customer base and I haven't heard anyone
pipe up on here using QML for anything non-significant
that wasn't phones or John Deere. Even the one medical
device we have been told about on this list has said you
can't do anything in QML, only painting.

its not true. f.ex all Volvo cars from 2015 until this year
using QML-based apps in their infotainment system

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12

https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015

https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016

2015 70,047 U.S. 503,127 global
2016 82,724 U.S. 534,332 global

I guess we need to have some common definition of subset and
surface?

The patient monitors that use Qt sans QML sell millions of
units. Granted, they only cost thousands, not tens of
thousands. The one I worked on that was released some time in
2015 reportedly sold 7 million units in its first few years.

--
Roland Hughes, President

Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com

https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

--
Best regards,

Vlad

--
Roland Hughes, President

Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Vlad Stelmahovsky

Using Electron has nothing to do with licensing issues. The issue is common
programming knowledge level is going down when programmers paradise
promised for newcomers: learn HTML programming language (sic!) and you are
rich
btw, is Electron licensed for use in medical devices?

On Wed, Apr 21, 2021 at 1:30 PM Roland Hughes 
wrote:

> LOL,
>
> I never said it wasn't. I said phones and John Deere. My point was this:
>
> >That tiny subset on the Web site doesn't scratch the surface.
>
> Of course the total number of embedded systems using Qt of any flavor is
> going down as much of the market is moving to Electron and other libraries
> given the licensing issues.
>
> Automotive is a tiny subset of where Qt is historically used.
> On 4/21/2021 6:26 AM, Vlad Stelmahovsky wrote:
>
> With these numbers are you trying to convince me that QML is not used in
> embedded? or what?
>
> On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes 
> wrote:
>
>>
>> On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:
>>
>>
>>
>> On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes <
>> rol...@logikalsolutions.com> wrote:
>>
>>>
>>> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>>>
>>> On 18/04/2021 14:50, Roland Hughes wrote:
>>>
>>> It's completely true. That tiny subset on the Web site doesn't scratch
>>> the surface. It certainly doesn't encompass my customer base and I haven't
>>> heard anyone pipe up on here using QML for anything non-significant that
>>> wasn't phones or John Deere. Even the one medical device we have been told
>>> about on this list has said you can't do anything in QML, only painting.
>>>
>>
>> its not true. f.ex all Volvo cars from 2015 until this year using
>> QML-based apps in their infotainment system
>>
>>
>> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12
>>
>>
>> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12
>>
>>
>> https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015
>>
>>
>> https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016
>>
>>
>> 2015   70,047  U.S.   503,127 global
>> 2016   82,724  U.S.   534,332 global
>>
>> I guess we need to have some common definition of subset and surface?
>>
>> The patient monitors that use Qt sans QML sell millions of units.
>> Granted, they only cost thousands, not tens of thousands. The one I worked
>> on that was released some time in 2015 reportedly sold 7 million units in
>> its first few years.
>>
>> --
>> Roland Hughes, President
>> Logikal Solutions
>> (630)-205-1593
>> https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog
>>
>>
>
> --
> Best regards,
> Vlad
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog
>
>

-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

LOL,

I never said it wasn't. I said phones and John Deere. My point was this:

>That tiny subset on the Web site doesn't scratch the surface.

Of course the total number of embedded systems using Qt of any flavor is
going down as much of the market is moving to Electron and other
libraries given the licensing issues.

Automotive is a tiny subset of where Qt is historically used.

On 4/21/2021 6:26 AM, Vlad Stelmahovsky wrote:
With these numbers are you trying to convince me that QML is not used
in embedded? or what?

On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:

On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

It's completely true. That tiny subset on the Web site
doesn't scratch the surface. It certainly doesn't encompass
my customer base and I haven't heard anyone pipe up on here
using QML for anything non-significant that wasn't phones or
John Deere. Even the one medical device we have been told
about on this list has said you can't do anything in QML,
only painting.

its not true. f.ex all Volvo cars from 2015 until this year using
QML-based apps in their infotainment system

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12

https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015

https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016

2015 70,047 U.S. 503,127 global
2016 82,724 U.S. 534,332 global

I guess we need to have some common definition of subset and surface?

The patient monitors that use Qt sans QML sell millions of units.
Granted, they only cost thousands, not tens of thousands. The one
I worked on that was released some time in 2015 reportedly sold 7
million units in its first few years.

--
Roland Hughes, President

Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

--
Best regards,
Vlad

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Vlad Stelmahovsky

With these numbers are you trying to convince me that QML is not used in
embedded? or what?

On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes 
wrote:

>
> On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:
>
>
>
> On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes 
> wrote:
>
>>
>> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>>
>> On 18/04/2021 14:50, Roland Hughes wrote:
>>
>> It's completely true. That tiny subset on the Web site doesn't scratch
>> the surface. It certainly doesn't encompass my customer base and I haven't
>> heard anyone pipe up on here using QML for anything non-significant that
>> wasn't phones or John Deere. Even the one medical device we have been told
>> about on this list has said you can't do anything in QML, only painting.
>>
>
> its not true. f.ex all Volvo cars from 2015 until this year using
> QML-based apps in their infotainment system
>
>
> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12
>
>
> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12
>
>
> https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015
>
>
> https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016
>
>
> 2015   70,047  U.S.   503,127 global
> 2016   82,724  U.S.   534,332 global
>
> I guess we need to have some common definition of subset and surface?
>
> The patient monitors that use Qt sans QML sell millions of units. Granted,
> they only cost thousands, not tens of thousands. The one I worked on that
> was released some time in 2015 reportedly sold 7 million units in its first
> few years.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog
>
>

-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs



On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:



On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes 
mailto:rol...@logikalsolutions.com>> wrote:



On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

It's completely true. That tiny subset on the Web site doesn't
scratch the surface. It certainly doesn't encompass my customer
base and I haven't heard anyone pipe up on here using QML for
anything non-significant that wasn't phones or John Deere. Even
the one medical device we have been told about on this list has
said you can't do anything in QML, only painting.


its not true. f.ex all Volvo cars from 2015 until this year using 
QML-based apps in their infotainment system

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12

https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015

https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016


2015   70,047  U.S.   503,127 global
2016   82,724  U.S.   534,332 global

I guess we need to have some common definition of subset and surface?

The patient monitors that use Qt sans QML sell millions of units. 
Granted, they only cost thousands, not tens of thousands. The one I 
worked on that was released some time in 2015 reportedly sold 7 million 
units in its first few years.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

2021-04-21 Thread Nuno Santos

Rui,

You need to extend QQuickItem and create your scene graph.

Open QtCreator and search for scene graph examples. Take a special look to 
"Scene Graph - Custom Geometry”

Best,

Nuno

> On 15 Apr 2021, at 11:25, Rui Oliveira  wrote:
> 
> Hey,
> As per the title implies, I would like some comments on the GUI offerings Qt 
> currently has. 
> 
> I'll share my own assessments and needs, and I'd like very much to hear your 
> comments.
> 
> So:
> 
> I want to write a desktop application. This desktop application would not 
> involve displaying lists of things, which seems to be what all 
> tutorials/guides/courses are about, especially on the QML side. This 
> application would involve some "custom graphics", namely a FFT display, and a 
> "waterfall" display. You can google for "GQRX" and you'll know what I want.
> 
> 
> 
> And then I looked at Qt, and:
> 
> First thing I have looked at were QWidgets. I feel comfortable staying in the 
> C++ domain. To implement said custom widgets I gave a shot to a class 
> inheriting from QOpenGLWidget. And honestly, the experience wasn't bad at 
> all! 
> 
> But, I feel very hesitant to start a project on QWidgets. It feels like 
> starting a project on dead tech. Although, I did watch Giuseppe D’Angelo's 
> talk in Qt Desktop Days 2020 (slides [1] 
> ), and 
> looking at slide 19, there seem to be prospects of evolution. My attention 
> goes especially to "Accelerate widget rendering & compositing through RHI". 
> Will QWidgets really have a RHI backend? And a QRhiWidget option? Or maybe 
> just QWidget and everything HW accelerated? I can dream...
> 
> I know QWidgets are no longer "interesting". Even KDE moved on from them... 
> And I understand that's not where the money is for now... Still, I'd like 
> some comments.
> 
> Now, QML.
> 
> Slide 25 of the same talk mentions native desktop styling for QQC2. I can't 
> find documentations on this. Are they already available yet? Also, in the 
> previous slide, "Planned in Qt 6.x: C++ API for Qt Quick elements". Does this 
> mean Qt Quick *without* QML? 
> 
> Also, in QML it seems to be very hard to have anything native-looking. I 
> looked at Qt Labs Platform [2] 
>  and things like the right 
> click menu aren't available on Windows, for example. Are there plans to 
> expand this? 
> 
> 
> 
> Either way, I'm quite divided. I'd like to hear your thoughts and 
> recommendations. 
> 
> In summary, it would seem that my options for the desktop with Qt are two 
> self-competing technologies: one "half-dead", one "3/4-baked"... I'd really 
> love to be wrong.
> 
> 
> 
> Thank you for your time,
> Rui
> 
> 
> 
> For those reading in plain text:
> [1] https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf 
>  
> [2] https://doc.qt.io/qt-6/qtlabsplatform-index.html 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs