Apps with inconsistent toolbar visibility when hovering over minimize button

[vertigo220]

Thought it might be helpful to create a list of apps where hovering over the minimize button doesn't show the toolbar (or does but inconsistently), so you can potentially check each of them out to see why it doesn't work and therefore improve the feature to make it more compatible. Here's what I've found so far:

• PotPlayer
• czkawka
• Dupe Clear
• ImageGlass *
• XnView MP *
• Steam
• Epic Games
• Task Scheduler
• PDF-XChange Editor

*shows but very intermittently, often requiring multiple attempts and several seconds or longer before showing, giving the impression it's not working at all, then once it shows, when moving the mouse it will often disappear then quickly reappear

[gileli121]

Thank you for the information. I'm aware that it doesn't always detect the minimize button.
The reason is that it's not necessarily something standard. There are windows where the minimize button is a custom implementation by the software itself.
Therefore, it is likely impossible to support every such case.

I can use the list you provided to try to improve the minimize button detection algorithm, but I'm already saying that it probably can't succeed fully. This could be endless.

That's why, when it doesn't work, it falls back to showing a green arrow instead of integrating with the minimize button.

[vertigo220]

Yeah, I understand that. Just figured if it could help get it working with even one or two of these, that might result in many other programs with similar designs also working. Not suggesting that it gets "fixed" to work with any, much less all, of them, just that it might be helpful to know what apps don't work in case you want to try.

[gileli121]

@vertigo220

Right. I understand.
I’ll work on improving it when I get the chance.

In the meantime, it would help if you send a sorted list starting with the software you use the most and ending with the software you use the least.

This will be helpful when I work on it, so I’ll know where to start.

Thank you!

[vertigo220]

Half those programs I don't use much, if at all (e.g. I trashed the 2nd and 3rd as they aren't very good and I rarely spend much time in the Steam and Epic launchers or in task scheduler), and the rest I don't see much use for this program with them, and for the rare occasion I might I can just use the arrow. It works fine in every program I've tried so far that I use frequently and have the need for this app. The list was more for reference, purely informational, not a request to fix it for those apps. If I find one that doesn't work that I'd really like it to, I'll let you know, but as it stands, please consider this a very, very low-priority issue.

[gileli121]

@vertigo220
Okay, thank you.
I’ll look into this. The first thing I’ll check is why the minimize button of WindowTop isn’t being detected.
This is something very standard that many other programs might also do. So, if I fix this issue, it might work for quite a few other programs from this list as well.

[gileli121]

After further research and analysis of the issue, I’ve concluded that this shouldn’t be part of the "Basic bugs or extremely good enhancements" program (mentioned in #389)

The reason is that I now understand this isn’t a Basic bug—it turns out it’s not a quick fix. The code works correctly even with WPF windows like those in WindowTop. The issue is that the API being used doesn’t provide enough information to detect the minimize button.

Additionally, when this doesn’t work properly, it doesn’t behave in a critically bad way. In the worst case, it just displays the arrow.
If that weren’t the case, I would have kept it on the list as a high-priority bug that needs to be addressed.
Additionally, there aren’t enough user reports to justify giving this a higher priority.

For these reasons, I’ve decided that this won’t be fixed sooner under this roadmap category.

Furthermore, fixing this would require re-implementing part of the logic using an additional OS API to detect the minimize button. Through my research, I’ve confirmed that this is possible.

However, the same/similar amount of development effort—possibly with a little extra work—could instead be used to implement this feature:
#324

The same API that could help detect the minimize button could also help implement request #324.

Additionally, rewriting part of the logic to use the new API carries a relatively high risk of breaking existing functionality. This risk is especially important because it's a core feature of the software. It would require significant effort in the testing process, adding to the overall development workload.

I’d rather invest the same development time and effort into achieving something more significant, like feature #324, which falls under the "Big features" category in the roadmap.

Don't worry, I will try to fix this bug. It just won't have the same priority I initially thought. When I have time and fewer important features to work on, I'll likely get to it.

[gileli121]

After thinking about it further, I decided to add #408 under a new list: Non easy bugs, better to be fixed (nice to have)