Opening the emoji picker window takes ~2 seconds

[balazsorban44]

Hi, thank you for your work on this!

I just installed Emote on my Ubuntu 21.10 laptop (so Wayland if relevant), and it looks great!

My one concern is when opening Emote either by my shortcut or from the terminal with the emote command, it takes about 2 seconds until the window opens.

The README.md suggests:

Emote runs in the background and automatically starts when you log in.

So is this expected? Is there any limitation that makes this open so slow? Can this be related to my computer? I have a fairly high-end developer-focused Dell XPS.

The only log I can provide immediately is when opening from the terminal:

(emote:12717): dbind-WARNING **: 11:04:32.457: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-aQHT5tmbfL: No such file or directory

(emote:12717): Gtk-WARNING **: 11:04:32.689: Theme parsing error: gtk.css:1427:23: 'font-feature-settings' is not a valid property name

(emote:12717): Gtk-WARNING **: 11:04:32.692: Theme parsing error: gtk.css:3317:25: 'font-feature-settings' is not a valid property name

(emote:12717): Gtk-WARNING **: 11:04:32.693: Theme parsing error: gtk.css:3779:23: 'font-feature-settings' is not a valid property name

I am happy to provide more information if needed. 🙂

This might be low-priority, and if there is nothing to do/there is an upstream blockage, feel free to close this issue.

[tom-james-watson]

Yeah this is far slower on Wayland, unfortunately. On X11, we register a listener in the app for a global shortcut which we can react to very quickly. On Wayland, you are basically starting a fresh instance of the program which unfortunately introduces a noticeable delay. Slow things in the chain:

• Starting a snap program
• Python
• My code somewhere?

I don't have any good ideas for how best to fix this. If I were to start this project again I would probably have used Flatpak and Rust GTK or maybe Tauri.

The wayland hotkey issue along with being unable to auto-paste the emoji into the previous app on selection makes the app substantially worse on wayland, which is a shame. It would be nice if people could share any ideas for how to fix or work around those issues.

[balazsorban44]

I appreciate your answer and I understand. I, unfortunately, am only a user here and have little to add, but hopefully, someone coming after me will be able to give some advice.

[balazsorban44]

Getting back to this, I was wondering if it was possible to instead of closing the program on selection or Esc, we could send it to the system tray instead? Wouldn't that keep it alive then?

Coming from https://github.com/maoschanz/emoji-selector-for-gnome which lives on the system tray and implements Super+e and works instantly.: https://github.com/maoschanz/emoji-selector-for-gnome/blob/c3ebe0d13d2f16326be80b3c2d636f2d9db8a9b8/emoji-selector%40maestroschan.fr/prefs.js#L98

Take this with a grain of salt, as I mostly don't know what I'm talking about, I don't develop for Linux. 😅 I was thinking to share, it might help.

[cmalard]

I'm no more helpfull here, but Guake manages that by providing another command to run: guake-toggle
Maybe it could be a workaround? :-)
-> https://github.com/Guake/guake/blob/master/docs/source/user/faq.rst

[ccoenen]

Getting back to this, I was wondering if it was possible to instead of closing the program on selection or Esc, we could send it to the system tray instead? Wouldn't that keep it alive then?

It should be possible to keep a process running with or without a dock icon / systray-like thing. And I believe this is the only real way to go around the slow startup time.

If you can, maybe take a look at things like KeePassXC, this is a program I have set to autostart in the background on system start. And when I then use a shortcut, it can come to the foreground very quickly. KeePassXC is made in a way that only opens one instance, regardless of how often you execute the program; a second run of the binary will detect it and just open the window of the existing process.

[birgersp]

I cloned and built Emote, and then for some reason the hotkey to open it seem to actually open my locally built version. Perhaps building and running Emote has (partially) overwritten the snap install or something.

Doing the hotkey (for me CTRL+ALT+E) opens emote instantly for me now.

Opening Emote from the Linux Mint menu is still slow but I don't care. The hotkey's what's important for me 😍

Not a issue "fix", but at least a workaround for those annoyed by the slow startup.

[Noxmiles]

Getting back to this, I was wondering if it was possible to instead of closing the program on selection or Esc, we could send it to the system tray instead? Wouldn't that keep it alive then?

It should be possible to keep a process running with or without a dock icon / systray-like thing. And I believe this is the only real way to go around the slow startup time.

Yes, I had an other emoji picker - which is not supported anymore - which was starting with the boot and opened a window instantly. This should be also possible for emote.

But it would require the program being running in the background, only showing the GUI when the shortkeys are pressed.

[tom-james-watson]

That is already how it works, to be clear - it runs as a daemon which starts on launch and only shows the gui when the shortcut is pressed. On X11 the window will open in a couple of hundred of ms. The problem is that on Wayland you can't register a global shortcut in the same way. The only way that I know of to get around this is to have the user manually create a shortcut which creates a second instance of the app. The first instance can detect when this second instance is launched and show the GUI, with the second instance silently closing. Unfortunately this is slow due to what I outlined here.

The only improvement I can think of is creating some kind of secondary program like emote-toggle which is capable of starting up faster than the existing emote binary. Unfortunately wayland kind of breaks Emote in multiple ways 😞.

[stephan-dev]

@tom-james-watson

register a listener in the app for a global shortcut which we can react to very quickly.

Even on X11, this seems to be broken when we change (from Emote GUI) the main shortcut to launch emote. This 2 to 4 seconds delay appears in X11, and worse, one can get completely locked out. #87

[tom-james-watson]

We've just released version 4.0.0 which adds support for flatpak. You might have more look on Wayland if you use the flatpak instead. Note that you will need to update your custom shortcut's command to flatpak run com.tomjwatson.Emote (see https://github.com/tom-james-watson/Emote/wiki/Hotkey-In-Wayland).

Would love some feedback on what your guys' experience with the new version is 🙏.

[banan314]

I'm thinking it would be faster if I knew the way to create a deb or install if from sources, but it doesn't compile and I don't know how to package on Debian so I can do neither

[banan314]

and it's slow on both snap and flatpak on X11 in case anyone wondering