Ah… it might have something to do with the fact that the engine (and context, 
etc.) are destroyed in the meantime, and callLater being called from QML. The 
QML team would know more about that. So I guess you have to stick to delaying 
the call in C++.

From: Interest <interest-boun...@qt-project.org> on behalf of randomslap--- via 
Interest <interest@qt-project.org>
Date: Wednesday, 15 June 2022 at 18:04
To: Interest <interest@qt-project.org>
Subject: Re: [Interest] QML Runtime Style Change
  Thank you Mitch! But about the latter, I tried it out by basically 1. getting 
rid of styleChange, 2. writing the line of code you mentioned but calling 
doStyleChange and 3. making doStyleChange Q_INVOKABLE.

  At first the window opens, I also change the style once but on the second try 
it produces a segmentation fault (core dumped). Maybe I need to change more 
code. I also tried adding engine->exit(0); before deleting. The difference is 
that now it will produce the fault on the first try to change style.

    Perhaps I should consider not using this program's concept. It's pretty 
faulty and may not work on whole environment. Thanks for the advice, again.

Jun 15, 2022, 06:04 by mitch.cur...@qt.io:
> 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-boun...@qt-project.org> on behalf of randomslap--- via 
Interest <interest@qt-project.org>
Date: Wednesday, 15 June 2022 at 03:09
To: Interest <interest@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.

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

Reply via email to