Qt Flatpak-Builder guide #127

aleixpol · 2018-05-17T00:05:28Z

Maybe tried to be too non-verbose, please tell me what you'd like to see on it.

aleixpol · 2018-05-17T00:08:16Z

Maybe @eszlari, @grulja or @nedrichards have good ideas on what it should look like beyond this.

TingPing · 2018-05-17T00:26:07Z

docs/qt.rst

+      "runtime-version": "5.9",
+      "sdk": "org.kde.Sdk",
+      "command": "blinken",
+      "finish-args": ["--share=ipc", "--socket=x11", "--socket=wayland" ],


--device=dri?

And --socket=wayland only when tested?

You need --socket=wayland enabled, otherwise users running on Wayland won't be able to run their app as both Plasma and Gnome require Qt Wayland plugin on wayland.

But afaik there are apps that don't support wayland and crash if this enabled.

The --socket=wayland just allows the app to access the wayland socket outside of it's sandbox, it shouldn't make the app crash or force it to use wayland in an X11 environment.

And --socket=wayland only when tested?

For that matter xcb needs testing too. It's not like xcb always works.
Will include a comment about dri.

The --socket=wayland just allows the app to access the wayland socket outside of it's sandbox, it shouldn't make the app crash or force it to use wayland in an X11 environment.

Kdenlive does crash when trying to run it under wayland natively:

$ flatpak run --socket=wayland org.kde.kdenlive QSocketNotifier: Can only be used with threads started with QThread Using Wayland-EGL Using the 'xdg-shell-v6' shell integration trying to load "/usr/lib/plugins/kf5/kio/file.so" from "/usr/lib/plugins/kf5/kio/file.so" Attempting to create QWindow-based QOffscreenSurface outside the gui thread. Expect failures. Attempting to create QWindow-based QOffscreenSurface outside the gui thread. Expect failures. ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects owned by a different thread. Current thread 0x0x2708aa0. Receiver 'QOffscreenSurface' (of type 'QWindow') was created in thread 0x0x4251b30", file kernel/qcoreapplication.cpp, line 576

Then kdenlive needs fixing.

eszlari · 2018-05-17T04:03:29Z

docs/qt.rst

