no output to target window

[fluffynuts]

Hi

This may not actually be an issue with x11-emoji-picker, but I don't know how else to look for help:

I'm using the 0.8.0 app image release, which was working when I first upgraded. I hadn't used the picker in a while, but today, launching it, no matter what emoji I pick or what my originally focused window is, no output appears there (tried on a terminal, in firefox - both places this used to work)

Now, since the software hasn't changed, I'm wondering if there's any well-known reason why this might be the case? Or any ideas for debugging why this is happening?

OS: Gentoo Linux App version: 0.8.0 App release: AppImage

[GaZaTu]

mhh thats odd 🤔

can you run it from the cli and try to input an emoji? maybe there is some error logging.

additionally: does activating the target window still work, if you have that input method enabled?

[fluffynuts]

yeah, I can run from the cli - no error logging, unless there's something I need to do to make the app more chatty, like an environment variable or cli arg? I can still activate the target window, yes. When I do so, x11-emoji-picker stays where it was - to dismiss it, I need to click on the text entry and press Escape

[GaZaTu]

I think i'll have to build a new release which does contain a way to create some logging first.

For the record, what desktop environment / window manager are you using?

While it shouldn't change anything, what if you try out the .gcc6.AppImage under releases?

And if all else fails i could have you beta test the new https://github.com/GaZaTu/x11-emoji-picker/tree/feature/dbus-daemon branch 😏

[fluffynuts]

I think i'll have to build a new release which does contain a way to create some logging first.

