Future request

[link0802]

Thank you for this great indicator! Want request some features:

• [ ] Create "main program window" with all emoji. Something like this:
• [ ] Hotkeys for fast open search window/main window.
• [ ] Emoji multi select in main program window.

[gentakojima]

Thank you for taking your time to add this issue and share your thoughts. This should be definitely the way to go.

The project originally started as a quick hack to get emojis in some way better than copy-pasting from a website, using a code I already hacked for some other project as a base.

Since I'm already using glade to build a search dialog at this time, this won't be much more difficult to do, and it's definitely better.

I've been documenting myself on how to do this and I'll probably start working on it very soon. At least these two:

• A main program window, very similar to the one you are showing.
• Configurable hotkey to open that main window.

I'm still unsure about what are you referring to as "Emoji multi select". Can you provide some example?

Also, it would be great to be able to paste the chosen emoji automatically on the target (or avoid the copy-paste mechanism completely) but I'm still unsure on how to do this. I don't want to rely on ibus, but maybe there is no other way?

We better leave this opened for now so other people can see it too.

[link0802]

I think os x emoji picker style will be even cooler

About multiselect: I don't know is it necessary (in design like os x it not). But if no clean way to paste emoji on the target - it will be cool feature. Just checkboxes near emoji to copy few of them at once. Something like this:

I will write if find some way to automatically paste without rely on ibus :)

Update: oops, my bad. In img need to be "Selected 4 emoji". But, I guess, idea is clear :wink: .

[gentakojima]

OS X emoji picker lacks search feature, but it's very similar, just some differences in styling. I'll try to do my best. If you have any more suggestions, you're welcome to share them. 👍

I don't find that particular multi-select solution very much (too bloated and probably difficult to make in glade), but I know what you're saying. If the window closes after searching for an emoji, it's very painful to get back there again.

Maybe the window shouldn't close after choosing an emoji, but we should need to find a way to manage the pasting of emojis in the target and then closing the window when we are done.

[gentakojima]

I found python-xdo that might solve some of these problems. So the plan so far is:

• Create a full featured picker window with categories and search as you type.
• Picker window should stay opened until [x] button is pressed with the mouse or the [ESC] key is pressed on the keyboard.
• Settings dialog should be accesible from within the emoji picker window.
• If the picker window is opened standalone, the emoji should be pasted on the clipboard as we've been doing until now.
• On configurable hotkey press, the window should open at mouse cursor position with a different behaviour: When an emoji is picked, the window should lose focus (so the focus would return to the previous window) and then using python-xdo we can simulate a keystroke with the correct unicode code(s). We don't even need the clipboard anymore. Then, grab the focus again as quick as possible.
  • Getting the current text cursor position might be more difficult and hackish so we can leave this for a later stage.
• Picker window should be forced to stay on top of other windows when opened via hotkey so it doesn't flicks too much when it loses focus.
  • Still need a way to tell this to the window manager but shouldn't take too much work

[link0802]

Such great plan. It will be best emoji picker in any os history :+1:

[gentakojima]

Thank you for your kind words. I've started working on this now, but it will probably take some more days to get the basics working. Still didn't commit anything to github. I'll continue updating the next days as I advance on this.

[benwaffle]

Can you use a GtkPopover and point it at the indicator?

[gentakojima]

Using a GtkPopover is a very interesting option in any case. The main problem is that I'm currently using 14.04 that is lacking the required GTK+3 version. I don't know what version started including these windows, but I've checked it and mine doesn't.

Maybe I can try using GtkPopover and fallback to other type of window. I'll check it later (thanks!).

Now I'm actually stuck, because:

• it seems the python-xdo included with Ubuntu 14.04 is an undocumented barely working implementation
• there is no Ubuntu package for the other -more complete- python-libxdo
• I don't know how to lose the focus on the window properly without flickering. Methods such as set_focus(None) don't work on windows. I can minimize it, close it, hide it, but I don't know how to lose focus.
• even If I ignore this problem and try to use python-libxdo or python-xdo, it seems like running this from the Gtk thread is not working as I thought. I'm trying to figure out what is happening.

I'll keep working on this when I have time, and if I can't get this to work I'll upload it to another tree to see if anyone can help.

[Elmapul]

future request or feature request? since you're copying things for clipboard, what about copy custom things and create an shortcut key for then? ex: ability to create an shortcut for this: 😀 or for other things such as this ¯(ツ)/¯

[HarmtH]

For what it's worth, I've fixed this in a hacky way for myself and uploaded it too https://github.com/HarmtH/emojione-picker-ubuntu

If you use Compiz, you need to add class=Emojione-picker to the Focus Prevention Windows in CCSM, otherwise the search window will not get the focus after the hotkey is pressed.

[gentakojima]

I'm stuck right now with this approach. I have an implementation, but it's seriously hackish and some applications (such as Firefox) reject the input, so It's not working.

I have to take some time to look at your code, @HarmtH, thanks! For now, I've just removed the unused imports.

[HarmtH]

I'm using another approach again, also because it wasn't always working correctly, will try to upload it sometime soon.

You now have to set a custom hotkeys in gnome hotkeys to communicate with a server instance of the program. That method seems to work correctly. On 12 Jun 2016 20:11, "Jorge Suárez de Lis" notifications@github.com wrote:

I'm stuck right now with this approach. I have an implementation, but it's seriously hackish and some applications (such as Firefox) reject the input, so It's not working.

I have to take some time to look at your code, @HarmtH https://github.com/HarmtH, thanks! For now, I've just removed the unused imports.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gentakojima/emojione-picker-ubuntu/issues/8#issuecomment-225451685, or mute the thread https://github.com/notifications/unsubscribe/ACTm4mv3P2XrHH0l81Drrkh8vhmJe0Gtks5qLEu_gaJpZM4Hnsbp .

[apjyotirmay]

I'm a big fan of this software, and use it on a daily basis on my Xubuntu machine. I have been thinking the same thing about making the search dialogue appear with a hotkey. I lack necessary programming skills to help you with this development, but I've had some ideas, which might be of any use to the ones working on this project. So I was thinking about, maybe there can be an instance running in the background, and the user can assign a hotkey(or a keyboard shortcut) to run the program(and since a background instance will be running, it shouldn't take much time to answer that keyboard call). For beginning, you can just give the user that search box to look for emojis. Even copying to clipboard shouldn't be a bad thing. As all that it takes is just "ctrl+v" to paste the emoji, and an user can paste multiple copies of them by just copying it once. And with a window, this thing can be made cross-desktop easily, as you won't be needing to handle different types of panel and all. For the future development, I was thinking of building an appimage too, as it will make using it on other distro pretty smooth and hassle-free.

[probonopd]

For the future development, I was thinking of building an appimage too, as it will make using it on other distro pretty smooth and hassle-free.

Should be fairly straightforward to convert the existing deb into an AppImage. See the AppImageKit wiki.

[apjyotirmay]

Should be fairly straightforward to convert the existing deb into an AppImage. See the AppImageKit wiki.

I was trying to do that, but couldn't really find proper documentation for that. Like the steps weren't clear, not even on the official page

[probonopd]

There are different ways to generate an AppImage of your application; in this case I recommend to use one of the following:

1. Convert existing binary packages. This option might be the easiest if you already have up-to-date packages in place, ideally a ppa for trusty or earlier or a debian repository for oldstable. In this case, you can write a small .yml file and in many cases are done with the package to AppImage conversion. See examples OR
2. Bundle your Travis CI builds as AppImages. This option might be the easiest if you already have continuous builds on Travis CI in place. In this case, you can write a small scriptfile and in many cases are done with the AppImage generation. See examples OR

Please let me know if you run into difficulties.

[apjyotirmay]

There are different ways to generate an AppImage of your application; in this case I recommend to use one of the following:

1. Convert existing binary packages. This option might be the easiest if you already have up-to-date packages in place, ideally a ppa for trusty or earlier or a debian repository for oldstable. In this case, you can write a small .yml file and in many cases are ...

@probonopd thanks, I will be giving it a try whenever I get time to do that, and will let you know about the progress about it too.