Re: [Interest] Send Data to JavaScript

[Jérôme Godbout]

Have you tried with a QVariantMap for your Q_PROPERTY instead? Will be dull to 
convert from QVAriant to list and string for each values, but will probably 
work.

Jérôme Godbout, B. Ing.

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


From: Interest  on behalf of John Schneiderman 

Date: Monday, April 12, 2021 at 9:17 AM
To: qt qt 
Subject: [Interest] Send Data to JavaScript
I'm attempting to send data to the JavaScript side of the QWebEngine
code. This data is being emitted via a signal. The registration is
connected correctly as other components work just fine, though they're
emitting only a single int or QString.

An example of what I'm attempting is below:

class Demo : QObject

{

 Q_OBJECT

public:

 Q_PROPERTY(
 QMap mappings
 MEMBER mappings_
 NOTIFY mappingsChanged
 )

};


What I'm expecting is that mappings would be transformed on the
JavaScript side as:

mappings {

 "key" : ["abc", "def"]...

}

However, when I try to view the data in the emitted signal it's always
null. Any suggestions where I should look for more answers or perhaps
I'm going in an incorrect direction?

Thanks,


--
John Schneiderman
Senior Software Engineer
CDPR Squad
GOG.com
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] the path forward (or is it "how the things, look"?)

[Roland Hughes]

On 4/12/21 10:47 AM, Thorsten Glaser wrote:

On Mon, 12 Apr 2021, Roland Hughes wrote:


Again, ripping XCB out won't be a free effort even if the new library is
free as in beer, but the current situation with XCB is kind of at the
heart of everything when one steps back for a few days.

And this very well MUST be. I’m using Qt applications (both with and
without KDE) over remote connections (all three of X11, X11VNC and
xrdp), so requiring local GPU rendering isn’t going to fly at all.
So, the X11 protocol, either with libX11 or XCB, must keep working.

bye,
//mirabilos


I didn't mean to imply requiring remote GPU rendering. I was talking 
about applications having access to the GPU for compute intensive things.


Vulkan was just the latest one I heard about. Someone else has done work 
on remote Vulkan.


https://www.researchgate.net/publication/326371108_Vulkan_Abstraction_Layer_for_Large_Data_Remote_Rendering_System

I only read the snippet and maybe they are doing Web only.

H

According to NVIDIA, x11 must still work.

https://developer.nvidia.com/embedded/vulkan

=


 Vulkan Loader

Vulkan applications interact with Vulkan drivers through the loader. The 
loader is responsible for supporting multiple GPUs and their drivers. 
For supporting the latest Vulkan API version, the loader also needs to 
be the matching version.


More information about the loader is available here: Vulkan Loader 



Canonical provides a specific version of the loader with each LTS 
release and it is not upgraded frequently. This limits the Vulkan 
driver’s ability to support the latest API version. To address this, 
NVIDIA now provides a compatible loader version along with the BSP 
release. This ensures applications can use the latest supported Vulkan 
API version.


*The latest BSP release includes Vulkan loader version 1.2.132.*

The Vulkan Loader can also be built on the device using the following steps:

1. sudo apt-get update && sudo apt-get install git build-essential
   libx11-xcb-dev libxkbcommon-dev libwayland-dev libxrandr-dev cmake
2. git clone https://github.com/KhronosGroup/Vulkan-Loader.git
   
3. cd Vulkan-Loader && mkdir build && cd build
4. ../scripts/update_deps.py
5. cmake -DCMAKE_BUILD_TYPE=Release
   -DVULKAN_HEADERS_INSTALL_DIR=$(pwd)/Vulkan-Headers/build/install ..
6. make -j8

=

What I was saying was that it is time for "the project" to cut bait with 
what we have for graphics rendering. There are cross platform, industry 
standard, OpenSource GUI only libraries that work well on the remaining 
Qt targets, Windows, Linux, Android. This one, and I'm certain others, 
claim to have 3D and 4K/8K out of the box.


Cutting bait on the low-level GUI code and focusing on the high level 
things that make Qt good and useful would make "project sense." Android 
could stop feeling totally neglected. If 3D doesn't work it wouldn't be 
"the project's" fault.


Probably most importantly, this entire conversation would get rather 
moot. True, our good friend Scott and his company might still be 
screwed, but there would now be a real abstraction layer between Qt and 
the video hardware. I haven't delved into the actual API, but judging 
from that NVIDIA site snippet, the loader should have a non-depreciable 
API call for obtaining the supported API version. That would mean code 
could gracefully straddle many years of API.


I mean the list of companies providing Vulkan drivers on this site: 
https://www.khronos.org/vulkan/


Intel, AMD, NVIDIA, Qualcomm, BROADCOM, etc. means this is a significant 
standard and needs to be looked into. There may well be other low level 
GUI only OpenSource standards supported by these same companies. Thiago 
would be able to find the public information from Intel easier than the 
rest of us. (Not asking for insider information. If Intel released an 
XXX-API driver for some cards, I imagine it got published somewhere.


Can our good friend Scott build a version of Vulkan loader on RHEL 6 
with the xcb he has on there? I don't know.


How is Vulkan using X11-xcb? I don't know. Maybe it is only for the 
remote communication stuff that you need? Maybe our good friend Scott is 
still screwed after this move? I hope not, but still possible.


Quite a few Engines currently support Vulkan according to that link. 
Among them Unity, UNREAL, and UX3D. I'm not a game developer, but I've 
heard of those.


In general, there obviously isn't enough resources in "the project" to 
continue doing the low level GUI stuff __AND__ everything else. It's 
causing breakage in the customer base. At least one, possibly more) 
layers of abstraction need to be inserted between the Qt API and the 
graphics hardware. Maybe "the project" has to adopt an engine as well? 
Maybe "the project" creates its own engine on top of Vulkan now that 
some 

Re: [Interest] the path forward (or is it "how the things, look"?)

[Thorsten Glaser]

On Mon, 12 Apr 2021, Roland Hughes wrote:

> Again, ripping XCB out won't be a free effort even if the new library is 
> free as in beer, but the current situation with XCB is kind of at the 
> heart of everything when one steps back for a few days.

And this very well MUST be. I’m using Qt applications (both with and
without KDE) over remote connections (all three of X11, X11VNC and
xrdp), so requiring local GPU rendering isn’t going to fly at all.
So, the X11 protocol, either with libX11 or XCB, must keep working.

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] Send Data to JavaScript

[Roland Hughes]

On 4/12/21 8:56 AM, John Schneiderman wrote:

I'm attempting to send data to the JavaScript side of the QWebEngine
code. This data is being emitted via a signal.


Here's a link to an old tutorial.

https://myprogrammingnotes.com/communication-c-javascript-qt-webengine.html

Your little Demo was missing the signal declaration. I suspect the real 
problem is you aren't passing by reference.


=

class WebClass : public QObject
{
Q_OBJECT
Q_PROPERTY(QString someattribute MEMBER m_someattribute NOTIFY 
someattributeChanged)
public slots:
void jscallme()
{
QMessageBox::information(NULL,"jscallme","I'm called by js!");
}

signals:
void someattributeChanged(QString & attr);
private:
QString m_someattribute;
};

=

I humbly suggest you follow the slow and painful path here. (Knowing 
full well you are probably going to try just fixing the signal )


1.) Get just a QString to work

2.) Get just a QStringList to work

3.) Get a QMap to work

4.) Get a QMap to work

5.) Get your QMap to work

I suspect when moving from step 3 to 4 you may need to add a 
Q_DECLARE_METATYPE for your QMap definition. You didn't say what version 
of Qt you are using. I seem to remember running into that a while back. 
I cannot share any of the code that I did because that was bought and 
paid for by a client. During at least one rev of Qt, when you got to a 
container of containers things got a bit dicey.


