You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a keybind set up to launch Xmoji with a hotkey. It would be nice if Xmoji would automatically focus on the search bar when it launches, rather than the "history" tab, so I can just hit my hotkey and then start typing the name of the emoji that I want to use (similar to how gnome-characters or the Windows emoji picker work).
I know part of the charm of this application is that it acts as a seamless virtual keyboard, so maybe this should be gated behind a commandline argument instead of being the default? (Bonus points if this "keyboard mode" allows selecting an emoji with arrow keys + enter, and closes itself after doing inserting the selection, so one can enter an emoji without any mouse input at all.)
The text was updated successfully, but these errors were encountered:
Hi, thanks for your suggestions! A fully keyboard-driven way to use the application certainly makes sense, but then we have to check how to map this to the technology.
First, what I don't want to add is "modes" in a way completely changing the behavior, because I think that's confusing. And the general issue with adding keyboard control at all is that the primary way to enter emojis with Xmoji is by faking keyboard events. This was done to make it work with as many other X11 applications as possible, without the need to rely on specific toolkits (Qt, GTK) and/or "input method" services. The search currently works by obtaining a global keyboard grab only as long as the text input field is active. Following suit to that, keyboard control for selecting an emoji could be added by e.g. a global grab for some hotkey which will then trigger a full keyboard grab until selecting an emoji which will release that grab again (before sending the fake keyboard events).
Regarding the idea to launch Xmoji with some "hotkey", that's already a usecase I have in mind. But my preferred model for that is to keep Xmoji running, so launching it again just brings it "to the front". The reason for that is, Xmoji is pretty lightweight, but needs to do some relevant work on startup to initialize its UI, so keeping it running would be more efficient if you use it from time to time. Part of what's necessary is already implemented ("single instance mode", so the running instance gets notified on attempts to start it again), another part is missing (a "tray icon", so one can avoid consuming space in a taskbar when it's left running) but planned for a v1.0.
My suggestion would be to split this issue into multiple. I don't want to widen the scope for v1.0 further (keyboard control is interesting, but something for after v1.0, as it's certainly a complex thing, see above), but a "quick win" could be adding a commandline flag to directly access the search. This would then select the search tab and clear and focus the search input field, also when Xmoji is already running. Adding that before v1.0 would make sense to me, what do you think?
I have a keybind set up to launch Xmoji with a hotkey. It would be nice if Xmoji would automatically focus on the search bar when it launches, rather than the "history" tab, so I can just hit my hotkey and then start typing the name of the emoji that I want to use (similar to how gnome-characters or the Windows emoji picker work).
I know part of the charm of this application is that it acts as a seamless virtual keyboard, so maybe this should be gated behind a commandline argument instead of being the default? (Bonus points if this "keyboard mode" allows selecting an emoji with arrow keys + enter, and closes itself after doing inserting the selection, so one can enter an emoji without any mouse input at all.)
The text was updated successfully, but these errors were encountered: