Could Jolla at one point provide a compiled version of silica on top of this optified Qt version ? As a side by side package to the official system one…
5 Likes
Potentially … a good question for Jolla at a community meeting?
5 Likes
An alternative would be to work on styling Kirigami apps to look like Silica. Or at least similar. That way we can stay with open source components and be compatible with Plasma Mobile
10 Likes
I try to build an app against qt5.15 using latest SFDK and there is something wrong with spec macros and its paths.Using:
%build
%{opt_qmake_qt5}
%make_build
building exits with
+ QTDIR=/opt/qt5
+ /opt/qt5/bin/qmake
Usage: /opt/qt5/bin/qmake [mode] [options] [files]
and I’ve found that it is path issue and when I use
%build
cd ./.sfdk/src
%{opt_qmake_qt5}
%make_build
the app builds in its directory(instead of working) but then fails at %install stage.
What am I missing?
That looks the same as in Add support for out-of-tree mb2 building of the apps · Issue #9 · sailfishos-chum/qt5 · GitHub
No idea what is missing, though
So, I tested running wayland compositor inside qt-runner and … it works. Tested using pure QML compositor shown as an example at qtwayland/examples/wayland/pure-qml at 5.15 · qt/qtwayland · GitHub
As a result, it was possible to run apps inside that nested compositor and it allowed to use newer Wayland protocols. The drawback that I saw was a loss of WebGL in QtWebengine, there could be more. But, in principle, as long as compositor is from Qt - Qt is the one supporting the old protocol - it is possible to get newer compositor protocols supported too.
It is even possible to run Silica apps inside that compositor. Just there are some odd aspects, such as transparent background.
2 Likes
I used the new Qt version to make a compositor (really a simple adaptation of the Qt example qwindow-compositor) that creates a new window for each client window (so that apps can open new windows and can open confirmation dialogues when closed).
I also plan to eventually add Xwayland (rootless) integration so we can have X apps as individual windows in Sailfish OS.
8 Likes
Haven’t yet tested it, but sounds very elegant. For keyboard, I suggest to use the same plugin I am using for qt-runner: GitHub - sailfishos-chum/qt-sfos-maliit-platforminputcontext
But that plugin need DBUS link var that has to be forwarded to the app running in new compositor. It also forward screen orientation to take that into account, probably useful info for the compositor as well.
Alternative would be to use newer Maliit or Qt virt keyboard.
Looking forward to see what comes out of it!
PS: Don’t forget to add LICENSE into the repo 
2 Likes
Sounds good only at hearing it. Lined up to see what comes out!
The Qt packages have been submitted to chum:testing, and are being built for 4.5.0.19. If all goes well, they will go to chum main tomorrow. This is everything except qwebengine, which has some issues to iron out.
6 Likes
Qt packages are now in Chum main, and to help developers more, the sample app has been updated with improvements to install location, how qml files are handled and improvements to the .spec
8 Likes
This is not really a request, but it would be nice to be able to make Android and SFOS apps from the same primarily SFOS base.
It would be nice to have a template (examples) for doing this, and building for Android, if one of you were to find it useful to do. (In the first instance QML/JS apps)
Currently the X10iii is not usable where/when I want to use the apps I want to make (due to power drain and GPS), so until (if ever) I have to use the Android.
This makes it pointless to write for SFOS alone since I can’t use them
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.rpmsent 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
That looks like generic SDK issue, not related to qt515. Maybe there is a report regarding it at forum already?
1 Like
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.
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
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
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
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
2 Likes