AltSnap
AltSnap copied to clipboard
RamonUnch
Program windows open behind tray
Screenshot:
AltSnap version 1.57, running on Windows 10 Pro - 21H2 (2009: 19044).
You mean you would prefer the window to pop up in front of the extended tray menu? EDIT: I am not sure this can be done or even if it should be done. taskbar is supposed to be topmost, I would not want to start a topmost war. It also seems the dialog is too low, the OK/Cancel/Apply buttons should not be hidden behind the taskbar.
You mean you would prefer the window to pop up in front of the extended tray menu?
I do, yes.
Other programs put their windows above the extended tray menu. For instance, here is the Eset anti-malware programme:
Or again, here is the Everything search engine:
Here is a program that I wrote with the 'Autohotkey' scripting language - and I don't think I changed any of that language's defaults:
Those are just context menu, not config dialogs, Does AltSnap's tray menu works properly? PS: I realize that they are similar concepts, but context menu by default are topmost because they only appear very temporarily.
Those are just context menu, not config dialogs
True. So let me adjust my point - to the following.
Let 'ET' be the extended tray. In the case of each program x other than AltSnap, when I open a window of x from a context menu within the 'ET', there never results a window that is behind the ET. Rather: if x opens a window w - via my doing something in the ET's context menu - then either (a) w does not overlap the ET, or else (b) the ET closes before w opens. I think that AltSnap's window should do either a or b or else (c) appear atop the ET.
Does AltSnap's tray menu work[] properly?
Yes, except that . . the windows that it opens are behind the extended system tray.
I had overlooked that some applications, aside from AltSnap, do open behind the extended tray. Still, those applications open windows that are large enough that the 'behindness' is not a problem.
[. .] the user wants the AltSnap application window to open in front of (or auto-close) the extended tray. Is that correct?
Yes, it is. (In a way, a third acceptable option would be: open a window sufficiently large that the being behind is not a problem. Yet, the content of the AltSnap window is such that that window cannot really be large.)
@silentbrains
Thank you for your work. Apologies for my unclarities. (I thought that I was being clear when actually I was not.)
It seems to me that you identified what matters here when you wrote as follows.
AltSnap (the application window) doesn't remember its last-opened position so it always opens in the bottom-right corner, ie behind the extended tray. This makes it slightly more laborious to use, since the user must close the extended tray to access any options hidden behind the extended tray
So the important thing is finding some way to avoid that situation.
I suppose that now you are considering which of the various alternatives is best. Here is my view on that matter. AltSnap should close the extended tray (presuming that AltSnap is able to do so). Here is why. We are taking it that the user has opened the extended tray, opened a context-menu for AltSnap, and then launched another AltSnap window from that menu. In such a case, the user is very much focussed upon AltSnap and not upon the tray. So, why not solve the access-to-AltSnap's-window problem by closing the tray?
The simplest solution is to pop the config dialog avoiding overlap with the extended tray. This is very low priority though as it is just a small UI problem.
Also as a note Windows 10 behavior is different than Windows 7's. I have Zero issue with Windows 7, the extended tray pops down as expected. and the config dialog appears exactly in the bottom right corner. So I am not sure what to do on Win10.
That's a Windows (10/11) bug. Microsoft forgot to treat accent activation like mouse click activation, thus you have to wait three seconds in case you are a keyboard user regardless of the application.