Keep in mind that you don't need a signal. As Qt users we knee-jerk to 
use of signal/slot but you don't really need it. Cutting and pasting 
from that link.


view->page()->runJavaScript("jsfun();",[this](const QVariant ) { 
qDebug()page()->runJavaScript("function getelement(){return $('#elementid').val();} 
getelement();",[this](const QVariant ) { qDebug()<|QMap myMap; QVariantMap vmap; QMapIterator 
i(myMap); while (i.hasNext()) { i.next(); vmap.insert(i.key(), 
i.value()); } QJsonDocument json = QJsonDocument::fromVariant(vmap); |





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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

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

Re: [Interest] Futur of Qt Webengine in Qt 6

[Allan Sandfeld Jensen]

On Montag, 12. April 2021 13:20:36 CEST Frank Hemer wrote:
> Hi all,
> 
> i wonder what are the plans for Qt Webengine in Qt 6.
> 
> While webkit has been removed and replaced by webengine, there is still no
> replacement supported by the mingw compiler yet.
> As a commercial customer it was disappointing enought this happened within a
> minor release but even more to be told (by commercial support) that there
> currently is no replacement available - and no schedule for a replacement.
> 
> Does this mean we have to go back in time using com interfaces or are there
> other plans on this?
> 
The plans for Qt WebEngine in Qt 6 does not include support for mingw. But 
like Qt 5 we do support building with clang-cl, if you only need to avoid 
MSVC.

Best regards
Allan


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

Re: [Interest] cmake build issues

[Thiago Macieira]

On Thursday, 8 April 2021 12:18:30 PDT Nibedit Dey wrote:
> Hello Everyone,
> 
> I am following the below steps to build Qt 6.0.3 from the source. However,
> it fails in CMake build step with multiple header file inclusion issues. I
> tried it on both macOS and Linux. I faced similar issues.
> 
>- $ tar xvf qt-everywhere-src-6.0.3.tar.xz
>- $ cd qt-everywhere-src-6.0.3
>- $ ./configure
>- $ cmake --build . --parallel

As Alexandru has hinted, the problem here is that two of the commands above 
are wrapping what they are actually running:

./configure is running cmake. This is what the error log you saw is for.

cmake --build is running ninja or make. This is the error log you want, but 
isn't in a file called CMakeError.log. It's your regular terminal. Capture 
that.

-- 
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] the path forward - that 7 year thing - was, , , , willy-nilly

[Roland Hughes]

On 4/12/21 8:56 AM, interest-requ...@qt-project.org wrote:

>And who's "you" here? And how exactly did that sabotage a commercial 
contract between you and whoever entity gives you commercial support on 
RHEL6?


The "you" would be whoever participated in the decision to drop RHEL 6. 
That should be painfully obvious.


>It is. Triple stamped, no erasies, touch blue make it true.  LA LA LA 
LA LA LA LA LA.


It is not. The 4K monitor worked on the unchanged system __before__ the 
Qt based software was installed. We know this because nothing was 
changed on the monitor still worked.


The Qt support for 4K was not good.


Still wondering why the moderators are sleeping,


**So am I. **

You hurl personal insults at me and try to call them sarcasm. I pointed 
out the difference between your response and Software Engineering and 
that someone knowing the difference wouldn't have made such a statement. 
Every time someone points out what you say is not correct you call it a 
personal insult. It's time for the moderators to do something about you. 
It's not just me you lash out at. ***You've been unchecked for far too 
long.***


> Not only changing a monitor is changing the environment, it's also 
something that may simplynot work out of the box.


No, it's not. It is no different than than changing out a keyboard that 
already has a driver on the platform.


In order to meet the definition of "changing the environment" you have 
to change the kernel, CPU, or the drivers. Had they changed out the 
video card, thus introducing shiny new drivers, __that__ would have been 
changing the environment.


Hooking up a 500-key keyboard that requires a new driver, __that__ would 
be changing the environment.


The 4K capability fully existed in the environment. It was not 
previously exercised. When it finally was exercised (in production no 
less) it pointed out HiDPI support in that version of Qt was no good.


Bundled in with the fixing of HiDPI, for whatever reason, was the 
dropping of RHEL 6. That sabotaged support for Scott.


At the time of release 4K monitors were far too expensive to be "a 
corporate standard." Now that they are $300 and falling, they will be 
the new corporate standard. 27 inch monitors were really expensive when 
they first came out. Now, if you shop around you can find off-lease 27 
inch 1920xwhatever resolution monitors for around $80. As the price on 
them dropped they became corporate standards.


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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

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

Re: [Interest] [EXTERNAL] Re: Send Data to JavaScript

[Giuseppe D'Angelo via Interest]

Il 12/04/21 15:56, John Schneiderman ha scritto:

On 12.04.2021 15:35, Giuseppe D'Angelo via Interest wrote:

Are you sure about the transformation? Only certain data types are
supported for the C++ <-> QML data exchange, and I don't believe the
one you're using is:

I'm not using QML in this particular case. I'm using QWebEngine and
QWebChannel for communication between C++ and the JavaScript running.


I'm sorry, I must've misread.

But a similar consideration applies: do you have any documentation 
telling you how datatypes in C++ are mapped to datatypes in JS -- and 
thus if your QMap is supposed to be supported, or 
if instead you need to "massage" it a bit?


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: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] iOS and openGL

[Volker Hilsheimer]

> On 10 Apr 2021, at 09:02, maitai  wrote:
> 
> Hi,
> 
> I have a QWidget app running on many platforms including iOS, using 
> QGraphicsScene/View, Qt 5.15.2. The scene can contains many items, be 
> rotated, etc.
> 
> We enable openGL QGraphicsview's viewport as it is stated in the 
> documentation, i.e.
> 
>QOpenGLWidget *gl = new QOpenGLWidget();
>QSurfaceFormat format;
>format.setSamples(4);
>gl->setFormat(format);
>setViewport(gl);
> 
> That works pretty well on all platforms and improves the performances, except 
> on iOS (tested on iOS 14), where it is exactly the opposite: all become very 
> very slow even in not complicated situations.
> 
> Is there something we can do to about that?
> 
> I know openGL is deprecated on iOS (replaced by Metal) does Qt supports that?
> 
> Thanks
> Philippe.


Qt 6 supports Metal as one of the backends of the new Qt Rendering Hardware 
Interface (RHI) architecture that the Qt Quick scene graphs uses for rendering.

Qt Widgets (which QGraphicsView is a part of) will continue to use procedural 
painting using the existing paint engines, and not use QRhi.

So the best option for you is to not use the QOpenGLWidget viewport on iOS, 
based on your experience that it’s slower than the default software rasteriser.

Regards,
Volker


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

Re: [Interest] [EXTERNAL] Re: Send Data to JavaScript

[John Schneiderman]

On 12.04.2021 15:35, Giuseppe D'Angelo via Interest wrote:
Are you sure about the transformation? Only certain data types are 
supported for the C++ <-> QML data exchange, and I don't believe the 
one you're using is: 


I'm not using QML in this particular case. I'm using QWebEngine and 
QWebChannel for communication between C++ and the JavaScript running.



--
John Schneiderman
Senior Software Engineer
CDPR Squad
GOG.com



OpenPGP_0xB23C7A7C8E96CE3B.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Send Data to JavaScript

[Giuseppe D'Angelo via Interest]

On 12/04/2021 15:17, John Schneiderman wrote:


What I'm expecting is that mappings would be transformed on the
JavaScript side as:

mappings {

      "key" : ["abc", "def"]...

}

However, when I try to view the data in the emitted signal it's always
null. Any suggestions where I should look for more answers or perhaps
I'm going in an incorrect direction?


Are you sure about the transformation? Only certain data types are 
supported for the C++ <-> QML data exchange, and I don't believe the one 
you're using is:


https://doc.qt.io/qt-5/qtqml-cppintegration-data.html

In other words, you may need to change the datatype / transform it 
somehow before giving it to QML. (Also do you want to just _read_ it 
from QML or also write into it? The above QML syntax looks a bit sketchy...)



HTH,
--
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] the path forward - that 7 year thing - was, , , willy-nilly

[Giuseppe D'Angelo via Interest]

On 12/04/2021 13:59, Roland Hughes wrote:


On 4/2/21 5:00 AM, Giuseppe D'Angelo wrote:

(Is there a conflict of intents here because of the massive support to
the Qt Project? I can't see how -- if anything, one could say that the
commercial decisions may drive the decisions in the Qt Project,
certainly NOT that the Qt Project has the power to "sabotage" the
commercial decisions!)


Well, when you dropped RHEL 6 you sabotaged commercial support for it.


And who's "you" here? And how exactly did that sabotage a commercial 
contract between you and whoever entity gives you commercial support on 
RHEL6?





Try fully ripping out QML. Not just conditionally compiled out. Not just
"don't use it." Fully rip it out of the OpenSource product and all
support for it such that QtC has to add it back in for every release.


How about trying triple cooked chips?

Not just conditionally double cooked chips. Not just pre-fried chips. 
Fully triple cooked, first simmered, then deep fried at low temperature, 
then deep fried at high temperature.


Supported forever.

I'm sure Opensource Qt would thrive with some triple cooked chips added 
to every release.





  >The combination of monitor+Qt is by definition part of the environment
(as far as the end-user application is concerned). Changing a monitor is
changing the environment.

No, it's not.


It is. Triple stamped, no erasies, touch blue make it true.
LA LA LA LA LA LA LA LA.




  > But wait, don't your practices tell you that you should've run a risk
analysis, filed in the holy 29 documents (all named with fancy
acronyms,I'm sure), get an independent certification and applied the new
cover sheet on your TPS reports (didn't you get the memo?) before
approving the purchase of a new monitor model on a life-critical
workstation?

That statement makes it painfully obvious you never learned Software
Engineering.


Oh, so we're back at the personal insults, I see.



No. Replacing one monitor with one of equal or higher capability does
not meet definition of RISK. "Screens look like crap" does not meet the
definition of RISK.


Good. Then run the 4K display in full HD, it will look like crap, but 
not meet the definition of RISK so nothing to complain about.


Or run it in 4K, don't enable HiDPI, it will look like crap, but not 
meet the definition of RISK so nothing to complain about.




Note for readers of the list: the above was sarcasm. Not only changing a 
monitor is changing the environment, it's also something that may simply 
not work out of the box. (But what do I know, I've never learned True 
Software Engineering™).


To give you an idea: 4k MST displays may require Xorg and kernel 
upgrades on older systems, without which they may not work at all / work 
only at limited resolutions or refresh rates / appear as two monitors 
instead of one, confusing WMs and applications / display an image on 
just one half of it rather than the entire monitor. So purchasing a 
random 4k monitor, and calling it "low risk", is a total falsehood.




Still wondering why the moderators are sleeping,
--
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] Send Data to JavaScript

[John Schneiderman]

I'm attempting to send data to the JavaScript side of the QWebEngine 
code. This data is being emitted via a signal. The registration is 
connected correctly as other components work just fine, though they're 
emitting only a single int or QString.


An example of what I'm attempting is below:

class Demo : QObject

{

    Q_OBJECT

public:

        Q_PROPERTY(
            QMap mappings
                MEMBER mappings_
                NOTIFY mappingsChanged
        )

};


What I'm expecting is that mappings would be transformed on the 
JavaScript side as:


mappings {

    "key" : ["abc", "def"]...

}

However, when I try to view the data in the emitted signal it's always 
null. Any suggestions where I should look for more answers or perhaps 
I'm going in an incorrect direction?


Thanks,


--
John Schneiderman
Senior Software Engineer
CDPR Squad
GOG.com



OpenPGP_0xB23C7A7C8E96CE3B.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] the path forward (or is it "how the things, look"?)

[Roland Hughes]

On 4/12/21 5:14 AM, Thiago Macieira wrote:

  Roland is asking we don't, but it's simply
not an option for the Open Source project. So we have two choices:


It is an option. Notably not a pleasant one.

Please read previous message discussing Abstraction and "Naperville 
divorce."


When XCB became too much effort to bundle in with Qt so developers using 
Qt didn't have to care what was under the hood, it was time for a full 
divorce and replacement with a different underlying package. Admittedly 
the effort wouldn't be free, but it was time to rip the bandage off.


What you choose to use under the hood is of little concern to high level 
Qt application developers as long as we don't have to touch it. The 
Naperville Divorce of XCB made certain we all had to touch it. Sticking 
with XCB is really what torpedoed Scott. From what little I've 
researched there are ways to get much newer compilers on RHEL 6.


Some competitors are putting Vulkan under the hood to get graphics, 3D, 
and GPU access. According to the page below it is also on Andriod


https://www.khronos.org/vulkan/

Another in this thread listed quite a list of cross platform GUI libraries.

Again, ripping XCB out won't be a free effort even if the new library is 
free as in beer, but the current situation with XCB is kind of at the 
heart of everything when one steps back for a few days.


The state of Qt3D has already been dumped on quite succinctly. Yes, some 
of the details may not have been 100% accurate but the outside world 
view of it being the ugly red headed stepchild chained in the basement 
was spot on.


Jason and others have already painted a rather abysmal picture for Android.

It's time to relinquish the GUI part of Qt to a Highlander (There can be 
only one) and let it straddle the underlying video architectures on all 
platforms. Instead focus on the parts of Qt that actually make 
applications. The only GUI part you need to provide is consistent Styles 
support, assuming your chosen underlying GUI library does not.


You should be able to maintain more than 90% high level API 
compatibility yet jettison all of the low level graphics support in 
favor of one really good cross platform GUI library.


Scott, could you poke around and see what 4K supporting GUI libraries 
exist on RHEL 6? From an academic perspective it would be interesting to 
find out. That would identify what has been chasing 4K the longest.


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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

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

Re: [Interest] the path forward - that 7 year thing - was, , , willy-nilly

[Roland Hughes]

On 4/2/21 5:00 AM, Giuseppe D'Angelo wrote:

(Is there a conflict of intents here because of the massive support to
the Qt Project? I can't see how -- if anything, one could say that the
commercial decisions may drive the decisions in the Qt Project,
certainly NOT that the Qt Project has the power to "sabotage" the
commercial decisions!)


Well, when you dropped RHEL 6 you sabotaged commercial support for it.

Try fully ripping out QML. Not just conditionally compiled out. Not just 
"don't use it." Fully rip it out of the OpenSource product and all 
support for it such that QtC has to add it back in for every release.


>The combination of monitor+Qt is by definition part of the environment 
(as far as the end-user application is concerned). Changing a monitor is 
changing the environment.


No, it's not.

> But wait, don't your practices tell you that you should've run a risk 
analysis, filed in the holy 29 documents (all named with fancy 
acronyms,I'm sure), get an independent certification and applied the new 
cover sheet on your TPS reports (didn't you get the memo?) before 
approving the purchase of a new monitor model on a life-critical 
workstation?


That statement makes it painfully obvious you never learned Software 
Engineering.


No. Replacing one monitor with one of equal or higher capability does 
not meet definition of RISK. "Screens look like crap" does not meet the 
definition of RISK.


"Unable to read data placing patient at risk" does meet the definition 
of RISK.


Replacing with a lesser capability monitor does meet the definition of 
RISK because a 640x480 screen may not fit everything that was on the 
larger monitor.


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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

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

Re: [Interest] the path forward

[Roland Hughes]

On 4/2/21 5:00 AM, interest-requ...@qt-project.org wrote:

Are there lists other than Develop and Interest?  Splitting this one might
help.  One to discuss future changes civilly, one for support, one for
flames and arguments...


https://forum.qt.io/category/10/general-and-desktop

https://www.qtcentre.org/

You can ask to join this group
https://groups.google.com/g/even-more-qt-interest

Everyone used to post here:

https://groups.google.com/g/qt-project-list-development

Lots of seemingly dead groups too

https://groups.google.com/g/qt-for-embedded-linux-devices

https://groups.google.com/g/qt-navigation-bar

https://groups.google.com/g/qt-mailing-lists-qt-qml

https://groups.google.com/g/qt-projects

https://groups.google.com/g/qt-project-list-interest

https://groups.google.com/g/qt-interest

https://groups.google.com/g/cpp-and-qt-study-group

https://groups.google.com/g/qt-programming

https://groups.google.com/g/my-qt-group

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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

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

Re: [Interest] the path forward

[Roland Hughes]

On 4/2/21 5:00 AM, Stottlemyer, Brett (B.S.) wrote:

Roland's view is extreme.  It may_sound_  reasonable, but if you look, you will find it 
isn't reasonable.  His definition of "stable" is being able to update the Qt 
version, but on a 15 year old piece of hardware that is using a 15 year old OS, and 
everything should build without any porting.


It's not extreme, it is reality for many production worlds. One of which 
we now know is somehow impacting chip production at Intel. If your 
desktop/laptop has an Intel Inside logo, this conversation is now 
impacting you.


You're a bit off on "His definition."

Stable = able to upgrade Qt with minor coding changes and zero approved 
platform changes.


When an OS is locked due to FDA regulation or custom device drivers, you 
can't change the kernel. Install or upgrade a 3rd party graphics 
library, possibly.


Given Thiago's and a few others involved in coding "the project" 
comments to Scott, I think everybody forgot the purpose of a cross 
platform application framework.


**Abstraction**

Everything underneath can change as long as the high level remains.

I think you have forgotten it as well Mr. Brett, which is why you think 
my view is extreme. To be certain, it is much work for "the project" but 
not extreme.


Having had some time to let all of this percolate in the back of my mind 
I think I've determined the root of the problem.


A Naperville Divorce.

I've been a traveling consultant for over 30 years and it's one of the 
few places where the phenomena is widespread. Couple gets married, buys 
a house they can't afford, two cars they just __have__ to have, then max 
out their credit cards. They decide to solve this problem by getting a 
divorce. After the divorce they still live in the same house together. 
Half the time they don't even have separate bedrooms because they needed 
to keep the guest room open for company. Legally they are divorced and 
now they have payments to a lawyer added to the mix.


That's pretty much what happened with XCB. https://xcb.freedesktop.org/

We were abstractly writing our applications, not caring at all who or 
what "the project" was in bed with underneath all of it. Then "the 
project" decided to get a divorce and return to everyone a daughter they 
didn't know they had saying "she's all yours now."


They are still using XCB, they just aren't shipping a version of XCB 
with Qt and maintaining it. Now people have to care. They didn't fully 
divorce.


Judging from the presentations, CopperSpice is in the process of a 
complete divorce.


https://youtu.be/MXz2t0gvRxI

According to the video above the CsPaint stuff they are working on which 
will be rolled into CopperSpice uses Vulkan under the hood for 3D and 
graphics.


https://www.khronos.org/vulkan/

What Vulkan is and is not capable of I do not know. It seems to have an 
awful lot of industry buy in.


The point is, had the divorce from XCB been a real divorce, "the 
project" could have moved to a different underlying graphics package. 
There obviously is one on RHEL 6 that supports something close to 4K 
which is why all of the other software on the system looked good and 
Scott's Qt software looked like crap. (No offense meant Scott.)



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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

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

Re: [Interest] the path forward

[Cristián Maureira-Fredes]

On 4/2/21 1:27 PM, Benjamin TERRIER wrote:
For the visibility, well it's quite easy to spot. For example, 
qt-project.org  is just a redirect to 
https://www.qt.io/developers 


I have really good news for you then Benjamin :)
https://www.qt.io/blog/a-new-face-for-the-qt-project

Feel free to suggest new ideas for that page via JIRA!

Cheers

--
Dr. Cristián Maureira-Fredes
R Manager

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin

Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Futur of Qt Webengine in Qt 6

[Frank Hemer]

Hi all,

i wonder what are the plans for Qt Webengine in Qt 6.

While webkit has been removed and replaced by webengine, there is still no 
replacement supported by the mingw compiler yet.
As a commercial customer it was disappointing enought this happened within a 
minor release but even more to be told (by commercial support) that there 
currently is no replacement available - and no schedule for a replacement.

Does this mean we have to go back in time using com interfaces or are there 
other plans on this?

Best regards
Frank


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

Re: [Interest] cmake build issues

[Alexandru Croitor]

Hi,

I think you might be misreading the log. 
The build log snippet that you posted seems to be a config test, which is fine 
if it fails on certain platforms.

You should try to scroll through the log to see the real failure reason.
Or attach the full log to some service and share it so we can try to advise 
something.

> On 8. Apr 2021, at 21:18, Nibedit Dey  wrote:
> 
> Hello Everyone,
> 
> I am following the below steps to build Qt 6.0.3 from the source. However, it 
> fails in CMake build step with multiple header file inclusion issues. I tried 
> it on both macOS and Linux. I faced similar issues. 
>   • $ tar xvf qt-everywhere-src-6.0.3.tar.xz 
>   • $ cd qt-everywhere-src-6.0.3
>   • $ ./configure
>   • $ cmake --build . --parallel
> CMake log only mentions missing header files. Is there anything I am missing?
> A sample error: 
> Desktop/qt6/qt-everywhere-src-6.0.3/CMakeFiles/CMakeTmp/src.cxx:9:8: error: 
> use of undeclared identifier 'posix_fallocate'
> (void) posix_fallocate(0, 0, 0);
>^
> 1 error generated.
> make[1]: *** [CMakeFiles/cmTC_39cfa.dir/src.cxx.o] Error 1
> make: *** [cmTC_39cfa/fast] Error 2
> 
> Source file was:
> #include 
> #include 
> int main(int argc, char **argv)
> {
> (void)argc; (void)argv;
> /* BEGIN TEST: */
> (void) posix_fallocate(0, 0, 0);
> /* END TEST: */
> return 0;
> }
> 
> make: *** [all] Error 2
> 
> Any help will be appreciated. Thanks in advance.
> 
> Regards,
> Nibedit
> ___
> 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] the path forward - that 7 year thing - was, , , willy-nilly

[Roland Hughes]

On 4/2/21 5:00 AM, Thiago Macieira wrote:

I would expect Qt to query the version of X being used, say
multi-touch isn’t supported so the app cant support it. If my customer
complained that multi-touch works on the Windows, and CentOS 7 boxes, but not 
CentOS 6.
The reasoning is clear, the default X for CentOS 6 doesn’t support it.
I could then point them to the newer X and say have your IT dept move
your CentOS to the X.Y.Z version of X (which they wont be able to do)
and it will work.
  
Well, that's your answer there: the feature you want isn't supported on the OS you have. So why is Qt any different?


Your argument is flawed.

The end customer replaced a run of the mill 1920 x whatever monitor with 
a $300 4K monitor. The video card, OS, and video driver fully supported 
resolution well above 1920 x whatever. The Qt HiDPI support was broken 
in the release Scott has. Between broken and less broken Scott's 
platform was dropped.


When Scott's company, paying QtC commercial customer, reached out for 
support they were basically told "sucks to be you!" Admittedly they told 
them what they had to upgrade which is the same thing as no support for 
Scott's customer base.


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

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

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

Re: [Interest] Are Qt.transparent and "transparent" different colors?

[Giuseppe D'Angelo via Interest]

On 07/04/2021 12:09, Tor Arne Vestbø wrote:

Yes, please file a bug about this.


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

Cheers,

--
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] QtQuick over Qt3D (Qt 5.15)

[Konstantin Shegunov]

On Thu, Apr 1, 2021 at 8:40 AM Paul Lemire  wrote:

> Hello Paul,
>
Hello,

> It sounds to me like Scene2D is what you want as it renders a QtQuick
> scene into an offscreen texture which can then be applied to a Qt 3D mesh.
> Unfortunately it can only be used from QML.
>
> That being said, nothing is stopping you from having 90% of the Qt3D code
> in C++ and just having a small part in QML that essentially only
> instantiates your 3D Scene and the Scene2D and povides the 3D scene with
> the Scene2D texture. I think that would be the easiest.
>
Yes, that's what I've been using to "guide me through". And I do
acknowledge I can use it from QML, but there's also this thing:
https://bugreports.qt.io/browse/QTBUG-90411

> If you want to do it purely in C++, another approach (but more complex to
> set up and that would have to be tested) is to use a QSharedGLTexture to
> tell Qt3D about an existing OpenGL texture by textureId. This means using
> the Qt shared OpenGL context, and manually rolling your own
> QQuickRenderControl to render QtQuick into a QOpenGLTexture, and then
> providing the QOpenGLTexture's id to the QSharedGLTexture. You'll also need
> to ensure proper synching using fences (QWaitFence/QSetFence) to ensure
> that Qt3D is not trying to render while the the shared texture is being
> updated. This would be more or less similar to one of the manual test we
> have in Qt3D
> https://code.qt.io/cgit/qt/qt3d.git/tree/tests/manual/sharedtexture?h=5.15.2
>
> I hope that helps,
>
Indeed, thanks! Still, it doesn't seem there's a way I can hook into the
frame graph and just have anything drawn directly on the screen, is there?
The best I could do, as far as I can tell, is to have an ortographic camera
looking at a quad, which I can texture with whatever comes from the QtQuick
scene, it appears (i.e. what Florian Blume's code does here:
https://github.com/florianblume/Qt3D-BackgroundImage). Is this correct?

On Thu, Apr 1, 2021 at 11:15 AM Oleg Evseev  wrote:

> By the way in Qt 5.14 there comes an option to use Scene3D as underlay
> without FBO:
>
> https://doc.qt.io/qt-5/qml-qtquick-scene3d-scene3d.html#compositingMode-prop
>
> I did tried this, but encountered with a problem when using together with
> OnDemand:
> https://bugreports.qt.io/browse/QTBUG-82861
>

Indeed. It does seem bugs reports've accumulated for Qt3D over time. View3D
also segfaults (the example) for some reason.

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

[Interest] no_check_exist is now fatal?

[Olivier B.]

I'm transitioning to 5.15.2 from 5.11. It seems that now, qmake install
rules with config no_check_exist became fatal. Previously, they generated
errors, but the build kept going. Now the builds seem to stop at the first
error. Was this change conscient? (was the previous behaviour considered a
bug?)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] iOS and openGL

[maitai]

Hi,

I have a QWidget app running on many platforms including iOS, using 
QGraphicsScene/View, Qt 5.15.2. The scene can contains many items, be 
rotated, etc.


We enable openGL QGraphicsview's viewport as it is stated in the 
documentation, i.e.


QOpenGLWidget *gl = new QOpenGLWidget();
QSurfaceFormat format;
format.setSamples(4);
gl->setFormat(format);
setViewport(gl);

That works pretty well on all platforms and improves the performances, 
except on iOS (tested on iOS 14), where it is exactly the opposite: all 
become very very slow even in not complicated situations.


Is there something we can do to about that?

I know openGL is deprecated on iOS (replaced by Metal) does Qt supports 
that?


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

[Interest] cmake build issues

[Nibedit Dey]

Hello Everyone,

I am following the below steps to build Qt 6.0.3 from the source. However,
it fails in CMake build step with multiple header file inclusion issues. I
tried it on both macOS and Linux. I faced similar issues.

   - $ tar xvf qt-everywhere-src-6.0.3.tar.xz
   - $ cd qt-everywhere-src-6.0.3
   - $ ./configure
   - $ cmake --build . --parallel

CMake log only mentions missing header files. Is there anything I am
missing?
A sample error:
Desktop/qt6/qt-everywhere-src-6.0.3/CMakeFiles/CMakeTmp/src.cxx:9:8: error:
use of undeclared identifier 'posix_fallocate'
(void) posix_fallocate(0, 0, 0);
   ^
1 error generated.
make[1]: *** [CMakeFiles/cmTC_39cfa.dir/src.cxx.o] Error 1
make: *** [cmTC_39cfa/fast] Error 2

Source file was:
#include 
#include 
int main(int argc, char **argv)
{
(void)argc; (void)argv;
/* BEGIN TEST: */
(void) posix_fallocate(0, 0, 0);
/* END TEST: */
return 0;
}

make: *** [all] Error 2

Any help will be appreciated. Thanks in advance.

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

[Interest] Future of Qt Location (mapping solutions) in Qt 6

[Ola Røer Thorsen]

Hi all,

just wanted to bring some attention to the fact that it is still unclear if
the Qt Location module (which gives plotting of geographical maps) will be
included in Qt 6 at all.

For our use-case it's a complete show-stopper if it disappears (especially
using the mapbox-gl plugin) and we would be stuck with Qt 5.15 until we
find some other way to proceed. How widespread is the actual use of this
module? It brings a lot of value for us for sure (commercial product). I've
brought this up with commercial support, but I guess it would be
interesting to hear what the open source side thinks too.

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

[Interest] Force Qt Quick application to use Nvidia chip rather then Intel chip (Windows)

[Nuno Santos]

Hi,

I’m working on a application that requires intensive usage of graphics card.

While running it in Windows I have found through task manager that the GPU 
being used is the Intel and not the Nvidia.

How can we tell the application to use the Nvidia chip instead of the Intel 
chip?

Thanks!

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

[Interest] Empty QML ListView after filtering QSortFilterProxyModel

[Roman Wüger]

Hello all,

I use the setFilterRole(), setFilterFixedString() function and so on. The 
application is a QML application where the business logic is written in C++.

After setting the filter, I run in a for loop over the Model and Print the 
items for debugging purpose, which works fine.

The problem now is, that when the filter is applied, the QML listview gets 
empty. Before applying the filter, I see the items as they should.

Have anyone some hints why the listview isn‘t showing anything after filtering?

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

[Interest] Empty QML ListView after filtering QSortFilterProxyModel

[Roman Wüger]

Hello all,

I use the setFilterRole(), setFilterFixedString() function and so on. The 
application is a QML application where the business logic is written in C++.

After setting the filter, I run in a for loop over the Model and Print the 
items for debugging purpose, which works fine.

The problem now is, that when the filter is applied, the QML listview gets 
empty. Before applying the filter, I see the items as they should.

Have anyone some hints why the listview isn‘t showing anything after filtering?

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

Re: [Interest] Are Qt.transparent and "transparent" different colors?

[Tor Arne Vestbø]

> On 27 Mar 2021, at 14:40, Giuseppe D'Angelo via Interest 
>  wrote:
> 
> On 27/03/2021 11:58, Alexander Dyagilev wrote:
>> Hmmm... What is this enum for then?
> 
> In C++ APIs, it's used in QColor's constructor.
> 
> In QML, enumeration types are strange beasts (and I wish they weren't), 
> sometimes being enum and sometimes being integers. I suggest to open a bug 
> report suggesting to add a Qt::Color -> color type construction (assuming 
> it's possible), because it's indeed supposed to "just work". (On the other 
> hand, clearly, int->color should never work.)

Yes, please file a bug about this.


Cheers,
Tor Arne

> 
> 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
> 
> ___
> 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] QML Image size vs sourceSize strange things

[Tor Arne Vestbø]

The icons provided from the system also go through a similar process of 
choosing the right size for what you request. If you request something specific 
by setting the sourceSize you will affect this, so please just set 
widht/heigth, as that should work. (If it doesn’t please file a bug with a 
small test case, thanks!)

Cheers,
Tor Arne

On 27 Mar 2021, at 08:57, Alexander Dyagilev 
mailto:alervd...@gmail.com>> wrote:


OK, thank you. We do use SVGs (but sometimes also PNGs).

However, these PNGs I was talking about in the original posting are files icons 
from system. I can't replace them with SVGs. :)


On 3/27/2021 9:51 AM, Nuno Santos wrote:
I had the same problem with blurry images on retina displays. I ended up 
creating a image component that inside was by default setting source size for 
twice the width and height of the item size to have good results on iOS screens.

However..

I have recently found that replacing the pngs for svgs has accelerated the UI 
loading time from seconds to a snap!!!

I have found this because I was not finding acceptable the time it took to 
resize a window.

I had to replace years of pngs into svgs but in the end it payed off.

You should definitely consider moving to svgs.

Best,

--
Nuno Santos

No dia 27/03/2021, às 03:17, Alexander Dyagilev 
 escreveu:



This all is not about my question in any matter. I do not care about SVG at 
all. And SVG are not used in this example.

Please learn to read question before answering

On 3/23/2021 4:16 PM, Jérôme Godbout wrote:
Do you really need to same memory by reducing the source size? I think you 
should left the source size alone and sample the image from the full source. 
Source size for SVG doesn’t make any sense, it’s vectoriel, doesn’t have any 
size, it can scale to any dimension. When playing with the image size (not the 
source) it will sample the source for each pixel, not sure about the algorithm 
but you might need an higher source resolution to get a proper image without 
artifact. I would at least take the Screen.devicePixelRatio into the source 
size into account and even add a x2 to ensure proper sampling, but I don’t see 
any real advantage to play with the source size unless you really are consuming 
way too much memory.

This might slow you down if the same image is using different sourceSize:

Note: Changing this property dynamically causes the image source to be 
reloaded, potentially even from the network, if it is not in the disk cache.


On Mar 23, 2021, at 3:31 AM, Alexander Dyagilev 
mailto:alervd...@gmail.com>> wrote:


Hello,

We had a strange problem with blurred images under Retina displays. Left part 
of the image - before, right one - after the fix.



Our QML code was using with to show images:

Image {

anchors.verticalCenter: parent.verticalCenter

sourceSize.width: 25

sourceSize.height: 25

source: preview.url

}



I've tried to multiply sourceSize by Screen.devicePixelRatio - images became 
bigger so they did not fit their places.

Then I've replaced sourceSize.width with just width and the same for height. 
And it works fine now.

My questions is:

1) Is it required to multiply sourceSize by devicePixelRatio? Or is it managed 
automatically? It seems that it is managed automatically for PNG and NOT 
managed for SVG.

2) If it is already managed automatically for PNG (these images preview.url are 
PNGs) then why was it blurred? The original PNG image is of size 64x64 pixels 
under Retina displays.

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

Jerome Godbout
Software/Firmare Lead Amotus

C: (581) 777-0050
O: (418) 800-1073 ext.: 114
godbo...@amotus.ca




dimonoff.com   |amotus.ca

We have moved!
1015 Avenue Wilfrid-Pelletier, Québec, QC G1W 0C4, 4e étage

___
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] Qt 5.6 Qt labs controls porting to QtQuick2 controls

[Mitch Curtis]

> -Original Message-
> From: Interest  On Behalf Of Ramakanth
> Kesireddy
> Sent: Thursday, 1 April 2021 3:10 AM
> To: Qt Interest 
> Subject: [Interest] Qt 5.6 Qt labs controls porting to QtQuick2 controls
> 
> Hi,
> 
> As we used Qt 5.6 Qt labs controls 1.0 in our Qml application and would like 
> to
> port to QtQuick2 controls in Qt 5.15, could you please let me know if there is
> a Qt documentation to port the labs controls to QtQuick2 controls and
> compatibility or known issues if any?
> 
> Please suggest in this regard.
> 
> Best Regards,
> Ramakanth
> 

We have porting documentation for Qt Quick Controls 1 to 2, but not from Labs 
Controls to Qt Quick Controls 2.

The closest thing would be to check the change log for each minor version up to 
the version you want to use:

