[Feature requests] Support for auto-off in full-screen apps; Ability to adjust the sensitivity for each hot corner separately #1
Comments
|
Also, I apologize for asking off-topic, but I wanted to know if you use the wonderful PowerToys application from Microsoft? Many people use PowerToys and would like to have support for hot corners. Back in 2020, a request was opened regarding this #1305. So far, the developers have not been able to implement it, and they marked the request as "Help Wanted", although many people still continue to open requests on this matter. Your app is written in C#, unlike many others, which makes it a great candidate to be integrated into PowerToys. This could benefit a much larger audience, and people would be immensely grateful for it. Therefore, I'd like to know if you could consider such a development option for your app. Probably, in this case, some changes would need to be made to the code to bring it up to PowerToys standards, and the UI would need to be re-implemented, but the PowerToys developers would assist with that, at least that's what they wrote themselves. I understand that you primarily developed app for your needs and implemented what you deemed necessary, and perhaps this idea doesn't interest you at all. Nevertheless, I decided to ask. I apologize if this sounded somewhat presumptuous on my part. Thank you again, and happy upcoming New Year to you 🎄 |
|
Hello and thank you for the interest in the app. I appreciate the feedback very much!
Although I don't experience this, my suggestion is that some phantom movement of the cursor around the hot corner area triggers the event repeatedly in a short period of time. I've added an adjustable delay before repeating the same action, please kindly try the 0.6.2 beta. Too big or too small hot corner area may be a possible cause as well. After installation you may try different values for the corner radius and delay in the app Settings. By the way, what action causes this behavior?
Accepted.
That's on the list too, along with traditional commands. I haven't imagined a simple straightforward implementation still.
Why would you like to have that?
What features would you find useful besides the mentioned ones? Maybe I'll be able to implement some.
Oh yea I used to have it on my first computer, Windows 98 if I recall this correctly. What I don't like with the current reincarnation is it's enormous size – almost 900 Mb installed. My app occupies less that 1 Mb disk space and I definitely intend to keep is as simple and lightweight as possible. However I'll consider your suggestion. Don't know for sure, I need to look at what their requirements are. |
Thanks a lot, and happy New Year to you too!!! |
I tried the latest beta, now the problem is slightly different. If you quickly move the cursor to the corner and back, everything works fine, the selected action is run. But if you move the cursor to a corner (the selected action is run), and hold it there for some time, and then return cursor, for example to the center, as soon as you take a corner away from there, the action is canceled. I think the problem is precisely in the logic of working with the area. Let's say we have a 2 by 2 pixel square. All movement actions are cyclic: run-cancel. Currently, as far as I suspect, if we move the cursor to this area, the action will be run. And if we continue to move through this area with the cursor, the action is cancel-run-cancel, etc. This is precisely the problem. In my opinion, it's necessary that when the cursor enters the reaction area, the action is run, and nothing happens when the cursor is moved further around the area. And to cancel the action, you must first move the cursor beyond the reaction area itself, in our case, it's a square 2 by 2 pixels, and then move the cursor again to the area where the action is run. That is, when the cursor is moved to the reaction area, it should perform the action only 1 time, and all further movements should be ignored until it leaves the area and returns to it again. I hope you understand my logic and what I mean.
For example, we use the upper-left corner for Task View, and the response to moving into this area should be instantaneous to quickly open Task View. On the other hand, for the lower-left corner, we assign the function of turning off the screen or transition to sleep mode. To minimize the chance of accidental activation, we set a longer response delay so that the user deliberately moves the cursor there and holds it. This is not my scenario, but I've extensively reviewed this kind of apps and read various feedback and requests, so I adopted this scenario from other users who need it. I only use the upper-left corner for Task View because I don't need anything else. However, each use case varies, so I decided to mention it because I've seen requests for this functionality multiple times.
Overall, HotFrameFx suits me quite well. The only feature I find lacking is support for multiple displays. At home, I mostly use only the laptop screen, but at work, I've a desktop computer with several displays. The absence of multi-monitor support there is much more noticeable. Additionally, if in the future I want to configure an action for another corner, the inability to adjust sensitivity for each hot corner separately would also be an issue. There are various minor nuances not directly related to functionality. For instance, it doesn't track the launch of multiple instances of the app, meaning you can inadvertently open the app multiple times, which isn't good and disrupts its operation. Also, it's not possible to hide the icon in the system tray. Most hot corners are set up once and then left alone, and a persistent tray icon only hinders and clutters it, especially considering the presence of many icons from other apps that are also impossible to hide. However, in terms of the core functionality of the app, HotFrameFx works best among all those I've had the chance to try. Here's a small list of improvements for your application that I'd like to see:
Yes, PowerToys takes up almost 700 megabytes. However, it includes various useful utilities, such as PowerToys Run and many others. The main advantage is that it's developed by Microsoft itself, and users trust it. They prefer not to use third-party applications for hot corners and want this functionality to be integrated into PowerToys, as it happened, for example, with the Peek feature. This conclusion can be drawn from all the comments. Therefore, users continue to open requests with the hope that developers will pay attention to it because it has been almost 4 years since they started expecting it. It would be great if you could consider this. You can continue to develop your app in parallel with PowerToys. It's just that even some partially transferred functionality of hot corners from your app and the launch of this function in general would allow to move this issue from a dead point. |
|
You can also take a look at these links, maybe it'll be useful for you to implement auto-off in full-screen apps. |
|
Until I forgot, I'll add another item to the list of improvements.
|
Yes I understand and that's exactly the way it works from the beginning. And now I've added an additional adjustable delay before triggering the action if the cursor enter the active area again after having left it. I'll investigate the problem further, maybe there's an error somewhere, right now I don't understand the cause unfortunately.
I got it. That's an interesting feature I haven't considered yet.
Me too, actually. And apparently I was too lazy to find HotFrameFx before implementing my own app 😁 Thank you for the participation, I find your comments very useful and will certainly consider implementing some :-) |
Implemented in 0.6.4 👍
Still in research, I'll move this to a separate issue and leave this thread as a generic suggestions chat 😉 |
Could you please run the latest binary from Publish directory and confirm if the behavior has changed? |
I tried the latest beta, thanks for the improvement. However, in terms of the work itself, nothing has changed, corner detection works poorly. Problems with work are especially noticeable if you set a long or maximum delay (3600-5000 ms). If you quickly move the cursor to the corner and back many times, then regardless of the long delay time with a periodicity of 3-5 times the selected action will still occur quickly, without delay, despite the fact that a long delay is set. Also, if you quickly move the cursor to the very corner and leave it there without moving, the selected action in many cases won't occur until you move the cursor again. |
What are your current settings (action, radius, delay)?
That seems to be the delay occuring. |
It doesn't matter, even with the default settings, the problem remains.
No, it's not a delay. Because the cursor can be there for a very long time, but still the action doesn't run until the cursor is moved. |
It seems that I fail to reproduce this behavior. On my personal computer, at least. Although I'm not a user of Win 11, I've set up Parallels running Windows 11 ARM on Mac and despite the UI being quite slow, the application seems to work even better than on my primary PC. I'd even use the word flawlessly if I knew not about the issue. However the context menu and the windows look terrible on 11, you're right about that. 😂
If the cursor entered the sensitive area white the delay was active and stays still there, the event won't be fired even on the delay expiry. That's how it works not. The application doesn't see cursor, only movements. I'll think about the above and maybe change the logic somehow, but now I don't see a solution since I cant reproduce the issue. |
Design has taken a backseat to me as long as the app doesn't work properly.
I understand that the app tracks the coordinates, that is, the position of the pointer, and I understand how it should work in principle, but it doesn't work that way for me. I tried today on another computer, although it's also running Windows 11. This problem is also relevant on it. And to immediately close the question that maybe HotFrameFx disrupts the operation of HotCornersWin, I'll say that I completely closed HotFrameFx – the situation doesn't change, the problem is present. Video 1. All default settings. To minimize any inaccuracies, the app was reinstalled, the configuration folder was deleted before that. I remind you, on the right – HotCornersWin; on the left – HotFrameFx. 120240103185024387.mp4Video 2. The delay is set to the maximum, 5000 ms. Other parameters are unchanged. For HotFrameFx, the largest delay was also chosen for clarity of operation. I remind you, on the right – HotCornersWin; on the left – HotFrameFx. You can see how with fast movements to the corner in HotCornersWin sometimes the long delay time is neglected, and the action happens almost immediately. And sometimes the action doesn't occur at all, although the cursor is in the reaction area. 220240103185551087.mp4 |
|
Thanks for the video, it's now a little bit clearer. |
Glad to hear. I'll wait 😉 |
|
I understand that Pascal is completely different from C#, but many of the apps I tried also had various problems with corner detection. With HotFrameFx everything worked perfectly from the start, it might be useful to take a look at the very approach it uses. |
Please find 0.6.5 beta ready for testing.
Oh it really might... but I avoid looking at the code to follow my own way instead of just rewriting someone's ready solution 😉 |
Oh, at first glance it works great, it seems that the problem is no longer observed, I'll test it and let you know if anything.
Well, this is sometimes useful, as in this case, when there is a problem, but you don't manage to reproduce it. However, everything seems to be working great now. |
|
I see the delay problem is still present. If you set a long delay, sometimes it is ignored and the action happens quickly, ignoring the delay. |
However, I don't think the delay itself is needed, since the app's logic was shifted from event-driven to fixed interval polling, a delay sufficient to filter cursor jitter happens naturally now. I suggest I'd remove the feature in favor of customizable sensitivity.
Thanks for your participation, this wouldn't so without it. If you confirm this working, I'm going to close the issue, it has grown too long now. Feel free to open another one! |
Lol. To me, delay and sensitivity are the same thing, because in both cases the principle is the same: the cursor waits for a specified time in the response area before run the action. Of course, if the implementation of sensitivity isn't the same as delay for you, and some other approach will be used, then of course in that case the delay should be removed, because it's still essentially a duplication of functionality.
As without your implementation 😉
Yes, the issue seems exhausted, well, at least for me and for now. But until no one opens any more issues, I'd be grateful if you didn't close this issue yet, because it no longer fully meets the original purpose, but rather turned into a chat. I've a few more minor troubles and discussions that aren't worth a separate issue for them. |
Okay then, let this thread stay opened 👌 |
|
Also, today I accidentally selected action "Start menu" instead of "Task view" and saw that it doesn't work. I definitely tried it before when I was testing the app work and it worked. I looked at a few other options, they seem to work. So, when you've time, please pay attention to it. I'll also note that "Task view" will need to be renamed to "Task View", i.e. "View" with a capital letter, because this is the correct name of this function. |
|
I also noticed that you switched from the delay parameter to the polling interval. And this parameter doesn't affect the work in any way, that is, nothing happens when it's changed. As far as I understand, this isn't yet an implementation of the sensitivity function. That is, in my opinion, the polling interval parameter isn't needed at all, unless it's an intermediate transition from delay to sensitivity and you left the polling interval as such a transitional option until you implement the sensitivity function. Then it makes some sense. Because otherwise, I don't know what to set it up for, let alone it doesn't work, well at least for me. |
Accepted. BTW, does virtual desktop left/right switching work on your Win11 machine?
Accepted.
Previously, the logic of the application was roughly the following: wait for a mouse movement, get the coordinates, check if it had hit a hot corner. As we did find out with your help, this approach failed to deliver acceptable results. I have some clues how that come, but I don't want to make the app complicated any further. That's why I switched the approach. Now, the app reads the cursor coordinates and checks for a coincidence with a hot corner area, then sleeps for some time, then repeats. As we have gotten rid of events, we need to decide how frequently the app has to read the coordinates (in other words, how long it sleeps between subsequent reads). Too frequent updates imply a high CPU consumption, too few of them mean that some fast movements will be missed out. That's why a new parameter was introduced – the polling interval. That's the amount of time between the cycles of cursor position update. A value of 100 means 10 updates per second, for example. Normally this parameter needs not to be adjusted and has to be somewhere around 100. This setting works but patently you can't see it with the naked eye 😉
No no no that's not. There's actually a hardcoded value now in the source code |
No, it doesn't work either.
Ok, thanks for explaining.
Probably the best solution would be to hide this parameter and set it to a default value that you think is correct, so that the user doesn't accidentally break anything due to ignorance of what he's responsible for. In my opinion, this isn't something that needs to be configured by the user.
Ok, got it. You have already spent many days of your holidays on app development, thank you for that. I'll wait for further implementations. I still have a few fairly minor edits, but I'll try to get them in shape tomorrow. |
|
Perhaps, after the implementation of Custom actions (commands and hotkeys), it'll be better to link the list of actions to the hotkeys, because they are used in Windows by default, this will allow you to avoid problems with different versions of Windows. |
|
I noticed such an unpleasant thing due to non-working actions for the "Start menu" and "Switching Virtual Desktops". They don't work, but if you select them and try to execute them, they won't work, but then with random periodicity, when you open "Task View", the "Start menu" can run itself and immediately close. And this can happen several times with different frequency when "Task View" is reopened. Perhaps, the number is related to the number of times you tried the "Start menu" action and it didn't work. As for "Virtual Desktops", numbered system notifications about the current desktop appear if you on/off the application. Sometimes, if you open some completely third-party app. In short, such a very unpleasant bug. |
That's all for now, if I remember something else, I'll add to the list 😉 |
Must be fixed in beta 0.8.0 please have a look.
Oh that's quite a list 😉 I'll review a little later and come back... |
Partially fixed. Switching virtual desktops at first glance works correctly, but the Start menu doesn't work cyclically, that is, it only opens, but the repeated action for closing doesn't occur.
This is more of a textual description than corrections, and some questions are repeated. So don't worry that there are so many of them 😄 |
Basically, what the application does is just a keystroke emulation. Unfortunately, there's an inconsistency in the way different hotkeys work in Windows: repetitive Win+Tab toggles Task View on and off, but repetitive Win only keeps bringing the Start menu up and never retracts it back P.S. I was wrong with that. So, there is no intentional cyclic action and never had been, in fact. |
🤷♂️ in HotFrameFx it just works for me |
I was wrong with this one. The issue #14 is opened.
Personally, I'd prefer seeing what's running in the background instead of some "magic" processes being hidden somewhere. In addition, hiding the app's icon raises a question of how is a user supposed to access the settings? We'll need then a configuration utility or a special command-line switch, along with a separate shortcut in the Start menu, for example. And what if they want to temporarily disable the app – now it's possible with just a double-click? Idk, for me the cons outweigh the pros.
Done. I didn't want to, until you or somebody else confirm the app works as intended, since I'm not the Win11 user and I hope I won't be in the near future.
A lot of apps have rather extensive about sections and honestly I don't see a problem in that. The current version looks not very neat – that's what I agree to, however.
Agreed, issue #12
It's a quick dirty hack caused by the context menu sometimes being in front of the window. Maybe I'll refactor that later.
Most notification area utilities (at least that I'm using) display their interface in the bottom right corner of the screen. That's an expected behavior for me. And the windows is movable, if the position seems so much unbearable. 😄 Let's leave this in limbo now.
P.S. Fixed in v0.8.2
That seems to be an installer configuration error, issue #13 P.S. Fixed in v0.8.2
I'm not, tbh. It's just a matter of taste; in addition we already have WinHotCorner in development, WinXCorners apparently not unknown at all, WinHotkey and who knows what else... Or maybe I'm too lazy with renaming all the stuff 🤷♂️ |
|
Thanks for the answers! |
Thank you for taking part! |
I'm closing this long thread now; feel free to use discussions if any questions, suggestions on anything else ^-) |
Thanks for the app. I tried the latest beta version and can confirm that also works on Windows 11.
As for the nuances, currently, it doesn't work very well, especially in detecting corners — at least in my case. When you move the cursor to the corner, the app tries several times to run the selected action for the hot corner, that is, the action is run-cancel-run, resulting in flashing. It's not always the case. Sometimes it works fine, but in most instances, it comes with this particular issue.
I'll also note, among the features I'd like to see, support for auto-off in full-screen apps, as well as the ability to adjust the sensitivity for each hot corner separately.
I'm currently using HotFrameFx, and it works great, but it lacks a few useful features. Interestingly, the configuration of actions for corners is done with hotkeys, which is excellent because users get the option to choose from many different actions, not limited to those implemented by the author. Perhaps you could consider incorporating a similar option into your app as an additional feature.
The text was updated successfully, but these errors were encountered: