Thanks for the instructions. I was able to create a working Qt integration. It was way easier than I fought. I had opened !46 to upstream it.
Oh, that's an interesting one. I had assumed the D-Bus integrations in Qt & GTK would be good enough that no-one would really want to use Jeepney in a GUI context.
😆
I've never tried GTK but the Qt one is really bad. It gives you almost no Control about the types you send. It work well for simple types, but if you do something more complex e.g. a(sssida{sv}) then good luck. There is also almost no documentation for Python.
This PR adds a Qt integration as explained in #36 to Jeepney.
To-Do:
JakobDev (c621b6f9) at 16 Oct 17:18
Add Qt integration
Please take a look at the following example code:
import jeepney.io.blocking
import jeepney
def main() -> None:
address = jeepney.DBusAddress(
bus_name="org.freedesktop.DBus",
object_path="org/freedesktop/DBus",
interface="org.freedesktop.DBus",
)
conn = jeepney.io.blocking.open_dbus_connection()
req = jeepney.new_method_call(address, "ListNames", "", ())
conn.send_and_get_reply(req)
if __name__ == "__main__":
main()If you run this code, it will crash with ConnectionResetError: [Errno 104] Connection reset by peer. The reason for that is simple: The object_path is missing a slash at the start. But instead of communicating that to the User, jeepney just shows a random error. I faced this problem in a bigger problem and thought jeepney had a bug. Took a while to realize the problem was on my side. jeepny should throw a that clearly state what the problem is.
Maybe each package could have it's own user-site in ./var/app/<appid>?
JakobDev (8f3f86d6) at 14 Nov 15:58
Fix syntax
See #1671
JakobDev (eedff97d) at 14 Nov 14:17
Add PYTHONNOUSERSITE environment variable
JakobDev (980a2033) at 14 Nov 14:14
Runtimes can set env vars. Se we could set PYTHONNOUSERSITE=1 on runtime level.I don't know where the finish-args are set here, so i can't make a patch.
That's not a good solution. Not everyone knows about this problem. This can cause bugs that are hard to reproduce by developers e.g. You get a bug report, but this bug is caused by older version of a lib which was loaded from user home. I think Python should be configured by default to don't load packages from user home.
See the following output which shows the problem:
$ flatpak run --command=python --filesystem=host:ro org.freedesktop.Platform//23.08
Python 3.11.5 (main, Nov 10 2011, 15:00:00) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib/python311.zip', '/usr/lib/python3.11', '/usr/lib/python3.11/lib-dynload', '/home/jakob/.local/lib/python3.11/site-packages', '/app/lib/python3.11/site-packages', '/usr/lib/python3.11/site-packages']
>>> As you can see, ~/.local/lib/python3.11/site-packages is before /app/lib/python3.11/site-packages in sys.path when the Flatpak has access to it. sys.path is the order, in which Python tries to import packages.
If a Flatpak comes with the Python package foo, but the User has also installed foo on his local System, Python will try to import foo from the local System and not from the Flatpak. This can result in broken Applications, as the version of foo from the local System might not be compatible with the version in the Flatpak.
I can't find gamemode in the runtime
While working on a 6.5 branch for QtWebEngine I got this error: QtWebEngine will not be built: Unmodified ffmpeg >= 5.0 is not supported.. I searched for the reason for this and found this commit. It explains that Chromium needs AVSTream, which is no longer part of ffmpeg 5.0, but some distros patch it in.
There are many Flatpak Apps that uses Chromium. The commit message explains that Chromium needs AVStream, so all Flatpak Apps which use Chromium (mostly through a WebView) are affected. SO I think it makes sense to ship this Patch with the Freedesktop Runtime instead of letting every App that uses a WebView ship a custom ffmpeg version.