https://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/dist

The "Important Behavior Changes" section is the most relevant here.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Simplest way of dynamically updating a texture to be displayed on a shader material

[Nuno Santos]

Hi,

I have a material that is painting a texture. The texture was created with 
window()->createTextureFromImage

Let’s say that now I want to update that image at 60 frames per second. This 
might not be a very efficient way of doing it.


What would be the simplest way of creating a texture which will constantly be 
updated and painted via QSGMaterialShader

I’ve seen that there is a private QSGVideoNode_* that basically paints a video 
frame using a texture that is updated whenever a new frame arrives.

Would this be the best example (and the most performant way) for what I am 
trying to achieve?

Thanks!

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

Re: [Interest] QtQuick over Qt3D (Qt 5.15)

[Paul Lemire via Interest]

Hello Konstantin,

On 4/3/21 3:09 AM, Konstantin Shegunov wrote:
On Thu, Apr 1, 2021 at 8:40 AM Paul Lemire > wrote:


Hello Paul,

Hello,

It sounds to me like Scene2D is what you want as it renders a
QtQuick scene into an offscreen texture which can then be applied
to a Qt 3D mesh. Unfortunately it can only be used from QML.

That being said, nothing is stopping you from having 90% of the
Qt3D code in C++ and just having a small part in QML that
essentially only instantiates your 3D Scene and the Scene2D and
povides the 3D scene with the Scene2D texture. I think that would
be the easiest.

