[Interest] QML Runtime Style Change

EXT Mitch Curtis mitch.curtis at qt.io
Wed Jun 15 05:04:25 CEST 2022


> The program will not maintain the same position between window re-appearances.

If by position you mean window position, you can use Settings to store it:

https://doc.qt.io/qt-6/qml-qt-labs-settings-settings.html#details

> I'd also like to ask, is there any way to get rid of the "special"  class function used only to invoke the other function? It really sounds like something that can be improved.

If you mean the invokable that does a queued invoke of doStyleChange, you could probably shift it to QML instead:

    onClicked: Qt.callLater(function() { App.styleChange(text); })

So you could merge doStyleChange into styleChange, but you still need the queued call.

From: Interest <interest-bounces at qt-project.org> on behalf of randomslap--- via Interest <interest at qt-project.org>
Date: Wednesday, 15 June 2022 at 03:09
To: Interest <interest at qt-project.org>
Subject: [Interest] QML Runtime Style Change
Hello again

    IMPORTANT: This mail is an UPDATE to the "Change QML Application Style on Runtime" mails.

I should also note I run on GNOME Wayland sessions.

    I finally managed to create a stupidly small application which is able to change to a whole different style only by renewing the QML engines. I send an image that shows all the code used as well as the app running and a compressed file containing all relevant files.

-> What was the problem:
    Indeed there a was a need for a queued connection as it was suggested but that wasn't causing the warning at that time. It was rather the engine probably causing weird reactions. The solution was to simply change the engine to a pointer and delete and re-new every time I want to change the app's style. Also, the .close() function was causing a Wayland protocol fatal error but when I removed '()' it didn't complain. The engine.exit(0); might also not be necessary.

-> Important notes:
    The program will not maintain the same position between window re-appearances. Items that are not bound by C++ data won't also maintain their states between re-appearances either.

    I just hope I can still reach a point to implement my idea even in a compositor and solve the above problems. I also hope memory is not leaking but I did not catch any related processes on my system monitor ( maybe I missed something ).

    I'd also like to ask, is there any way to get rid of the "special"  class function used only to invoke the other function? It really sounds like something that can be improved.

Thank you for helping me. I'd appreciate any ideas to improve this "concept" if possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220615/2e9fe75a/attachment.htm>


More information about the Interest mailing list