GNOME Bugzilla – Bug 693991
fullscreen apps look weird when in the background
Last modified: 2014-10-15 10:27:42 UTC
If I have a fullscreen app and then Alt+tab away from it it looks really bad. One reason for this is that the shell top bar covers part of it. Also, it just looks odd having that window behind everything else. Perhaps we should just not show / hide fullscreen windows when they lose focus. Although I just noticed we now do something weird with "minimized" windows in the overview. We make them harder to see. Odd.
(In reply to comment #0) > Although I just noticed we now do something weird with "minimized" windows in > the overview. We make them harder to see. Odd. Jakub asked for that after landing bug 682887.
(In reply to comment #0) > Although I just noticed we now do something weird with "minimized" windows in > the overview. We make them harder to see. Odd. Indeed I don't think that that makes any sense. When in the overview most users don't care whether a window is minimized or not (that does not mean much; you want to switch to a different window whether it is just in the background or minimized does not matter).
Created attachment 236446 [details] [review] Minimize fullscreen windows when they end up in the background Alt-Tab away from a monitor sized on the primary monitor results into the top panel being displayed on top of the window which looks very bad. So just hide those windows by minimizing them. The icon geometry animation does not really make sense for fullscreen windows so just fade them out.
Created attachment 236447 [details] [review] overview: Don't display minimized windows differently in the overview Making them not fully opaque just makes them harder to see and there is no reason why the user should care whether the window is minimized or not when switching to a window display them like any other windows.
We aren't talking about minimized, but hidden. And it makes perfect sense to me to tone down windows that are hidden.
(In reply to comment #5) > We aren't talking about minimized, but hidden. And it makes perfect sense to me > to tone down windows that are hidden. "Jakub asked for that after landing bug 682887." Huh?
(In reply to comment #6) > (In reply to comment #5) > > We aren't talking about minimized, but hidden. And it makes perfect sense to me > > to tone down windows that are hidden. > > "Jakub asked for that after landing bug 682887." > > Huh? Err ignore that ... I read Florian's comment as "Jakub asked the same"
Trying the patch. I like the fade out but the first time I go to the overview the window is fully transparent. Later it is fine. I am not sure about the hidden thing at all but I guess it is a different bug. The way I think of it is if you hide it - you hide it from the normal view. You don't hide it forever. In the old days we didn't hide windows in the taskbar after you minimized them either.
(In reply to comment #8) > Trying the patch. I like the fade out but the first time I go to the overview > the window is fully transparent. Later it is fine. That's odd I cannot reproduce it (and the opacity is reset in minimizeDone). > I am not sure about the hidden thing at all but I guess it is a different bug. > The way I think of it is if you hide it - you hide it from the normal view. You > don't hide it forever. In the old days we didn't hide windows in the taskbar > after you minimized them either. I agree here I don't see a point in having them look any different in the overview. Still not convinced that you should care about "this is hidden" or not while in the overview.
Created attachment 236562 [details] [review] display: Don't put minimized windows at the back of alt-tab Minimizing a window should not change its position in the alt-tab list.
Review of attachment 236562 [details] [review]: Yes ... much better.
Comment on attachment 236562 [details] [review] display: Don't put minimized windows at the back of alt-tab Attachment 236562 [details] pushed as 7e61ef0 - display: Don't put minimized windows at the back of alt-tab
Created attachment 236649 [details] [review] Minimize fullscreen windows when they end up in the background Alt-Tab away from a monitor sized on the primary monitor results into the top panel being displayed on top of the window which looks very bad. So just hide those windows by minimizing them. The icon geometry animation does not really make sense for fullscreen windows so just fade them out. ---- Cleaned up version, uses new mutter apis.
Review of attachment 236649 [details] [review]: Looks good. ::: js/ui/windowManager.js @@ +300,1 @@ actor.move_anchor_point_from_gravity(Clutter.Gravity.NORTH_WEST); Remind me that we have to remove this :)
Review of attachment 236447 [details] [review]: Deferring to Allan / Jakub / John. Let me know when a decision has been made.
Comment on attachment 236649 [details] [review] Minimize fullscreen windows when they end up in the background Pushed this one (git bz strikes).
<mccann> now, if I'm going to see all fullscreen windows half invisible I'm not going to like it <drago01> Jasper: what's the cause? <drago01> mccann: currently you will ... <mccann> drago01: that is no good <mccann> you're exposing implementation details to the user <mccann> I never said to hide the window really <drago01> ok so we have two choices 1. remove the special case for all windows or 2. add a special case for the fullscreen one ... doing nothing sucks so chose one ;) <drago01> mccann: ^^ <Jasper> aday, jimmac: your input is very valuable, especially considering you guys were the ones who asked for the opacity change <mccann> drago01: 1 then <mccann> but aday and jimmac may want to chime in <aday> i don't remember pushing for this... but making the window less easy to identify does seem like a valid concern <drago01> I'd go for 1 for now <drago01> it is not like it is set in stone <drago01> when we come to a different agreement we can change it Attachment 236447 [details] pushed as 3430012 - overview: Don't display minimized windows differently in the overview
In bug 705177 I provided some use cases in which I believe this patch complicated the user workflow and decreased user experience, rather than the opposite.
Hello! Im no Gnome-developer but Im every day developer, and every day GNOME Shell user with multiple monitors. I just want you to know, that this patch made things worse for me. Every fullscreened app is minimizing automatically against my will when poping up its own dialog, some other window, or when its loosing focus to desktop or other app. Its annoying and confusing. Consider the scenario, when one wants to drag-n-drop a file or dir from Desktop - its impossible now, as the drop target disappears. Moreover, some of the embedded Flash web apps or clips are minimizing the same bad way as soon as they are popped to fullscreen, leaving frozen Desktop, with no option to Alt-tab or click back to them or the parent window (only solution is to switch to another Workspace and back). Honestly, I see nothing wrong or weird having fullscreen app covered by top bar or something else for some period of time, if its not having focus. Please consider removing this behaviour.
One short term fix I'd like to try is restoring the fullscreen window to maximized instead of hiding.
Reopening. This was reverted, so we're back to fullscreen windows looking and acting weird
One specific piece of advice: you cannot track "when a full-screen window loses focus" accurately under X11. There are certain focus modes that prevent us from being able to make an accurate assessment of it. Java, Flash, Skype, VirtualBox and other popular applications and frameworks use these modes, so we can't simply ignore them. Any solution we want to design cannot rely on saying "when a full-screen window loses focus". Keep this in mind.
The following fix has been pushed (after design+code review on IRC): 5664c70 screen: Always consider monitors with fullscreen windows "in-fullscreen"
Created attachment 288547 [details] [review] screen: Always consider monitors with fullscreen windows "in-fullscreen" Fullscreen windows look weird when they are overlapped by system chrome, which currently happens when another window is stacked above. We used to auto-minimize fullscreen windows in that case, which proved to be both unreliable and unpopular. So instead, keep the system chrome hidden even when the fullscreen window is not stacked at the top.
If I understand it correctly, if I watch a full-screen flash video in the background, and then switch to e.g. Empathy, the top bar stays hidden? I wonder, how can I then access the global menu, or Activities, or the user menu, or the language switcher? Can I pull down the bar by applying pressure to the top edge, the same way notification bar works? Maybe it's too late, but what about this idea - if you switch from fullscreen app to a non-fullscreen app, the top bar slowly slides downwards from the top edge, thus appearing into the view. When you switch back to the fullscreen app, it slides backwards up, this disappearing. Would that solve the "looking weird" issue (it was not described anywhere, so I don't really understand what 'weird' means here)? By using that animation, it would be clear that you have switched contexts (fullscreen vs non-fullscreen) and that it changes the chrome visibility. Personally I don't see anything 'weird' if the top bar overlaps a section of some other content, because it's a part of the currently focused application (which also overlaps a section of some other content below it). If the sliding animation helps to explain properly what's happening, why not use that approach instead of disappearing the top bar completely?