Multiple Windows Terminal windows are started, and only one of them is captured by wtq

bllngr commented 1 month ago

Environment

Windows 11
Windows Terminal 1.21.2701.0 installed as Windows App
Windows Terminal set as Default terminal application
wtq 2.0.10 from winget
default WT and wtq settings, with the builtin Windows Terminal example enabled in wtq instead of the Powershell one

Expected Behavior

When wtq.exe is started and no Terminal instance is running, wtq launches Windows Terminal and immediately captures and hides it

Actual Behavior

When wtq.exe is started, a regular Windows Terminal instance is launched
Then, a second window with the default profile is started, sometimes even a third
- seems like this depends on system usage. When the system is busy, it happens more often
One of the instances is being captured by wtq and hidden
The other Windows Terminal windows remain uncaptured and visible

Log

logs-20241022.txt

flyingpie commented 1 month ago

@bllngr Hey Julius, thank you so much for reaching out, I've seen this pop up a bit, and it's really useful to have some extra information on what's going on.

Could you provide your wtq.jsonc file as well?

bllngr commented 1 month ago

wtq.jsonc is the default config, with the builtin Windows Terminal example enabled instead of the Powershell one

wtq.jsonc

hongwen000 commented 1 month ago

I figured out this issue by inspecting the code and finding out the reason is that for Windows 11 users who use WindowsTerminal as default terminal, there would be a mismatch between the name of the powershell window (which turns out to be "WindowsTerminal" and the expected name (powershell)

flyingpie commented 1 month ago

@hongwen000 I think that's a closely related issue, but not the main one. I appreciate you've been looking around in the code, I hope it's reasonably easy to make sense of :)

The config is (taken out some irrelevant bits):

// Example with Windows Terminal
{
    ..
    "FileName": "wt",
    "ProcessName": "WindowsTerminal"
}

The "FileName" property is used to start the app (what you could also type in "Run", Win + R), the "ProcessName" is the process name that WTQ looks for when trying to attach to it (what you can see in task manager). In many cases, only a "FileName" is necessary, and WTQ uses that as the "ProcessName" too (such as is the case for the powershell example).

The split came about due to Windows Terminal, as it is one of not too many apps that actually has a different "run" command than the running process.

When starting a process, WTQ has a retry mechanism, which is what we're seeing here. The first attempt to start the process actually succeeds, but the process is not ready in time for WTQ to pick it up.

I've been playing around with removing the retry mechanism, because that's mostly an artifact from WTQ v1, where there were more reasons to have one. Though there's a different issue that pops up that I still need to have an alternative for, namely that if the app is started, but not ready in time, WTQ hasn't attached to the process yet, and it is not toggled off/on screen immediately (takes another hotkey press for that to happen).

So stop spawning processes, but keep looking for started ones for a while. As soon as that is working, I think this issue should be solved.

flyingpie commented 4 weeks ago

Update on this, the next version is shaping up to address this issue.

I've removed the retry mechanism altogether, and limited the starting of processes to 1 attempt when WTQ starts, and 1 attempt when a hotkey is pressed (and the app is not running yet, and it's set to attach mode "FindOrStart").

The biggest topic that still needs work is feedback, in the form of a notification/alert/popup-kinda thing. The log is nice, but less obvious.

flyingpie commented 2 weeks ago

So far, my own testing has suggested that this is solved, or at least way less pronounced. I'll roll this into the next release, and close the issue after that.

markusmo3 commented 2 weeks ago

Just a little praise: This is EXACTLY what i've been waiting for and what hindered me from switch to v2. THANKS ❤️

(No idea why i randomly got the thought to check wtq again just hours after this feature is in prerelease...)

flyingpie commented 2 weeks ago

@markusmo3 Thank you so much for your comment, really appreciate it :heart:

I'm fixing a bug, then I'll make a new stable release.

bllngr commented 2 weeks ago

Yeah this is great, thanks @flyingpie! Startup is so much cleaner now.

bllngr commented 5 days ago

Just FYI: When autostart on login is very slow for some reason (sometimes happens on my work machine when the network is down), wtq completely fails to capture the Terminal window now.

Here's a log from one time it happened for me:

20241018.txt wtq.jsonc

flyingpie commented 5 days ago

@bllngr Ooh, good one! Can't set opacity and then it dies.

Slated for the next release, thank you so much!

flyingpie commented 2 days ago

Moved this particular issue to #153, still slated for 2.0.12.

flyingpie / windows-terminal-quake