Make Windows 10 switcher respond to Enter key

[CrendKing]

Thank you for your recent update on the switcher. And sorry for the nitpicking of this request.

There is one tiny difference of the current implementation comparing to the actual Windows 10 switcher, that it only responds to the Space key, while the latter responds to both Space and Enter key.

Can you please allow Enter to select window?

[valinet]

I have added that; it's uploaded in place of the current pre-release version. Enter works the same as space worked and still works. Haven't thought of that from the get go, usually it's only "Space" that selects stuff, "Enter" only in certain instances, but here it makes sense, indeed.

Thanks

[CrendKing]

Thank you. However, it seems the ability to navigate with arrow keys is broken in the new version?

[valinet]

Support for the arrow keys is not broken, it’s not implemented altogether. So I don’t know how it possibly would have worked in older releases when I never had code to treat those…

[CrendKing]

You are correct. I must have misremembered.

I think I found where the keydown events get processed: https://github.com/valinet/sws/blob/master/SimpleWindowSwitcher/sws_WindowSwitcher.c#L1082. I feel bad for keep asking for things. So if you don't mind, I can try to do a pull request for this one. My change works locally for me, but a bit messy (basically copied the section for processing (shift+) Tab key). We could discuss for cleaning it up. But if you feel this too small to bother for PR, could you please add this feature?

P.S. I didn't know there is mini mode for the switcher (Alt+`). It seems to be only showing the windows for the same process of the currently focused window?

[valinet]

P.S. I didn't know there is mini mode for the switcher (Alt+`). It seems to be only showing the windows for the same process of the currently focused window?

Yeah, that's it, indeed. I think i remember seeing such a thing in GNOME or something like that and with the way layouts are computed, adding that in wasn't such a big of a deal. And indeed, I forgot to mention it anywhere, because I forgot about it altogether. It was at the time I was implemented positioning for the switcher, and whether it should display all windows or windows only on the current monitor.

I think I found where the keydown events get processed: https://github.com/valinet/sws/blob/master/SimpleWindowSwitcher/sws_WindowSwitcher.c#L1082. I feel bad for keep asking for things. So if you don't mind, I can try to do a pull request for this one. My change works locally for me, but a bit messy (basically copied the section for processing (shift+) Tab key). We could discuss for cleaning it up. But if you feel this too small to bother for PR, could you please add this feature?

Around there, indeed. The thing is left/right arrow is piece of cake, takes 3 lines of code to implement.

Up/down is more troublesome... Like, window information (which also contains the coordinates of the rectangle where the preview will be drawn) is stored in a 2D array. Getting to the row above/below means checking from the current position until the top of the preview rectangle changes compared to the top of the current one, for example. Or until there's no such rectangle (non-visible items do not have an associated rectangle, because, well, they won't be drawn, so what position would they have). So yeah, that's also easy, if you start having no rectangles, then again, you reached the different row. That's how you figure when you get to the first items on the next row. That's also easy.

The problem is what you do from there? Because you expect pressing down to select the item that is most near the one you are on, but on the next row, for example. Well, this "near" is where the complication arises. How do you determine what's near in a low overhead way... idk, I will have to think. I mean, don't get me wrong, it's doable, I just never though of it.

So, in your local changes, you also implemented up/down or just left/right?

[CrendKing]

I just did the left/right arrow. As to up/down, I don't know if you store the X and Y position of each thumbnail (_sws_window?) If not, maybe consider storing them. Once you have them, arrow down means finding the other item that has the closest value to current item's X (compute difference in absolute value), while having closet and greater value of Y. The worst runtime is O(n), but you can optimize it.

For example, suppose there are two rows of items, with 3 on first and 2 on second. Let's name them (1, 3) (3rd item on first row), (2, 1) (first item on the second row). The treatment for (1, 1) and (1, 3) is deterministic. Depending on the width of the thumbnail, the (1, 2) could fall to either (2, 1) or (2, 2).

Also note that while pressing down from (1, 1) goes to the (2, 1), pressing up from (2, 1) may not go back to (1, 1), due to squashing. You can observe the asymmetric behavior too on Windows 10.

What do you think?

[valinet]

Yeah, I have typed a reply like 6-7 hours ago, it seems I forgot to hit send (I know why, I switched to some other tab to write the release notes, then had some other stuff to do and forgot about the one with this issue). Whoops. Anyway, what I said there is that, yet again, I have been proven that actually implementing is much easier and faster than thinking how hard it might be and trying it explain it. So yeah, I have implemented and updated a revised release since a few hours ago, but as I said, forgot to send... so lame, yeah, apologies.

Once you have them, arrow down means finding the other item that has the closest value to current item's X (compute difference in absolute value), while having closet and greater value of Y. The worst runtime is O(n), but you can optimize it. For example, suppose there are two rows of items, with 3 on first and 2 on second. Let's name them (1, 3) (3rd item on first row), (2, 1) (first item on the second row). The treatment for (1, 1) and (1, 3) is deterministic. Depending on the width of the thumbnail, the (1, 2) could fall to either (2, 1) or (2, 2).

Anyway, yeah, basically you explained pretty much what I did. Like, exactly that =))) I mean, how many other ways are there to implement this, really, but still... As I said in the beginning, it's doable, I just wasn't willing to put the brain for work for the 10 minutes without some initial complaining =))) Then I realized, again, that it's just easier to shut up, think a bit and in a few minutes be done with it. So it's in there for quite a while now, you can have a look the code that independently implements exactly what you just stated (that's how clean reverse engineering is done also, by the way): valinet/sws@b16f8a6. It even came out looking rather nice, not many changes at all. I also fixed a bug in the process =)))

As to up/down, I don't know if you store the X and Y position of each thumbnail (_sws_window?) If not, maybe consider storing them.

They're stored indeed, in pWindowList[i].rcWindow, that is the rectangle where the app will be drawn, and rcThumbnail is the rectangle where the window preview will be drawn (that's inside of rcWindow).

Also note that while pressing down from (1, 1) goes to the (2, 1), pressing up from (2, 1) may not go back to (1, 1), due to squashing. You can observe the asymmetric behavior too on Windows 10.

Yup, happens exactly like that here as well. And indeed, I also expect it. No, it works rather nice, what can I say, I am satisifed with how it turned out =)))

So, thanks for taking the time for explaining as well, my bad for not hitting "Send" to spare you the time, but I guess it's useful for maybe other people looking to better understand and learn about this topic.

[CrendKing]

Glad it worked!

One last point before we conclude here. I noticed your solution has "amd64" as the architecture, but the compilation guide in README.md all still have "x64". Just to let you know.

[valinet]

Yeah, I know, thanks for pointing that out. I changed the targets' names' a while ago. I said I will update that in the README when I will rewrite that and reorganize it a bit, I thought that might come sooner so I kept postponing it. In the mean time, quite some time passed, some people asked the same thing and I had to point them to typing "amd64" instead of "x64" to get it to build.

So yeah, I have updated that as well. Thanks.