Yes, that's what I've been using to "guide me through". And I do 
acknowledge I can use it from QML, but there's also this thing: 
https://bugreports.qt.io/browse/QTBUG-90411 

Ok we will need to take a look at that. Shouldn't be too hard to fix but 
not sure how we can fixes to 5.15 publicly. Qt 3D from dev branch (Qt 6) 
does build with 5.15 though but I'm not sure we had ported Scene2D to Qt 
6 due to other changes in QtQuick.


If you want to do it purely in C++, another approach (but more
complex to set up and that would have to be tested) is to use a
QSharedGLTexture to tell Qt3D about an existing OpenGL texture by
textureId. This means using the Qt shared OpenGL context, and
manually rolling your own QQuickRenderControl to render QtQuick
into a QOpenGLTexture, and then providing the QOpenGLTexture's id
to the QSharedGLTexture. You'll also need to ensure proper
synching using fences (QWaitFence/QSetFence) to ensure that Qt3D
is not trying to render while the the shared texture is being
updated. This would be more or less similar to one of the manual
test we have in Qt3D
https://code.qt.io/cgit/qt/qt3d.git/tree/tests/manual/sharedtexture?h=5.15.2



I hope that helps,

Indeed, thanks! Still, it doesn't seem there's a way I can hook into 
the frame graph and just have anything drawn directly on the screen, 
is there? The best I could do, as far as I can tell, is to have an 
ortographic camera looking at a quad, which I can texture with 
whatever comes from the QtQuick scene, it appears (i.e. what Florian 
Blume's code does here: 
https://github.com/florianblume/Qt3D-BackgroundImage 
). Is this correct?


