tom-james-watson / Emote

Emoji Picker for Linux written in GTK3
https://snapcraft.io/emote
GNU General Public License v3.0
651 stars 36 forks source link

Flatpak Version Fails to Open due to Python Type Error #117

Closed 266-750Balloons closed 1 year ago

266-750Balloons commented 1 year ago

I have installed Emote via Flatpak. When I attempt to start it, the process immediately exits. When executing flatpak run com.tomjwatson.Emote, I get the following error: Launching emote daemon ERROR:dbus.connection:Unable to set arguments ('', {'reason': 'Emote autostart', 'autostart': True, 'background': True, 'commandline': dbus.Array(['emote'], signature=None)}) according to signature None: <class 'TypeError'>: Expected a string or unicode object Traceback (most recent call last): File "/app/share/emote/emote/__init__.py", line 117, in do_activate self.start_daemon() File "/app/share/emote/emote/__init__.py", line 44, in start_daemon self.flatpak_autostart() File "/app/share/emote/emote/__init__.py", line 55, in flatpak_autostart res = inter.RequestBackground('', { File "/app/lib/python3.10/site-packages/dbus/proxies.py", line 72, in __call__ return self._proxy_method(*args, **keywords) File "/app/lib/python3.10/site-packages/dbus/proxies.py", line 141, in __call__ return self._connection.call_blocking(self._named_service, File "/app/lib/python3.10/site-packages/dbus/connection.py", line 643, in call_blocking message.append(signature=signature, *args) TypeError: Expected a string or unicode object

System Specs: Distro: Debian 13 Trixie (Testing) Arch: x86_64 Desktop: XFCE 4.18 WM: Xfwm4 Flatpak Version: 1.14.4

Thank you for your time.

tom-james-watson commented 1 year ago

Not sure what's going on there, but we can at minimum put error handling around that call.

vemonet commented 1 year ago

It seems to come from flatpak autostart: https://github.com/tom-james-watson/Emote/blob/a6abad4193ac00aa4b2fe8c96659fc2491dc18a9/emote/__init__.py#L55

The error message is TypeError: Expected a string or unicode object At the top of the trace we can see more details:

Unable to set arguments ('', {
  'reason': 'Emote autostart', 'autostart': True, 'background': True, 
  'commandline': dbus.Array(['emote'], signature=None)})
  according to signature None: <class 'TypeError'>: Expected a string or unicode object

Could be something related to the signature being None? I checked at other usage of dbus RequestBackground(e.g. https://github.com/rafatosta/zapzap/blob/be35e2c8020d6e8adbbe7be15accb75193c8ebf0/zapzap/services/portal_desktop.py#L25, https://github.com/mijorus/whisper/blob/bd27154d504842e65b0b9d6d980fd0442b98af58/src/Preferences.py#L54, https://github.com/rafatosta/zapzap/blob/be35e2c8020d6e8adbbe7be15accb75193c8ebf0/zapzap/services/portal_desktop.py#L25) and it seems like no one provides a signature to the constructor (as we do)

There is a similar error message that was resolved by simply rebooting the laptop: https://github.com/getsenic/nuimo-linux-python/issues/29

Regarding our error message, maybe something happened and your machine is not able to generate the signature for the dbus call

Do you still get the error after rebooting @266-750Balloons ?

dcermak commented 1 year ago

I see the same error on Fedora 38 running i3:

❯ flatpak run com.tomjwatson.Emote 
Launching emote daemon
ERROR:dbus.connection:Unable to set arguments ('', {'reason': 'Emote autostart', 'autostart': True, 'background': True, 'commandline': dbus.Array(['emote'], signature=None)}) according to signature None: <class 'TypeError'>: Expected a string or unicode object
Traceback (most recent call last):
  File "/app/share/emote/emote/__init__.py", line 117, in do_activate
    self.start_daemon()
  File "/app/share/emote/emote/__init__.py", line 44, in start_daemon
    self.flatpak_autostart()
  File "/app/share/emote/emote/__init__.py", line 55, in flatpak_autostart
    res = inter.RequestBackground('', {
  File "/app/lib/python3.10/site-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
  File "/app/lib/python3.10/site-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/app/lib/python3.10/site-packages/dbus/connection.py", line 643, in call_blocking
    message.append(signature=signature, *args)
TypeError: Expected a string or unicode object
266-750Balloons commented 1 year ago

As an answer, I still get it after rebooting.

vemonet commented 1 year ago

There is originally a clear and standard way to enable autostart of an app on linux: moving the desktop file to ~/.config/autostart. And that is what was implemented originally, and it was working like a charm.

But we were recommended by flatpak devs to use this shady, poorly documented and visibly highly unstable "XDG portal APIs", so now we need to fix their own issues, not cool 🤷🏽

266-750Balloons commented 1 year ago

I think I've found our culprit after monkeying around for a few hours with several VMs with various distros and looking around in D-Spy. Apparently, the XDG portal backend is supposed to create the org.freedesktop.portal.Background interface. With xdg-desktop-portal-gnome, this happens correctly, and the Flatpak opens just fine. However, with xdg-desktop-portal-gtk backend, it does NOT create this interface. I've submitted a bug report at flatpak/xdg-desktop-portal-gtk#434. Hopefully, it gets fixed soon and everything will work properly. For now, you can install xdg-desktop-portal-gnome, which, obnoxiously enough, basically installs all of Gnome Debian, so I'll be holding off for now. Since the issue is NOT in any Emote code, should I close this, or should we implement the old way for now until the API gets fixed?

tom-james-watson commented 1 year ago

Thanks for looking into that. It sounds like this is an upstream bug. For the reasons in https://github.com/tom-james-watson/Emote/pull/120, I don't think we can go back to the autostart file method, unfortunately.

We need a simple change that just puts some error handling around this at least. That means autostart won't work for some people I guess, but that's not the end of the world.

smurphster commented 1 year ago

Hello... I'm seeing the same issue in Kali. Are there any other work-arounds besides installing xdg-desktop-portal-gnome?

tom-james-watson commented 1 year ago

I've added a workaround, though it means that autostart won't work in those cases, but at least the app will run!