Developer Announcement - Qt 5.15 available for app developer testing

Applications
#41

I got some problem with dbus. Is there a fix for this?

$ sfdk tools target exec SailfishOS-4.5.0.18-aarch64 ssu ur
DBus unavailable, falling back to libssu

… and later when deploying on device

$ sfdk deploy --sdk
sending incremental file list
sample-sfos-qqc2-1.0-1.aarch64.rpm

sent 17,483 bytes received 35 bytes 7,007.20 bytes/sec
total size is 17,359 speedup is 0.99
QObject::connect: No such signal QDBusAbstractInterface::installFinished(bool,QString)
QObject::connect: No such signal QDBusAbstractInterface::needConfirm()
Installing sample-sfos-qqc2-1.0-1.aarch64.rpm
Failed to request file installation: “Not connected to D-Bus server”
Connection to 192.168.0.190 closed.
Deploy failed

#42

That looks like generic SDK issue, not related to qt515. Maybe there is a report regarding it at forum already?

1 Like
#43

There were several issues.
When comes to %make_build script it looks like an absolute/relative path issue while creating Makefile. I can build PROJECT if I directly use in spec file an absolute path to PROJECT directory:

%qtc_qmake5 \
 /home/USER/SailfishOSProjects/PROJECT

Second, INSTALLS section in .pro file is required for qt515 macro scripts:

# Default rules for deployment.
target.path = /usr/bin
desktop.path  = /usr/share/applications
desktop.files = *.desktop

icons.path    = /usr/share/icons/hicolor/86x86/apps/
icons.files   = sample-sfos-qqc2.png

qml.path    = /usr/share/$$TARGET/
qml.files   = qml/

INSTALLS += target desktop icons qml

not to mention about:

Messages from sb2:
(WARNING)	qmake[22639/1870329664]	Path not found for FD 4, for __fxstatat64()
... a lot
 (WARNING)	qmake[22639/1870329664]	Path not found for FD 3, for __fxstatat64()
# exit 0 (0)

after build.

#44

Kirigami 2 v 5.104 is now also available in chum. We wont package any other kf5 libraries just yet, but will do it on a as-required basis, so, if anyone wants/needs a kf5 tier1 library, mention it here.

3 Likes
#45

Re required libs: please also consider packaging them yourself and add to Chum repos (Github and OBS). That way the effort can scale and we will be able to cover more

1 Like
#46

New Qt is allowing us to experiment further. I have compiled Chromium using their cross-compilation instructions and was able to run it from SFOS. In short, it cannot be used yet as a browser due to the absence of keyboard.

This build runs on SFOS directly, without any extra container approaches (Flatpak or Containers). Only requirement is that it need newer compositor. So, I used Qt Wayland example compositor or newcompositor by @artur.

Current status and what was done is written down at GitHub - rinigus/pkg-chromium

7 Likes
#47

Hmm. That get’s us a lot closer to porting apps like Utilities / KTrip · GitLab In a sense, it could make A number of things I work on obsolete. Combined with kpublictransport it could replace Fahrplan. But then, maybe I’ll join the dark side and @cypherpunks and just scrape ALL the public data and dump it into Multimodal :slight_smile:

2 Likes
#48

Update on QtWebEngine: I managed to compile it on a phone and it worked without problems. So, looks like our SDK is somehow leading to faulty library that fails on some pages. Opened corresponding issue: SB2 leads to faulty QtWebengine compilation

Not sure where to go from here. For interested devs: Please look at the issue above and think about solutions. Ideally, let’s keep SDK discussion under that issue.

7 Likes
#49

Compiled on the phone? Holy moly, HOW?? It takes almost two days to compile on my laptop! (Old one yes but still…)

1 Like
#50

How: With a lot of patience (induced by running out of other options). Required make -j1 and adding swap file to get over some jumbo builds. Together with phone crashes (tried to use make -j2), took about 30h

10 Likes
#51

The current state of public transport here almost makes me consider joining the dark side of my own and start developing a Tesla app. :grin:

1 Like
#52

Oh wow! That’s beyond dedication!

I wonder if there’s a Sailfish-capable single-board device with more muscle that could be used for “on-device” compiling…

1 Like
#53

I have this waiting in a box for pretty much that use case (among others).
Now if anyone could make a pi image with SFOS SDK :wink:

(Also it’s almost impossible to source CM4 modules…)

2 Likes
#54

I am trying to solve it by docker-aarch64 image and compiling with that. Work in progress: GitHub - rinigus/docker-sailfishos-builder

3 Likes
#55

The first big package using this is now in Chum, Noson, the Sonos controller. Not much use to people without a Sonos speaker system, but for those who do, this is working quite well. Its a good looking and featureful QQC2 based application. See The Demise of Noson (Sonos controller) on SFOS - #14 by piggz

6 Likes
#56

Qt WebEngine is packaged and available in Chum testing. Will promote it to Chum proper if the tests will be fine. To make it possible, new build environment (Docker based build environment: simulating native builds) was used.

With WebEngine packaged, we plan to add Angelfish soon as well.

12 Likes
#57

I am excited about this. So much good things happened in such short time. Thanks!

#58

What is Angelfish? A quick search bring up an analytics thing?

#59

Plasma/KDE web browser from plasma mobile

2 Likes
#60

Oh, how very cool. You guys are really stealing the wind out of our collective sails! Yipee!