+      "modules": [
+        {
+          "name": "blinken",
+          "buildsystem": "cmake-ninja",


"builddir": true

"-DCMAKE_BUILD_TYPE=Release" or "-DCMAKE_BUILD_TYPE=RelWithDebInfo" ?

"-DCMAKE_INSTALL_LIBDIR=lib" (workaround for flatpak+ECM bug)

This is supposed to be fixed: flatpak/flatpak-builder#93
But projects using extra-cmake-modules still install in /lib64.

The ECM bug is a bug, that only affects projects using ECM. Instead of documenting it I'd rather have it fixed.

flatpak/freedesktop-sdk-base#22

eszlari · 2018-05-17T04:21:38Z

docs/qt.rst

+      "sdk": "org.kde.Sdk",
+      "command": "blinken",
+      "finish-args": ["--share=ipc", "--socket=x11", "--socket=wayland" ],
+


Maybe add a

"cleanup": [ "/lib/cmake", "/share/cmake", "*.cmake" ]

Looks noisy to me, do we really want that on every recipe?

I just thought this to be a hint for people who make their first flatpak app, so they don't forget the cleanup step.

eszlari · 2018-05-17T04:23:02Z

docs/qt.rst

+          "buildsystem": "cmake-ninja",
+          "sources": [
+            {
+              "type": "git",


Better use "type": "archive" as an example? (with "branch": "stable"?)

+1 for archive as an example

How does it make a difference? Documenting sources will be done elsewhere as well, no?

Afaik it's Flathub's policy to prefer archives to git, so this would serve as a good example.

allanday · 2018-05-17T14:01:46Z

Is this guide necessary? Shouldn't it be enough to use the KDE runtime and follow the standard guidelines?

aleixpol · 2018-05-17T14:16:36Z

Is this guide necessary? Shouldn't it be enough to use the KDE runtime and follow the standard guidelines?

I would hope it isn't necessary, I was suggested to create it and thought it probably does make sense so there's something to get started from.

Also it's potentially the right place where to put any possible troubleshooting information we may have.

mhall119 · 2018-05-17T14:21:06Z

It's necessary to answer the developer question "How do I flatpak a Qt/KDE app?". Even if it's a very simple answer, the answer needs to be documented.

It would also be nice to have an example using qmake if that's still common among Qt apps, or whatever has superceded qmake (IIRC there was a new build tool coming)

cpba · 2018-05-21T00:12:33Z

I think this is a good idea.

As silly as it may sound, the fact that the kde runtime packages Qt dependencies may not be immediately obvious to everybody. Windows-centric Qt developers may not be familiar with the kde project.

A new user following standard guidelines may try to use the freedesktop runtime and self-build Qt if this isn't clearly stated.

allanday · 2018-05-21T09:04:24Z

Fair enough - sounds like a good idea to include this.

Second question - is it possible to use the qt demo app as the example?

cpba · 2018-05-21T11:11:51Z

Yes, that'd be even better.

My understanding is that the main guide is to be rewritten using qt-flatpak-demo, would it be fine then if the Qt guide was also the generic one?

aleixpol · 2018-05-22T10:12:26Z

Second question - is it possible to use the qt demo app as the example?

My thinking behind using this application was that it's useful to prove there doesn't need to be changes ad-hoc for flatpak.

Is this the application you want?
https://github.com/flatpak/qt-flatpak-demo

allanday · 2018-05-22T11:17:21Z

The guides branch has been merged into master. It would be great to get the Qt guide merged in there too.

allanday · 2018-05-24T13:54:11Z

It would be good to indicate that you don't have to use the KDE runtime in order to use Qt.

aleixpol · 2018-05-24T13:57:32Z

My understanding is that the main guide is to be rewritten using qt-flatpak-demo, would it be fine then if the Qt guide was also the generic one?

Looking at that demo, doesn't look like a great idea, it has a bunch of dependencies and makes for a worse test case IMHO.

It would be good to indicate that you don't have to use the KDE runtime in order to use Qt.

How do you mean? The org.kde.Sdk is the one that bundles a tested and up to date Qt. One could package it within their application but that's not something I'd document.

allanday · 2018-05-24T14:06:49Z

How do you mean? The org.kde.Sdk is the one that bundles a tested and up to date Qt.

There are apps out there that use Qt in their own particular ways. They might well just want to bundle the libraries that they use. I think we ought to at least indicate that they can do that, if they'd like.

grulja · 2018-05-24T14:55:03Z

@aleixpol ignore all the dependencies in the demo app, they are just for demonstration. @allanday wanted some bundled modules so he can refer to them in the documentation. This [1] is the manifest for the demo app which is actually used.

[1] - https://github.com/flathub/org.flatpak.qtdemo/blob/master/org.flatpak.qtdemo.json

aleixpol · 2018-05-27T22:34:18Z

Are we content with this first version?

eszlari · 2018-05-29T00:18:55Z

Have you thought about using YAML?

cpba · 2018-05-29T00:26:57Z

All the other guides are currently json. It would be best to keep them consistent. I'm not against converting them all to yaml, but the pros and cons should be weighted, and a consensus should be reached before we do anything. El dt., 29 de maig 2018, 02:18, eszlari <notifications@github.com> va escriure:

…

Have you thought about using YAML? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#127 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALLz5DcWprRfbdoQMv3yyGLZD2QzOUIwks5t3JPwgaJpZM4UCN6p> .

aleixpol · 2019-04-03T16:26:50Z

Hi, is there any reason why this never ended up making it in?

mwleeds · 2020-07-01T19:04:22Z

The CI failure looks independent of the changes here. I'll go ahead and merge this.

aleixpol changed the base branch from master to guides May 17, 2018 00:06

TingPing reviewed May 17, 2018

View reviewed changes

eszlari reviewed May 17, 2018

View reviewed changes

aleixpol changed the base branch from guides to master May 22, 2018 16:24

aleixpol force-pushed the guides branch 2 times, most recently from 3d56de3 to 4833334 Compare May 24, 2018 14:05

aleixpol force-pushed the guides branch from 4833334 to 9e7c66d Compare May 24, 2018 15:03

aleixpol and others added 2 commits July 1, 2020 11:43

Add a first version of a guide for Qt-based applications

710f917

qt: Fix a few issues

deceeb1

mwleeds force-pushed the guides branch from 9e7c66d to deceeb1 Compare July 1, 2020 19:00

mwleeds merged commit c64f0a3 into flatpak:master Jul 1, 2020

Qt Flatpak-Builder guide #127

Qt Flatpak-Builder guide #127

Conversation

aleixpol commented May 17, 2018

aleixpol commented May 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aleixpol May 24, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eszlari May 17, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

allanday commented May 17, 2018

aleixpol commented May 17, 2018

mhall119 commented May 17, 2018

cpba commented May 21, 2018

allanday commented May 21, 2018

cpba commented May 21, 2018

aleixpol commented May 22, 2018

allanday commented May 22, 2018

allanday commented May 24, 2018

aleixpol commented May 24, 2018

allanday commented May 24, 2018

grulja commented May 24, 2018

aleixpol commented May 27, 2018

eszlari commented May 29, 2018

cpba commented May 29, 2018 via email

aleixpol commented Apr 3, 2019

mwleeds commented Jul 1, 2020

aleixpol May 24, 2018 •

edited

eszlari May 17, 2018 •

edited