briefcase: [GNU/Linux] [Possible solution] Gtk emoji picker doesn't work on AppImage but works on dev mode

Following the hello world example from: https://docs.beeware.org/en/latest/tutorial/tutorial-1.html If you right click the text input widget and select “Insert Emoji”, the AppImage version crashes. In dev mode you get gtk emoji picker, as expected. The crash log on the terminal is the following (I had to translate some parts to English):

[GTK+] Not implemented: Widget.set_hidden()
[GTK+] Not implemented: Widget.set_hidden()
[GTK+] Not implemented: TextInput.set_font()
[GTK+] Not implemented: TextInput.set_font()
[GTK+] Not implemented: Widget.set_hidden()
[GTK+] Not implemented: TextInput.set_font()
[GTK+] Not implemented: TextInput.set_alignment()
[GTK+] Not implemented: TextInput.set_font()
[GTK+] Not implemented: TextInput.set_font()
[GTK+] Not implemented: Widget.set_hidden()
[GTK+] Not implemented: Widget.set_hidden()
[GTK+] Not implemented: Button.set_background_color()

(__main__.py:13824): Gtk-WARNING **: 12:19:22.975: Could not load a pixbuf from icon theme.                                                                                       
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /home/user/.icons/elementary-xfce/status/16/image-missing.svg: [TRANSLATED] Can't load the image loading module [\TRANSLATED]: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /usr/lib/x86_64-linux-gnu/librsvg-2.so.2: undefined symbol: cairo_tag_end (gdk-pixbuf-error-quark, 5)
/tmp/.mount_Hello_4a1FKE/AppRun, linha 7: 13824 Abortado                $APPDIR/usr/bin/python3 -s -m helloworld

Debian 10 (buster) amd64; Python3.7; Everything beeware was installed with pip on a virtual env.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (6 by maintainers)

Most upvoted comments

Your understanding about AppImage ld_path is correct - except that the build process includes discovering all the libraries that are needed, and copying them (and modifying them) so the app is self contained. The app shouldn’t ever be looking outside the image itself, except for libraries like libc.

As I said - there should not be a need to back port anything. If the app runs on an actual 16.04 machine, it should run on any linux with a same-version-or-newer libc - and in the recent past, this was true. However, we’ve also made some recent changes to the way we invoke the AppImage build that might be affecting things. Running a build with Briefcase 0.3.2 should have the “old” packaging behavior, which was known to work.

freakboy3742 on Aug 26, 2020