Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyboard-centric input mode #18

Open
axiopaladin opened this issue Nov 20, 2024 · 1 comment
Open

Keyboard-centric input mode #18

axiopaladin opened this issue Nov 20, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@axiopaladin
Copy link

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.)

@Zirias Zirias added the enhancement New feature or request label Nov 22, 2024
@Zirias Zirias changed the title [Feature Request] Keyboard-centric input mode Keyboard-centric input mode Nov 22, 2024
@Zirias Zirias self-assigned this Nov 22, 2024
@Zirias
Copy link
Owner

Zirias commented Nov 22, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants