Minor Improvements

[slightlyfaulty]

First off, great job on this Emoji picker 🚀. With a bit of setting up it's by far the best one I've been able to find for Linux.

That being said, it would be great to see some minor improvements:

1. Application Icon - At the moment it's just using a default Xorg icon.

   

2. In the documentation you advise using xdotool key to print the emoji to the current window. However, I ran into a lot of trouble with xdotool key "holding down" the key for too long and outputting multiple emojis. Though undoubtedly an xdotool bug and not a jome bug, I found that simply doing jome -c 'xdotool type' works much better and achieves the same result as jome -f cp -p U -c 'xdotool key --delay 20' without any of the repeating key issues.

3. The last issue I had was with emojis not being sent to the window properly without adding a long delay to the command. This seems to be due to the jome window not closing quickly enough sometimes and reverting focus to the previously active window. My solution is to instead use a set of shell scripts to explicitly focus the previous window.

   jome-show.sh
   
   #!/bin/sh
   jome -c "jome-print.sh $(xdotool getactivewindow)"

   jome-print.sh
   
   #!/bin/sh
   xdotool windowfocus $1
   xdotool type $2

   This can of course be adapted for server mode too.

4. I'm not sure if it's even possible, but it would be super cool if there was a way to print multiple emojis to a window without needing to re-open jome each time.

Anyway, thanks again for making jome and keep up the good work!

[eepp]

First off, great job on this Emoji picker . With a bit of setting up it's by far the best one I've been able to find for Linux.

Thank you so much for this feedback, I really appreciate this. I didn't promote jome anywhere, but I might do it once I get enough feedback to know it works fine for other users than me.

That being said, it would be great to see some minor improvements:

1. Application Icon - At the moment it's just using a default Xorg icon.

Sure.

2. In the documentation you advise using xdotool key to print the emoji to the current window. However, I ran into a lot of trouble with xdotool key "holding down" the key for too long and outputting multiple emojis. Though undoubtedly an xdotool bug and not a jome bug, I found that simply doing jome -c 'xdotool type' works much better and achieves the same result as jome -f cp -p U -c 'xdotool key --delay 20' without any of the repeating key issues.

Good. I'll look into that and update README.adoc if it works fine.

3. The last issue I had was with emojis not being sent to the window properly without adding a long delay to the command. This seems to be due to the jome window not closing quickly enough sometimes and reverting focus to the previously active window. My solution is to instead use a set of shell scripts to explicitly focus the previous window.

   jome-show.sh
   
   #!/bin/sh
   jome -c "jome-print.sh $(xdotool getactivewindow)"

   jome-print.sh
   
   #!/bin/sh
   xdotool windowfocus $1
   xdotool type $2

   This can of course be adapted for server mode too.

That's great. I'll add this trick to README.adoc.

4. I'm not sure if it's even possible, but it would be super cool if there was a way to print multiple emojis to a window without needing to re-open jome each time.

What kind of UX do you have in mind?

Anyway, thanks again for making jome and keep up the good work!

[slightlyfaulty]

What kind of UX do you have in mind?

Maybe something like having a CLI option that makes the jome window not close after selecting an emoji. Instead it will just execute the -c command, which will allow using xdotool to print the emoji to the previous window after each selection.

[eepp]

Maybe something like having a CLI option that makes the jome window not close after selecting an emoji. Instead it will just execute the -c command, which will allow using xdotool to print the emoji to the previous window after each selection.

Done. Please try it (new -q option).

[slightlyfaulty]

Nice. Seems to be working perfectly so far.

Is there a reason -q can't be used in server mode though?

Also looks like there's a typo in the error message for this. It says "cannot specify -s and -k options together."

[eepp]

Nice. Seems to be working perfectly so far.

Is there a reason -q can't be used in server mode though?

When you accept an emoji in server mode:

1. jome hides its window.
2. jome sends a reply (what it prints to the standard output) to the waiting client (jome-ctl).
3. jome-ctl prints what it received and quits.

This is so that you can use jome-ctl to make the jome window visible, block until the user accepts an emoji, and then use the output of jome-ctl.

I don't know how -q would work with the current design. If step 1. does not happen, then jome-ctl still quits after printing. The connection is lost. If you accept another emoji, there's no connected jome-ctl to send the reply to.

I guess in server mode with -q, jome could accumulate emojis or codepoints, and then when you close the window, reply to jome-ctl with the concatenated accepted emojis. Then jome-ctl would print all of them at once. What do you think?

Also looks like there's a typo in the error message for this. It says "cannot specify -s and -k options together."

Fixed, thanks.

[slightlyfaulty]

Hmm. I see what you mean. I would try to suggest alternative workarounds but I'm afraid my coding knowledge in this area is not quite there.

I'm not sure about having it accumulate emojis. This seems a bit unintuitive for the end user, or it would require some kind of UI to properly indicate which emojis have been selected.

Anyway I'm happy to use jome as is. Thanks for the quick feature adding! 🥳

[eepp]

Closing this as most of it was done.

Might open another enhancement issue later for the -q and -s modes together.