Yes you will need to have a fullscreen quad mesh to draw the texture + 
matching FrameGraph part to draw only the quad  after the content of 
your 3D scene.


Many ways of doing the same thing: using the QPlaneMesh with a rotation 
+ camera or providing a custom plane mesh already in NDC space (-1  to 
1) in which case you don't even need to worry about having a camera.




On Thu, Apr 1, 2021 at 11:15 AM Oleg Evseev > wrote:


By the way in Qt 5.14 there comes an option to use Scene3D as
underlay without FBO:
https://doc.qt.io/qt-5/qml-qtquick-scene3d-scene3d.html#compositingMode-prop



I did tried this, but encountered with a problem when using
together with OnDemand:
https://bugreports.qt.io/browse/QTBUG-82861



Indeed. It does seem bugs reports've accumulated for Qt3D over time. 
View3D also segfaults (the example) for some reason.


Kind regards,
Konstantin.



--
Paul Lemire | paul.lem...@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.fr
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] QML: Strange "binding loop detected" message

[Alexander Dyagilev]

OK, I've just refactoring it in this way and the problem is solved now. 
It's sad that it's impossible to use self-variable in the binding 
without getting boring warnings...


propertyintspeedColumnHoveredWidth:0

onCurrentTimeChanged:updateSpeedColumnHoveredWidth()

onDownloadsViewSpeedColumnHoveredChanged:updateSpeedColumnHoveredWidth()

onDownloadsViewSpeedColumnHoveredWidthChanged:updateSpeedColumnHoveredWidth()

onDownloadsViewSpeedColumnNotHoveredSinceTimeChanged:updateSpeedColumnHoveredWidth()

functionupdateSpeedColumnHoveredWidth()

{

//keephoveredwidthatmaxrecentvalue+3secondsafterleavinghoveredstate

varw=downloadsViewSpeedColumnHovered?

Math.max(d.speedColumnHoveredWidth,downloadsViewSpeedColumnHoveredWidth):

(d.currentTime-downloadsViewSpeedColumnNotHoveredSinceTime<3000)?d.speedColumnHoveredWidth:

0;

if(w!=d.speedColumnHoveredWidth)

d.speedColumnHoveredWidth=w;

}

On 4/2/2021 8:53 AM, Alexander Dyagilev wrote:


Hello,

I have a table. I change one column's size when user hovers it. Each 
row in this column can require different "hovered" width. And I would 
like it to return back in 3 seconds after mouse pointer left it.


So, I use this:

property bool viewSpeedColumnHovered: false
property int  viewSpeedColumnHoveredWidth: 0
property double viewSpeedColumnNotHoveredSinceTime: 0

These properties are set outside of my control and the question is not 
about them.


To achieve the above I use this property:

//keephoveredwidthatmaxrecentvalue+3secondsafterleavinghoveredstate
property int speedColumnHoveredWidth: downloadsViewSpeedColumnHovered ?
Math.max(speedColumnHoveredWidth, viewSpeedColumnHoveredWidth) :
  (currentTime - 
viewSpeedColumnNotHoveredSinceTime < 3000) ? speedColumnHoveredWidth :

  0

When I hover the column first time - all is OK. But after 3 seconds 
has passed, it returns to 0. My column became normal again. Then I 
hover it again and get this strange message:


QML ViewHeaderColumnsWidthCalc: Binding loop detected for property 
"speedColumnHoveredWidth"


I can't understand how can this be... If Math.max returns the property 
itself (speedColumnHoveredWidth), then it should not generate 
"changed" signal (property remains the same).


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

Re: [Interest] the path forward

[Benjamin TERRIER]

On Thu, 1 Apr 2021 at 18:56, Jason H  wrote:

> I've called Qt "top secret rockstar tech" multiple times and I plan on
> calling it that for a bit more. I've had 5 companies buy licenses since
> 2005.  Qt has delivered on getting my products to market in record time,
> even if that was a process frought with far more native code than it should
> have been. At the very least having a cross-platform UI saved some effort,
> and provided consistency, rather than having to target Android's stacks AND
> AVFoundation seperately.
>
> What I don't like is the erosion of the LGPL that Nokia set in place. I
> think it's shortsighted, and contributes to the decline of Qt overall. I
> feel that while Qt stock has done well, volume is thin, and something as
> technical as having BSD or LGPL could be beneficial for the volume. Qt is a
> project of declining hobbiest popularity, even when there are big companies
> buying into it. Compare it with say, ReactJS/Electron. Everyone knows about
> that, Qt not so much... Maybe the big player interest will circle back
> around as it comes up on job postings... I'd personally launch a head on
> WebGL offensive if I could I think there's a lot of untapped potential
> there!
>
> Also, I think Qt should be on a US stock market, but I am biased. ;-)
> There's some pink sheets version of Qt stock which is even thinner volume.
>

I am completely in phase with Jason.

Qt is a very good piece of technology, for many reasons.
Being a cross-platform UI framework is just the tip of the iceberg. It has
a great documentation, API are consistent and clear (isEmpty() vs empty())
and it covers far more than just UI: it has networks, filesystem, serial
port, webengine, etc.

And I also dislike the erosion of the LGPL and the Open-Source Qt offering.
For the past years, I've seen the popularity of Qt decline: I see less and
less Qt job offers and it is harder and harder to get Qt developers.
For me, this is one of many symptoms that Qt, as an open-source project, is
declining. I am not talking about quality here. I am talking about
visibility, user base, governance, etc.

For the visibility, well it's quite easy to spot. For example,
qt-project.org is just a redirect to https://www.qt.io/developers and from
there you need to go through 6 different pages before being offering the
link to get the download installer

https://www.qt.io/developers
https://doc.qt.io/qt-5/gettingstarted.html
https://www.qt.io/download
https://www.qt.io/download-open-source
https://www.qt.io/download-qt-installer

And of course https://www.qt.io/download-open-source has 4 pages of content
trying to steer the user toward a commercial license before seeing the
button to continue.
And then you still have to create an account and login during the install
process.
Of course this web page labyrinth to download the installer is changing
every couple of months.
I've never seen an open-source project trying this hard to hide itself.

It's such a pain to get Qt through the Qt website that for the past 5+
years I just go to download.qt.io and browse the directory structure
directly: way more easy and convenient.

The decline of the user base is mostly based on my point of view, but there
are other people on this mailing list who draw the same conclusion.
And it is only logical to have less and less users, when you switch from
LGPLv2 to LGPLv3, do not release new modules under LGPL, force Qt account
login (while having said that you understood why it's a bad idea a couple
of years earlier), stop updating Qt 5.15 when Qt 6 is barely usable, ...

For the governance. Well I might not be fully aware of everything. I try to
follow the mailing lists, but I don't read everything so I might have
missed something.
When I started to work with Qt 10+ years ago, I spent time learning about
the Open Governance model.
My feeling is that the Qt Project does not follow the open governance model
anymore. It seems to me that the Qt Company is making more and more one
sided decisions.
The mailing list is just the place where the Qt Company announces the
decisions that were already taken.
I know that TQC is the 1st contributor to Qt and provides hardware and
infrastructure support, which make its voice stronger.
But how come the TQC can single handedly decide that the Qt Project won't
support Qt 5 while Qt 6 gets actually usable?

I mean either TQC does support the Qt Project and it should support the
decision made by the Qt Project. That's what the Open Governance implies
(at least it's my understanding).
And if that's the case the decision to stop 5.15 support should have been
made in public.

Or TQC does not support the Qt Project. TQC only supports Commercial Qt.
In which case the support provided to the Qt Project is just a side effect
of TQC needing to support its commercial version of Qt, i.e. the Qt Project
only gets the crumbs TQC is willing to let go.

My feeling is that in 10 years Qt transitioned from the 1st case to the
later.
Maybe I am 

[Interest] QML: Strange "binding loop detected" message

[Alexander Dyagilev]

Hello,

I have a table. I change one column's size when user hovers it. Each row 
in this column can require different "hovered" width. And I would like 
it to return back in 3 seconds after mouse pointer left it.


So, I use this:

property bool viewSpeedColumnHovered: false
property int  viewSpeedColumnHoveredWidth: 0
property double viewSpeedColumnNotHoveredSinceTime: 0

These properties are set outside of my control and the question is not 
about them.


To achieve the above I use this property:

//keephoveredwidthatmaxrecentvalue+3secondsafterleavinghoveredstate
property int speedColumnHoveredWidth: downloadsViewSpeedColumnHovered ?
Math.max(speedColumnHoveredWidth, viewSpeedColumnHoveredWidth) :
  (currentTime - 
viewSpeedColumnNotHoveredSinceTime < 3000) ? speedColumnHoveredWidth :

  0

When I hover the column first time - all is OK. But after 3 seconds has 
passed, it returns to 0. My column became normal again. Then I hover it 
again and get this strange message:


QML ViewHeaderColumnsWidthCalc: Binding loop detected for property 
"speedColumnHoveredWidth"


I can't understand how can this be... If Math.max returns the property 
itself (speedColumnHoveredWidth), then it should not generate "changed" 
signal (property remains the same).


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

Re: [Interest] Interest Digest, Vol 114, Issue 38

[Thiago Macieira]

On Thursday, 1 April 2021 07:50:31 PDT Scott Bloom wrote:
> That doesn’t mean that Qt cant support it, its that Qt needs to be able to
> compile without it.  And if you cant, rev the major version

As explained, that's not the driver for major version number. We rev the major 
number only and exclusively for binary and source compatibility breaks. This 
policy will not change.

We also need to drop compatibility with things that are too ancient and thus 
are hampering further progress in other areas, making them economically and 
practically unfeasible to support. Roland is asking we don't, but it's simply 
not an option for the Open Source project. So we have two choices:

1) do it within a major series
2) do source- and binary-compatibility breaks more often

I see you are asking for #2. But as I mentioned before, it appears to be only 
a convenience of numbering. Meanwhile, doing source- and binary-compatibility 
breaks has huge implications for the entire ecosystem, so doing it more often 
means the ecosystem will be harmed. It's not a choice we can make.

And as a nefarious side-effect to what you're asking, allowing source-
compatibility breaks more often (say 3.5 instead of 7 years) means you get 
more of them over a fixed period of time, which means that an 8- to 15-year 
support project would need to go over not one or two, but two to four major 
API changes.

So, I hear you, but I don't agree that what you're asking is the best choice.

-- 
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] the path forward (or is it "how the things look"?)

[Rui Oliveira]

I'm going to vent my perspective as a non-professional programmer who 
just wants to do GUI on a cross platform hobby project and is relatively 
new to Qt.


So, to start. ReactJS/Electron. Yes, everybody is doing it because I 
guess the ratio of frontend devs to C++ programmers is 100:1.


Now, do they replace C++? No. For example, in my application, I kinda 
need some number crunching (FFT) in the backend, so I'm not going to do JS.


Honestly, if it wasn't for that, I'd probably be using C# and one of the 
newer cool libraries: Avalonia.UI, Platform.Uno, and the upcoming .NET 
MAUI. Man, it's incredible how the x-platform C# space has been growing 
compared to C++!!! And like, Avalonia.UI is based on SKIA, which is a 
C++ library!! But it's being used on C# instead... Makes you think. Why 
is the C++ GUI ecosystem like it is? DearImgui is probably the newest 
thing which is worth a damn, but I don't particularly enjoy how it looks.


I want to develop a desktop application. And I feel very frustrated: 
Widgets seem to be in life support, QML for the desktop is honestly 
severely underdeveloped. It reaches the hilarious point that QtQC1 had 
native styling but QtQC2 didn't until now!?! (and still they are... 
meh). Not to mention the native stuff in the Labs platform is just 
half-done (no native right click menu on Windows...). I don't want to 
start a project on a half-dead (be honest) platform, but I don't want to 
start a project on a half-baked technology either. And I bet most of you 
will have examples to why I'm wrong, but I'm saying things from what I 
can see.


Then, on the licensing shenanigans: I find it funny that for example "Qt 
Quick MultiEffect" is a GPL/commercial only tech. I feel this should 
have just been a QML engine fix? But that would be LGPL, and I guess 
that's not interesting anymore...


I've seen a couple times here and there people asking for help with 
stuff like Qt Gamepad, and I tell them to forget about it and just use 
SDL instead. Another tech that's not deprecated, but not going anywhere 
either.


Then, there's the aspect of mobile, which I honestly don't care, but I 
really feel that the mentioned C# libraries, JS, and Flutter will be far 
more popular than C++/QML will ever be. And following the Qt JIRA, 
sometimes I wonder how I would develop for Android with it. It really 
feel a bit... Messy...


Anyhow, about the licensing model. The Qt Co. must make money, we get 
it. And the "make it free-as-in-beer and then sell support isn't for 
everybody", I get it. But let me just bring something to the table: have 
you looked at how game engines are licensing recently? Putting fees over 
sales instead of developer seats. That solves the problem of "buying 
just before launch" and makes the general community happy. Even 
commercial software companies know that getting college students 
"addicted" to a certain tech is a good way to make them ask their 
employer to use it. Honestly, I think the whole "pay to develop" model 
is so dead now... Pay for support, and pay a cut on sales over X amount 
seems to be working very well for the game engine market. And honestly, 
as a hobbyist, I think that a model in the lines of "free for hobbyist 
and free for the first X dolars in revenue (cough Unity cough)" keeps 
both the community happy and gives a fair benefit/obligation balance to 
commercial customers. Maybe that would work with Qt, maybe not. I'm just 
saying.


Sorry for the ramble, and I'll probably remember more things to say, an 
maybe I didn't express myself with the best polish, but that's my 2 cents.


Anyhow, thanks for the project, and I really mean it. The Qt APIs are 
top notch, the docs the same (even though the QML-related docs is 
clearly subpar compared with the legacy C++ stuff).


Rui


Em 01/04/2021 17:56, Jason H escreveu:
I've called Qt "top secret rockstar tech" multiple times and I plan on 
calling it that for a bit more. I've had 5 companies buy licenses 
since 2005.  Qt has delivered on getting my products to market in 
record time, even if that was a process frought with far more native 
code than it should have been. At the very least having a 
cross-platform UI saved some effort, and provided consistency, rather 
than having to target Android's stacks AND AVFoundation seperately.
What I don't like is the erosion of the LGPL that Nokia set in place. 
I think it's shortsighted, and contributes to the decline of Qt 
overall. I feel that while Qt stock has done well, volume is thin, and 
something as technical as having BSD or LGPL could be beneficial for 
the volume. Qt is a project of declining hobbiest popularity, even 
when there are big companies buying into it. Compare it with say, 
ReactJS/Electron. Everyone knows about that, Qt not so much... Maybe 
the big player interest will circle back around as it comes up on job 
postings... I'd personally launch a head on WebGL offensive if I could 
I think there's a lot of untapped potential there!