Closed mqnc closed 11 months ago
I implemented this myself using the first option. Actually even nicer than that would be if only the vscode instance that has the focus listens on the standard port. But I'm fine with the way it is now.
Hi @mqnc thank you for the feedback and suggestions. I was on vacation, so I hadn't had the time yet to pick it up.
Could you share the solution? Would be happy to add it to the extension for others as well.
I created a pull request. I noticed that sometimes commands are not executed until I unfocus and focus the window again :/
@mqnc just noticed the PR and merged it. About the re-focus
, that might indeed be a problem. Maybe we need to test a bit more to find a better solution to see if a certain window is focussed.
Thanks for merging it! I've been using it the whole time and am not really satisfied with it as I said. The thing is, we really want to avoid that a window that is not in focus receives commands. So when the plugin starts, it assumes that the window doesn't have the focus, although it most likely has. So there is one mandatory refocus after starting vscode, which is already annoying. Then, as I said, it sometimes happens that the vscode.window.onDidChangeWindowState does not fire for some reason. So far I am only aware of that happening when the window gets the focus, not noticing that the focus was lost would be worse (and might have happened without me noticing).
It would be nice if there was some way to query if the vscode window is in focus, rather than an unreliable event when the focus changes. Alternatively, if there was a way to display the RC port in the window title (or any other window property that can be read from the outside), the remotely controlling program can decide what port to send commands to. But as far as I'm aware of, the window.title setting only allows for a very restricted set of dynamic variables.
@mqnc found a focused
property on the window state: vscode.window.state.focused
. Let us test it out to see if that works better.
The title is indeed a limitation for extensions.
@mqnc I made a change to the code and pushed it to the DEV branch. Can you test it out and see if that works better?
Seems to work fine, thanks!
Cool! I'll release this.
Version 1.6.0 will be available in a couple of minutes.
Unfortunately it still happens that the window is in foreground but does not receive commands. It seems vscode.window.state.focused is as buggy as the other variant. Seems to be a broader vscode bug then...
I am using this extension for voice coding. If I have multiple instances of vscode running, my commands are sent to the one with the default port, while they should be sent to the instance that has the focus.
I see several options to address this:
Would any of this be possible? If you have another idea that doesn't involve modifying your source, I am all ears!
Thanks!