QML-only app: benefits of libsailfishapp vs. sailfish-qml

[nephros]

For apps implemented in pure QML, are there any benefits of adding a minimal c++ file and compiling it against libsailfishapp?

As opposed to not doing that and just launching it through the sailfish-qml launcher?

The second way has the benefit (for me) of being able to build RPMs noarch, and testing them through qmlscene, both of which make developing/testing/tuning on the device much easier.

[cypherpunks]

I’m using sailfish-qml for my apps precisely because it allows me to develop on the SFOS device itself. Not having to rely on a giant SDK is also a big plus.

[martyone]

@nephros

The second way has the benefit (for me) of being able to build RPMs noarch , and testing them through qmlscene , both of which make developing/testing/tuning on the device much easier.

Check Enable receiving updates with Qt QmlLive under Projects > Run Settings inside the IDE and enjoy previewing changes on device just by saving the file under the IDE - no need to re-build/deploy/start. Works with pure QML apps as well as apps based on libsailfishapp, including apps with QMLs bundled in compiled-in resources (qrc).

Find more details in “Using QmlLive with Sailfish OS Devices” in the Help inside the IDE and this tutorial QML Live Coding With Qt QmlLive | Sailfish OS Documentation.

[nephros]

Thanks for the tip.

I don’t use the SDK (as I’m swiching computers all the time, not all of which support having the SDK installed,) or even QtCreator most of the time, instead opting for a vim → git → docker/obs build → install RPM workflow. This way all I need on my local machine is a ssh client and sometimes a web browser.

[flypig]

@nephros

are there any benefits of adding a minimal c++ file and compiling it against libsailfishapp ?

From the source code, this is pretty much all that sailfish-qml is doing. But just some random thoughts on benefits/drawbacks I’ve experienced personally with apps:

1. QML-only apps are likely to be more future-proof than apps with a complied launcher. The fact they’re noarch as you already pointed out, and that Jolla takes the responsibility for updating sailfish-qml if needed (not that this seems to have been needed much) are examples of why this might be the case.
2. Sometimes it can be convenient to experiment on the C++ side before moving over to QML. For example I find it easier to debug DBus stuff in C++, even if it ends up in QML. So having a C++ wrapper available can make this kind of experimentation during development easier.
3. I find it easier to handle versioning with a C++ launcher, because the version numbers can live in one place (the spec file) and cascade through the app.

There are obviously some cases where C++ may be necessary (e.g. using non-Qt libs) but since you explicitly state the apps can be implemented in pure QML, these wouldn’t apply.

[poetaster]

The only reason some of my QML only apps still have C++ involved is that they have localstorage, for instance, which I needed to be able to migrate for stuff like the Sailjail changes to organization, etc.

Some apps I just ‘inherited’ with libsailfishapp and am looking to move to noarch, pure QML.

[nephros]

@flypig

There are obviously some cases where C++ may be necessary (e.g. using non-Qt libs) but since you explicitly state the apps can be implemented in pure QML, these wouldn’t apply.

There’s also cases where using c++ would be arguably smarter

I have this one app where I – brace yourselves – do gunzip/deflate in Javascript (which involves a byte-per-byte-copy while doing a char-to-byte conversion, twice…).

[poetaster]

Wow. Cool. That’s a hack and hacks are good! I probably would have been a wimp and done it in python