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
