Perhaps go for non-minimized, and keep that script in a warm place in case enough XA2-forever-people like me really suffer from an app weight and ask one day for a lighter version?
2 Likes
The script is public anyway. I could verify that the --no-minify flag still works, and then I could just switch it from default-off to default-on. Sounds like a plan 
2 Likes
Given that native (QML) apps take quite noticeably longer to start that Android ones do, perhaps the os/installer/app needs to minify all qml once at/post installation on device?
Perhaps a complex app that might benefit from minifying, could be put on chum as two apps: QMLminified and QMLraw, and people could give you an informed opinion?
1 Like
My vote on such questions usually is: make sure the build script is trivially usable from RPM, and that your QML can be included as either a submodule, or a (build-?)dependency. Best of both worlds! On the flip side, it might require take quite some engineering time.
2 Likes
Really doubt there is huge performance difference, being able to audit (and modify if needed) the code on device is a huge plus
2 Likes
I have to admit that I like opal IN PRINCIPLE but one thing that became apparent after taking up development on tidings with the newly integrated opal elements is that is SLOW. When using the SDK it really crawls. AND, of course I freaked out when I couldnāt parse the code.
Of course, tidings is REALLY slow in some parts (which are in progress) but I mean, QML files causing delays when doing compiles is really irritating.
I think it might be worth looking at what could be made more efficient since Iām rather hesitant at the moment to use larger bits.
1 Like
Ok wow, maybe adding opal components to the qml booster is the way then, or having a separate opal-booster (last time I tested it there were noticeable improvements from adding more even silica ones Speed at which Sailfish apps launch - #6 by throwaway69 but a lot changed since then, then again the booster approach is likely to give much more speedup than reducing a read on a qml file by some percentage)
Edit: the boosters are rather small in terms of ram usage (200kb for the browser one?), if it saves a couple of seconds definitely seems like the way, if weāre talking about <0.1s probably not worth the effort, definitely worth retesting couple generations of hw later though
Now Iām stumped. On a faster machine and I cannot even get a c++ compile to finsih!
EDIT: 12th Gen Intel(R) Coreā¢ i9-12900KF 64GB ram. This was the box that my son had as a trophy.
In any case, with this much ram and power, parsing the qml is NOT an issue. On my thinkpad machines (x240ā¦) it was painful.
The problem (as always) is that weāre stuck with Qt 5.6. Moving on to Qt 6 would allow pre-compiled QML etc. which should improve performance a lot (but it would also break Patchmanagerā¦).
Sadly, due to Harbour restrictions, itās not possible to package Opal modules separately from an app. Each module is copied into the app and shipped with it.
In Opalās case, this is kinda already the way it works: the ābuildā script (or rather: release script) just bundles the QML code which can then be added into an app. I tried using submodules and they made packaging complicatedā¦ Hereās how it works: docs
A release bundle is basically the moduleās Opal/MyModule/*.qml stuff (currently minified) plus compiled docs for QtCreator plus a generated āaboutā page entry.
Minification makes this from this source: it strips documentation comments and whitespace, mainly indentation. Stripping docs (which can be added to QtCreator) saves a lot of space (800 lines / 27 KiB in this file).
As itās all plain text QML/JS this is possible even with minification. Itās just not comfortable.
Yeh, sorry about that. I should have included a line of explanation in all minified files. Itās not so obvious when Iām using the modules myself becauseā¦ well, I wrote the code ;).
Can you elaborate on that? I donāt quite understand what youāre referring to, because slow compile times should have nothing to do with QML? Minification etc. is all done when I upload a release bundle, not when an app is compiled.
I wonder if there really is a link because Tidings is only using Opal.About, Opal.LinkHandler, and Opal.SmartScrollbar. The first two are only loaded when opening the about page, and the scrollbar should be quite performant. Where do you see slowdowns?
Ah okay, then thatās not Opal because the modules in Tidings are QML-only.
IIRC Sailjail broke the booster.
On qmake passes, parsing the QML was slower than compiling the c++. This is not the case on the faster machine (which is very fast).
No, opal does not slow down tidings. I meant to say that itās not as if Iāve optimized performance myself.
I did resolve the build issues with tidings. As Iāve said, on my new (well, not new, repurposed) dev machine, the qml parsing is no longer painful. But on a slower machine, it is (ie. if Iām on the road, I will not be working on tidings).
Interesting; I never noticed that but maybe my dev machine is too fast. Or Iām just so used to it because all my apps use Opal that I no longer notice 
This is definitely something to look into. I donāt want Opal to be a bottleneck/resource hog, and I think itās important to support old(er) hardware. When exactly is the SDK parsing QML during build anyway? Or is it the harbour validator?
Minification shouldnāt have an effect on that, howeverā¦
That last machine on which it was painful was a thinkpad W541. I have an X220 and and X240 I could test on to be more explicit. Iām not sure if it may have to do with minification, though I doubt that. In any case, there is a āparsingā step that even on opening a project runs which was awful slow on the W541. At the moment(on newer hardware), itās not an issue.
Ohh the thing for code completion? I donāt know how to influence thatā¦ On my machine only clangd causes problems sometimes, and thatās only for C++.