[Issue] Pop-up windows: Problem with "lack of focus" / "click out"

[needcoder]

Problem with "lack of focus". is back - when I call the "ai command" or "new prompt" then "click out." does not close the window - you need to click on this window and only then "click out" or "escape." will close it down

And sometimes the focus is triggered:
I've figured out in what cases: After I explicitly click on the window and hit "escape," - for the next window call - "click out". will work, but for subsequent times it will not work until I explicitly click on the window again and press "escape".

[nbonamy]

I am not able to find a solution for now. I have something (https://github.com/nbonamy/witsy-autolib) that works in Dev but for whatever reason does work in Production. Unable to know why.

For now I am adding a very ugly bar with close button so you can click it.

[nbonamy]

Maybe found a fix. Available in 2.0.0-rc1:
https://github.com/nbonamy/witsy/releases/tag/v2.0.0-rc1

[needcoder]

Maybe found a fix. Available in 2.0.0-rc1: https://github.com/nbonamy/witsy/releases/tag/v2.0.0-rc1

Bravo! "click out" normal works, but "ai commands" window appears again for 3-4 seconds - can we fix it?

if the speed of appearance has dropped due to calculations in which program the text is selected - it is possible to disable this in the settings

[nbonamy]

The only added delay for this is 250ms

witsy/src/main/windows/commands.ts

Line 45 in ddc770e

setTimeout(() => {

On my install which is Windows running in a virtual machine on a Mac (so far from ideal condition), I measured a delay of 50 frames on this 60fps video so 830ms total.

Screen.Recording.2025-03-07.at.08.31.53.mov

And no I am not going to add another setting.

[needcoder]

The only added delay for this is 250ms

witsy/src/main/windows/commands.ts

Line 45 in ddc770e

setTimeout(() => {
On my install which is Windows running in a virtual machine on a Mac (so far from ideal condition), I measured a delay of 50 frames on this 60fps video so 830ms total.

Screen.Recording.2025-03-07.at.08.31.53.mov
And no I am not going to add another setting.

Okay, we can write it off to the fact that I don't have a powerful hardware on my computer, but there is a fact that other windows appear very quickly and this one needs 3 seconds to appear - maybe a feature of electron

[needcoder]

maybe 250ms => 100ms

[nbonamy]

1. I don't think the 150ms difference is what you are worried about 😀
2. It is a totally arbitrary value. If this is done too early, the window stays invisible. In my tests, 250ms seems the right value but not impossible that somebody logs an issue in some time with "window does not appear".

Remember: it is a hack to mitigate an electron issue...

[nbonamy]

As predicted, had to reverse things for now. I fear this is going to end as a known-bug with no fix planned. I cannot workaround electron / OS issues.

[needcoder]

As predicted, had to reverse things for now. I fear this is going to end as a known-bug with no fix planned. I cannot workaround electron / OS issues.

The funny thing is that now "ai commands" start up in ~1.5 to 2 seconds and "click out." works, but after changing the layout to Russian - 1 time is called - and then on each call starts the bug "Please higlight text...", even if you change back to en layout - the bug does not go away.

upd: I just saw a message about "Alternative Method"

[needcoder]

As predicted, had to reverse things for now. I fear this is going to end as a known-bug with no fix planned. I cannot workaround electron / OS issues.

The funny thing is that now "ai commands" start up in ~1.5 to 2 seconds and "click out." works, but after changing the layout to Russian - 1 time is called - and then on each call starts the bug "Please higlight text...", even if you change back to en layout - the bug does not go away.

Can we implement somehow neatly work for non-latin keyboards? because when you select "alternative method" - "click out" doesn't work (just for the default version you only need to add non-latin kb support)

[nbonamy]

The problem is this one: when you activate "Alternate copy/paste method" for non-latin keyboard, it uses the Powershell script which spawns a separate process which creates the focus issue for which I don't have a solution as once again this is an electron/OS level issue and no good workaround is available. And honestly I have spent enough time on this for now 😀

[needcoder]

The problem is this one: when you activate "Alternate copy/paste method" for non-latin keyboard, it uses the Powershell script which spawns a separate process which creates the focus issue for which I don't have a solution as once again this is an electron/OS level issue and no good workaround is available. And honestly I have spent enough time on this for now 😀

It's extremely frustrating that the electron didn't provide for this.

[needcoder]

The problem is this one: when you activate "Alternate copy/paste method" for non-latin keyboard, it uses the Powershell script which spawns a separate process which creates the focus issue for which I don't have a solution as once again this is an electron/OS level issue and no good workaround is available. And honestly I have spent enough time on this for now 😀

You can ask their repository - why doesn't it work and we have to write crutches, or the solution exists, but we just don't know about it

[needcoder]

The problem is this one: when you activate "Alternate copy/paste method" for non-latin keyboard, it uses the Powershell script which spawns a separate process which creates the focus issue for which I don't have a solution as once again this is an electron/OS level issue and no good workaround is available. And honestly I have spent enough time on this for now 😀

It is very important to emphasize that when you change the layout from English to Russian and press hotkey - window "ai command" is called 1 time before the bug - well, how is it possible that 1 time it works (i.e. it reads keys correctly) and then the bug starts?

[needcoder]

Can't even make a workaround crutch of calling a python script to change the layout before calling "ai commands"
That is, assign the utility to the same keys to change the layout via PowerToys keyboard manager - for some reason if witsy does not read the hotkey if it was read by another program

[needcoder]

The problem is this one: when you activate "Alternate copy/paste method" for non-latin keyboard, it uses the Powershell script which spawns a separate process which creates the focus issue for which I don't have a solution as once again this is an electron/OS level issue and no good workaround is available. And honestly I have spent enough time on this for now 😀

It is very important to emphasize that when you change the layout from English to Russian and press hotkey - window "ai command" is called 1 time before the bug - well, how is it possible that 1 time it works (i.e. it reads keys correctly) and then the bug starts?

Moreover, if you change Hotkey, then the bug disappears (Changing the hotkey triggers something that resets the bug) - maybe the best solution to this problem lies in this

UPD: Maybe with "alternate copy" enabled, we can reset the Hotkey every time we change keyboard layouts (or after calling the "ai commands" window), or you can come up with a more elegant option.

[nbonamy]

Just to be sure: the "Alternate Copy/Paste Method" thing should make the shortcut work with non-latin keyboards. The only issue remaining is the lack of focus on 1st display. Right?

[needcoder]

Just to be sure: the "Alternate Copy/Paste Method" thing should make the shortcut work with non-latin keyboards. The only issue remaining is the lack of focus on 1st display. Right?

The only problem is that the "click out" doesn't work with the alternate method to close called windows, the rest works

But the best implementation is default, and I suggest to focus on the fact that when you change the hotkey in the settings - it resets and removes the bug, so maybe with the alternative method don't write sidercar solutions but just reset the hotkey when you change the layout or after every window call? (because even on non-latin layout windows are called 1 time, and only from the 2nd time the bug starts).