WindowTop / WindowTop-App

Set window on top, make it dark, transparent and more
Other
1.16k stars 69 forks source link

Feature Request: Keyboard shortcut to toggle anchors #123

Closed ACastanza closed 3 years ago

ACastanza commented 3 years ago

The anchors feature is absolutely incredible! I came to the software looking for transparency, but I think anchors are the feature I wouldn't want to give up. But what would make it even better is the option to toggle it on and off with a keyboard shortcut. Most of the time they fade into the background (both figuratively and literally), but occasionally they're just a little too distracting and it'd be nice for there to be a way to quickly disable them, and be able to bring them back without needing to expand the system tray and toggle it from the menu.

Thanks!

gileli121 commented 3 years ago

@ACastanza Thanks for your feedback! It was my idea, and I hoped that this idea was good and seems that I was right. I agree with you that it is a little too distracting sometimes and that the option to disable/enable it via hot-key is a must to have.

I will develop it soon.

Any idea what the default hot-key should be?

gileli121 commented 3 years ago

@ACastanza It was done It added here: image

Try this build: WindowTop Build 29-07-21_1.zip

Let me know how it works

ACastanza commented 3 years ago

It's great! I bound it to alt+A (anchor), but then I changed most of the default keybinds (including replacing the default Alt+A keybind with something else) so maybe best to leave it unset by default. I did notice one thing though, it doesn't seem to be able to initially enable the anchors. Like, if you've never enabled them before the keybind wasn't able to turn them on for the first time, I had to first enable it from the system tray icon's right click menu and only then could I toggle them on and off with the keybind.

gileli121 commented 3 years ago

@ACastanza Great

I did notice one thing though, it doesn't seem to be able to initially enable the anchors. Like, if you've never enabled them before the keybind wasn't able to turn them on for the first time, I had to first enable it from the system tray icon's right click menu and only then could I toggle them on and off with the keybind.

The idea is to hide/unhide. If there is nothing to hide/unhide (because it is not enabled) then it will do nothing. Do you think that this behavior should change? So if it is not enabled and you "Unhide" it via the hotkey, it will actually enable it?

ACastanza commented 3 years ago

My thought process was that "Disabled" and "Hidden" are functionally equivalent so a keybind for "unhide" would perform the same function as "enable" if anchors were not active (either not active because hidden or not active because disabled). Does the opacity toggle (for example) not perform like that? You don't have to first enable transparency from the menu for a window before you can toggle it with a keybind.

But I suppose the desirability of that might depend on things like how the anchors are implemented, if they'd always run in a background process if you didn't have to first enable them manually, that extra overhead might not be desirable for someone who had no intention of toggling them on.

gileli121 commented 3 years ago

@ACastanza At the code level, there is almost no difference. The option to "Hide" is also stopping the background thread as the option "Disable" The only difference is that the option to Hide it will not save it to the settings file (as the disabled state) and that it will not delete from memory the last anchor position (so when you unhide it you will see it on the same location on the screen).

I understand that you prefer that it will enable it if it is disabled. The question is if it should also save the enabled state to the settings in this case? And if you hide it, it will also save it to settings as a disabled state?

ACastanza commented 3 years ago

Oh, so if you were to set it to the disabled state every time you toggled it to hidden, it would then also delete the anchor position. Resulting in it not remembering the anchor position next time you unhid it. That's probably not a desirable behavior. I think the optimal behavior would be, from my perspective at least, to allow the keybind to set it to enabled and save the enabled state, but to only set/save the disabled state through the tray icon context menu (or settings toggle). But it's your software, I got the keybind I asked for, that's good enough for me.

gileli121 commented 3 years ago

Oh, so if you were to set it to the disabled state every time you toggled it to hidden, it would then also delete the anchor position.

It could be true, but it is wrong because I know what I am doing. I can control the way I disable it.

In code there are 2 options to disable - The first one is to remove it from the background thread and also remove the object that knows the location on the screen. The second one is to only remove it from the background thread.

If you disable all anchors (it can be that each other is disabled in one of the 2 different ways), then the background thread will stop anyway.

What we want here is that when you disable it via hotkey, it will only remove it without removing the location. In addition, it will not save the new state to the settings in this case (that you used hotkey).

Did I get you right?

ACastanza commented 3 years ago

Yes that sounds right. Thanks again!

gileli121 commented 3 years ago

@ACastanza Please try this build: WindowTop Build 29-07-21_2.zip

Let me know if it works now as you wanted

ACastanza commented 3 years ago

That works great, thanks for doing this!

gileli121 commented 3 years ago

Great!

gileli121 commented 2 years ago

@ACastanza Here is updated version of this feature: anchors_demo

It will now show icons. It is available in v5.7.5