Fullscreen, can't switch to other windows (#262)

[Forestidia86]

Issue #262 on github

mobius discovered that (for an older Lix version) on Win when in fullscreen Lix remains on the screen (like a background screen image) when tabbing out and you cannot get to other windows.

My observations concerning v. 0.9.7 (I really hope they are accurate since it really behaves odd and particular):
- Hardware fullscreen seems to behave as expected, i.e. doesn't have this issue, i.e. lets you switch to other windows and minimizes.
- Software fullscreen:
a) If you press Win key you get the task bar but cannot switch to other tabs by clicking on them and Lix remains on the screen in the background. You can though open program windows with the popping up Start menu but only in its activation via Win key but not if you click on the Start menu button (Win 7). If you opened such another window you can actually switch by clicking on tabs until you focus Lix again.
b) If you press Alt+Tab you can get to other open windows and can change to other windows but Lix remains on the screen in the background unless you explicitly choose desktop and clicking on any other window then seems to bring Lix in the background again.

[Simon]

Thanks, good feedback! Excellent idea to try both hardware and software fullscreen. I always encourage software fullscreen over hardware fullscreen, I'd like to make software fullscreen behave nice. I'm okay with hacks once the problem is specific enough.

a) If you press Win key you get the task bar but cannot switch to other tabs by clicking on them and Lix remains on the screen in the background.

This symptom agrees with mobius's earlier feedback from 2017-11-18, although he had the symptom with Alt+Tab, didn't try Win key.

Interesting that focussing other windows re-enables the taskbar. Do these windows overlap Lix as desired?

b) If you press Alt+Tab you can get to other open windows and can change to other windows but Lix remains on the screen in the background

I'll denote by W the non-Lix window that we choose with Alt+Tab.

What do you mean with "background" here?
b1) "background" means (Lix is not focussed, nonetheless Lix overlaps W), or
b2) "background" means (Lix is not focussed, and W overlaps Lix)?

mobius's symptom was b1), "the other windows don't visually appear".

unless you explicitly choose desktop and clicking on any other window then seems to bring Lix in the background again.

Does this mean: If we explicitly choose desktop during Alt+Tab, then Lix minimizes? Then, after Lix is minimized, you click on the taskbar on W, then Lix un-minimizes? Does at least W overlap Lix now?

-- Simon

[Forestidia86]

I have attached two pictures for a demonstration what I mean with Lix is like a background screen image.
Background can mean both cases, the ones where you can make windows overlap and where not, that's a point for itself though probably connected from a technical viewpoint.

What often happens if you hit the Win key when a program is in fullscreen is that it just minimizes, vanishes completely to its tab in the task bar (, what happens with hardware fullscreen-Lix). But (software fullscreen-)Lix just stays there fullscreen in the background even in the cases where you can focus/put in the foreground/make visually appear other windows. (As I indicated for the Win key there are even cases where like mobius with the old version windows don't even visually appear if you try to focus them.)

If you press Alt-Tab and choose Desktop it seems to look like Lix has minimized but I'm not even sure if this is really minimizing since Lix appears in the background again once you go to another window. This other window is visible, overlaps.

(I've just noticed that fullscreen Firefox behaves similiar to Lix (stays background image when Win key is hit or Alt-Tabbing to other window than Desktop) though much more mildly: You can make appear other windows by clicking on the task bar and if you've chosen Desktop with Alt-Tab then it doesn't come back by itself when choosing other windows. From my experience nevertheless rather rare behavior (though I generally don't use fullscreen). Maybe that has really to do with the difference between hardware and software fullscreen in general?) 

[ccexplore]

Hardware fullscreen traditionally (at least on Windows) grants the program using it more exclusive access to the display hardware, in such a way that the fullscreen window cannot coexist with other application windows (in fact, in the old days games utilizing hardware fullscreen often also changes the display resolution from the normal setting).  So the system really has no choice but to minimize the window (and potentially switch display resolution back to normal settings) when switched away, because it is simply not possible for the fullscreen window to even be displayed correctly when the system has to display other application's windows.  The minimize-on-switch-away for hardware fullscreen is thus actually more of a side effect.

Software fullscreen I think typically just means the software itself position and sizes the window in such a way that it covers up the full screen.  How it handles occupying portions of the display normally set aside for things like the taskbar may vary depending on OS support.  For example, one possibility is to make the window an "always-on-top" window (which makes it always displayed over other overlapping windows not also marked as such).  But "always on top" really means that and so unless the software turns that off upon being switched away, the window can continue cover up other application windows.  The OS may also provide other ways to facilitate software fullscreen that work less bluntly than an always-on-top window.  Behaviors like minimize-on-switch-away may or may not be automatic again depending on how exactly the fullscreen-like behavior is achieved and managed by the software.

It may seem obvious that fullscreen programs should always automatically minimize on switching away, but considering use cases including potentially multiple monitors, there are at least some use cases for some programs where it is not necessarily the desired behavior.  That said, when it comes to Lix I think there's little dispute that you're probably almost always better off having it automatically minimize when switching away to another program.  Or at least it would make sense as the default of a user setting.

[Forestidia86]

Thanks, ccexplore, for explaining.
Yeah, using the Win key to minimize always felt irregular and seems more like an escape method to get out of the program. (That's why I almost never use fullscreen when I have a choice since I want to be able to change windows easily.)

Reading Simon's question and my answering post again, I think I actually haven't answered the questions. (But they were hard to understand for me since from my viewpoint window (merely) overlapping fullscreen doesn't seem desirable in the first place.)

Alt-Tabbing to another window generally leads to an overlapping of that other window with Lix, i.e. you can use that other window and it gets visible as you can see in lixfull2.png. So insofar you get the desired results with this method.

Using the Win key: Clicking on other tabs on the Taskbar doesn't seem to produce visible/overlapping windows (at least for me). But if you use the Start menu as is activated by the Win key (without clicking on the Taskbar beforehand) then it can be possible to produce visible/overlapping windows. If you have produced such a window, even clicking on the Taskbar seems to work in this respect again.

(You can always start other programs (and see them pop up in the Taskbar as tabs), but their windows are not always visible/are sometimes in the background as explained above.)

I actually don't know how to explain that better. I actually haven't fully understood myself under what conditions exactly you can produce overlapping/visible windows. The general rule seems to be: Using keys in the first place to get to other windows brings you in a state where you can produce overlapping windows generally (even by clicking on the Taskbar) but using in first place the mouse to click on the Taskbar generally denies you such a state.

(But as explained above in almost all cases Lix remains a background image.)

[Simon]

Thanks, ccx, for the detailed explanation and Forestidia for the good research. Yeah, with "overlapping", I meant "is visible in front of".

mobius still has his issue in 0.9.7, but he deems it a minor issue.

Allegro doesn't expose API to minimize the window. I can react in the Lix code to losing focus, but I don't seem to be able to request minimization. I should research more for how typical Allegro 5 programs handle this.

-- Simon

[Forestidia86]

Well with hardware fullscreen you actually should be able to have the desired results (minimizing), so that would be a workaround for people that absolutely want this behavior at the moment. (I personally don't have this issue since I'm using windowed mode anyways.)

[ccexplore]

Using the Win key: Clicking on other tabs on the Taskbar doesn't seem to produce visible/overlapping windows (at least for me). But if you use the Start menu as is activated by the Win key (without clicking on the Taskbar beforehand) then it can be possible to produce visible/overlapping windows. If you have produced such a window, even clicking on the Taskbar seems to work in this respect again.

Yeah, this is probably the most mysterious behavior for me.  If always-on-top was being used to achieve the fullscreen effect, I can see it causing other application windows to be obscured, but then I can't quite see how using the Start menu somehow changes things so that it no longer obscures other windows.  So it's perhaps not done that way.

I think Lix also does mouse capturing which may have some role to play in causing some of the symptoms (eg. maybe that's why clicking on the application icons on the taskbar didn't seem to work, if the input is still being captured and directed to the Lix window), though I thought in Windows it's supposed to release the capture once you switch away to another application.  Unless it doesn't count yet when you bring up the Taskbar via the WIN key?

Anyway, it sounds like Simon wasn't doing anything unusual or out of the way to cause such behaviors, so I suspect this could be a common-ish issue for Allegro 5 on Windows, hopefully with some useful mitigations already known.  And ultimately there is the fallback to hardware fullscreen or windowed modes.

[Forestidia86]

I think Lix also does mouse capturing which may have some role to play in causing some of the symptoms (eg. maybe that's why clicking on the application icons on the taskbar didn't seem to work, if the input is still being captured and directed to the Lix window), though I thought in Windows it's supposed to release the capture once you switch away to another application.  Unless it doesn't count yet when you bring up the Taskbar via the WIN key?

The capture only seems partly removed when pressing the Win key:
a) You get a duplication of cursor: the Lix crosshair and the normal Win cursor,
but if you move the (Win) cursor, both move simultaneously (at least when on the Lix "plane").
b) It is actually quite hard to click on the Taskbar without refocussing Lix.
c) Clicking on the Taskbar seems to reunite the cursors for (at least) when not over the Taskbar but over the Lix "plane".