That would be excellent (: or I can try work along with the source - it's been a while since I worked in C/CPP, but I'm sure I can get back into the swing of things, though I'd appreciate help with ideas on potentially what's going on

For the record, what desktop environment / window manager are you using?

KDE plasma, kwin, all on Gentoo plasma-desktop 5.2.5-r1 kwin 5.21.5

While it shouldn't change anything, what if you try out the .gcc6.AppImage under releases?

Yeah, no change - runs fine, still no output in my console window. This used to work, and, as stated earlier, I don't think it's a failure in your app, but perhaps other people are experiencing this too. However, I do see this output:

XGetWindowProperty[_NET_WM_DESKTOP] failed (code=1)

And if all else fails i could have you beta test the new https://github.com/GaZaTu/x11-emoji-picker/tree/feature/dbus-daemon branch

I cloned, checked out, built - same results when running emoji-picker, but the dbus part of that branch name suggests that there's probably another way to invoke this?

Just thinking about it - I recently (a few days ago) totally nuked my KDE settings, let it generate from new again, because I was struggling with something, I think because I got 2 new monitors where I had 1 before. So my setup now is actually closer to stock standard than it was before. I'm not all that sure what's different though :thinking: but now my BT headphones, for instance, automatically connect (yay for me) and my monitors are behaving as expected, so I had some really old cruft in there - probably 7 or 8 years old, transferred from an Ubuntu home dir to this Gentoo box when I first built about 4 years ago.

[GaZaTu]

I realize now that there isn't actually a whole lot to log as libxdo is doing all the heavy lifting.

I found this issue which seems to outline a similar problem when using xdotool https://github.com/koldkaching/semicomplete/issues/66. It would be interesting to see what happens if you use xdotool directly as described in there.

Another thing to try out: in the kde system settings is a way to configure how strictly it's supposed to react to activation requests. I'd like to know what mode it's using rn and what happens if you change it?

I think the best way for me to debug this then is by setting up a fresh vm with kde installed. (i hope arch is bleeding edge enough compared to gentoo to get the same result)

I'll continue work on this in the afternoon after i'm back from an appointment. 😊

[fluffynuts]

xdotool as used in the issue description also fails for me; however the --desktop 0 workaround does activate Firefox though.

I've tried stepping through the source of your project to figure out more - so far, I see it taking the "clipboard hack" route, but I don't see output to the CLION editor when this happens - perhaps I'm just being really naive with the debug attempt :D

[GaZaTu]

OK so i did a fresh install of arch with kde and sadly i can't reproduce the issue.

If you edit https://github.com/GaZaTu/x11-emoji-picker/blob/master/src/crossdo.h#L74 and replace the NULL with ":0" does it work?

[fluffynuts]

hm, ok, so I'm quite sure I first noticed things going badly on Firefox, but:

I was testing against output in terminator (terminal emulator) - nothing happens. On a whim, I switched back to Firefox, and, after ensuring that all app images were deleted and not running, hit my trusty hotkey (win+., of course!) and... emojis are working just fine in Firefox now. And I tested in konsole - working there too (I switched from konsole to terminator not so long ago as well because terminator is faster to start up and allows me to bind keys for resizing panes and doesn't have such giant pane dividers).

So I guess this now becomes the report: emoji picker doesn't work under "some conditions" (**), which is a lot more specific and perhaps traceable - tho those conditions may not be resolvable (see below)

FWIW, I went on this extra round of testing because the NULL -> ":0" trick above didn't seem to work, so I wanted to make sure that I was definitely firing up the recently-compiled emoji-picker binary. System Monitor showed me more than one hit for a running process matching emoj, so I killed everything and tried again with my hotkey (now using the freshly-compiled version out of master, with the :0 fix), and it worked, so I thought "let me double-check that the app image for 0.8 is still acting strangely" and it wasn't.

** so, by "some conditions", I mean: this wasn't working against terminator (as noted above), but I also can't seem to type emojis into the duckduckgo search box - I'm not sure if the two are from a similar behavior: if I focus the ddg search box, then focus another application, then re-focus ddg, the text input isn't focused, so naturally any keypresses you send aren't being diverted to the search box. Perhaps something similar happens with terminator?

At any rate, I think you can downgrade this from "never works" to "there are some specific scenarios that don't appear to work, some of which there's not a lot that can be done to prevent 🤷‍♀️" (eg the ddg thing)

Thanks so much for spending the time to try to debug this with me; I'm sorry this has been a waste of time - though I'm dead sure when I reported this, I couldn't emoji in twitter (their picker is so slow) - again, tho, that might have been a derpy twitter update which made focus disappear from the text input.

I've also discovered that I can ctrl-c from your dialog to place the emoji on the clipboard - and I can paste that back into apps which don't behave as expected (just found another one: dolphin's path input above the files pane)

So I've also learned a work-around for unexpected situations. Thanks again for this app - it really helps someone like me - I'm ASD and I think I often come off as a little cold, so I try to pepper my text with emojis to convey the emotion I'd like to.

[GaZaTu]

System Monitor showed me more than one hit for a running process matching emoj

I think the reason why you had multiple running might be because using the ctrl+v input methods causes the emoji picker to stay active in the background to keep ownership of the clipboard.

if I focus the ddg search box, then focus another application, then re-focus ddg, the text input isn't focused

Now that you mention it, i noticed that behavior aswell when writing a comment on reddit. Using the emoji picker works when creating a new reddit post but does not work when writing a comment because the comment textbox isn't focused anymore. So far i haven't found a solution for that which is quite sad. 😑

I've also discovered that I can ctrl-c from your dialog to place the emoji on the clipboard

ngl i completely forgot that feature exists 😂

(just found another one: dolphin's path input above the files pane)

I found that using InputMethod: ctrl+v works with dolphin.

I should definetely go through some more applications figuring out which input method works, so i can provide more defaults in the emoji picker settings. This is actually something I wanted to do for a while (but have been too lazy to do). 😅

[fluffynuts]

hm I hadn't even read the config section of the readme 😅 but when I was reading code, I was like "woah, there's a bunch of different ways things can happen, and I'm not sure exactly what drives them" 😂

[szamanr]

i'm experiencing this issue as well, in various apps such as firefox, atom. seems to happen randomly.

i hit my hotkey (win + .), the popup shows up, i search for an emoji. when i hit enter, nothing happens. when i hit shift+enter, the popup is closed but the emoji is not shown. when i open the emoji popup next time, that emoji is not visible in the recent list.

occasionally it works, but at least 50% of the time it doesn't. if i hit enter multiple times, sometimes it will work. if i rage click the enter button a bunch of time, i sometimes end up with multiple instances of that emoji. i might need to buy a new enter button. [wanted to type a wink here but it didn't work]

watch me try to input the first row of 10 emojis: 😀😁🤣🙂🙃

the expected output was: 😀😃😄😁😆😅🤣😂🙂🙃

---

i'm on ubuntu 20.04 with gnome 3.36.9 and i have emoji-picker v0.8.2 installed from x11-emoji-picker-x86_64-ubuntu-20.04.deb.

[GaZaTu]

Sadly I'm not able to reproduce this on my Ubuntu 20.04 with GNOME 3.36.8 VM. 😥 Tried Firefox with InputMethod: ctrl+v and Atom with InputMethod: activate window & default Not sure how to help in this case as it usually either works or not at all. I didn't have a "works sometimes" behavior on any of the systems i tested it on so far.

😀😃😄😁😆😅🤣😂🙂🙃 ye idk fdm

[szamanr]

ohh didn't know about different input modes. thanks, i will experiment with that! 😀😃😄😁😆😅🤣😂🙂🙃