(That's actually quite similiar in windowed mode (apart from b) generally) though there it is nevertheless a way to effectively free the mouse.)

Edit:
- The shortcut Win+m ("Minimize all windows") brings the Taskbar and lets you produce overlapping windows by clicking on the tabs (but Lix remains on background/doesn't minimize).
- The shortcut Win+d ("Show desktop") gets you to the Desktop but if you open another window Lix gets on the background again. (Basically the same as with Alt+Tab and choosing Desktop.)

[ccexplore]

Ok, I had researched further via Google but sadly, it doesn't seem like Allegro 5 have any support for the programmer to minimize the window.  I did manage to find a thread that seem to show the history of how "software fullscreen" came to be in Allegro 5.  Interestingly, Firefox's fullscreen mode was alluded to as an example of how that mode would behave.

This page seems to show the implementation of display management in Allegro 5 on Windows.  Skimming through it, from what I can tell it does turn out they use the topmost option together with sizing/positioning the window and hiding the taskbar (with a method that looks suspiciously hacky, though I can't say I'm an expert in this) to achieve the fullscreen effect.  They also hooked into system events around the window being switched into and away in order to play nice (eg. unhide the taskbar and turn off topmost upon detection of being switched away).  It doesn't seem to minimize though and as I said, there seems to be no support either for the programmer to tell Allegro 5 to minimize the window.  Given that they may have modeled things after Firefox's fullscreen mode, it may even all be behaving "as intended" (whether it works well for the end user is another matter, clearly).

So I suspect it'll probably not be possible for Lix to do what you want in software fullscreen, without further updates being pushed out to Allegro 5 itself, or unless we start incorporating platform-specific native calls to Windows APIs outside of using Allegro to achieve the operation lacking support in Allegro 5.

I'm actually less concern about the fact the "Lix remains in the background" even after you finally successfully switched into another window.  If you think about it, that is no different from the behavior you get when you switch via Alt+Tab or Taskbar away from a maximized window (eg. your browser window, probably) to some other window, the old window doesn't automatically minimize as a result of such an action.  I'm more concern with the report that Lix/Allegro5 may somehow be interfering with usage of the Taskbar (so you can't easily switch to another window without some additional fiddling around) during a switch-away attempt.  It doesn't seem like the current implementation of software fullscreen in Allegro 5 should be leading to such an effect, more investigation will be needed to understand if that specific problem may be caused by Allegro 5 vs something Lix is doing.

[Forestidia86]

Thanks for your research, ccexplore.

I'm actually less concern about the fact the "Lix remains in the background" even after you finally successfully switched into another window.  If you think about it, that is no different from the behavior you get when you switch via Alt+Tab or Taskbar away from a maximized window (eg. your browser window, probably) to some other window, the old window doesn't automatically minimize as a result of such an action.  I'm more concern with the report that Lix/Allegro5 may somehow be interfering with usage of the Taskbar (so you can't easily switch to another window without some additional fiddling around) during a switch-away attempt.  It doesn't seem like the current implementation of software fullscreen in Allegro 5 should be leading to such an effect, more investigation will be needed to understand if that specific problem may be caused by Allegro 5 vs something Lix is doing.

I don't want to push it that much further from my side since it is not even my problem and is deemed as minor by the one that is actually hit by it.  (Actually sorry, if I'm taking away energy/attention from other issues that are much more important.)
But the point with minimizing is that there seems to be no good way to minimize software fullscreen-Lix. Even if it looks like that with Alt-Tab+choose Desktop or Win+d it still pushes itself back.
Firefox fullscreen minimizes with Win+m and if you go to the top of the screen with the mouse it even shows the window bar again where you have the option to minimize or restore the window status. Apart from that you can deactivate it with pressing the key that activates it. That is much more mildly than it is with Lix (at least for me).

[Simon]

I closed the github issue because other windows can overlap Lix and are then visible.

Winkey, then click on other task in taskbar; expected switch to other task, observed Lix eats the mouse cursor and stays active: This might be connected to how I trap the mouse in Lix.

If Forestidia or anybody else is willing to try random things in the code on Windows: Go to src/hardware/mouse.d, replace all occurrences of _trapMouse = b; or _trapMouse = true; with _trapMouse = false;. Compile and see if the Winkey behavior changes. Or join IRC, I'll walk you through it.

-- Simon

[Forestidia86]

I have attached my modified src/hardware/mouse.d, so that you can look if I did everything right.

It hasn't helped. Clicking on the Taskbar after Win key is really a problem since it even prevents Alt-Tab from working. You have to refocus Lix that it works again. (It is as if clicking on Taskbar after Win key leaves Lix in its always on top state.)

[Forestidia86]

I've tested on the newer laptop (Win 8.1) and there are no Taskbar problems as it seems.
So either it is something with my old laptop or Win 7 that causes this problem, so it is in the end only very specific.

[Simon]

Yep, your attached mouse.d is exactly what I suggested.

Thanks for the exhaustive tests. Interesting that it behaves so differently on Win 7 vs. Win 8. Excellent idea to test on both systems!

Maybe I shouldn't worry until I get fresh complains. I've always encouraged to leave the game with Alt+Tab, which seems to work reasonable enough without introducing native Windows API calls in the Lix code.

-- Simon