GNOME Bugzilla – Bug 668490
Always show the close button for thumbnails in overview, otherwise we can't close windows on touchscreens
Last modified: 2021-07-05 14:11:08 UTC
Why do we even hide the close buttons in the overview? It's far more touch oriented to leave them visible and it's easier to aim for them if they are visible. It also looks better IMO. Ofc, when dragging or zooming they will be hidden as usual.
Created attachment 205872 [details] screenshot less flickering, better for touch, better looking
(In reply to comment #0) > Why do we even hide the close buttons in the overview? It's the design. My guess is that hiding the close buttons avoids distraction from the primary purpose of the window picker, which is to select a window (not close it - the primary mean to achieve that is to use the "normal" close button outside the overview). Anyway, marking for UI review to get the designers' opinions.
Interesting idea. Agree about touch. There were ambitions to change the thumbnail border and to incorporate a permanent close button there. That didn't happen though. I'd probably want to see bug 665310 fixed first.
I am in favor of a) keeping the close buttons in overview mode and b) showing them all the time, not just on hover I constantly use this feature to quickly close windows. This overview mode with the window names and close buttons are actually a killer feature and the main reason I like Gnome Shell over Ubuntu Unity. In particular if you use Gnome 3.6 and maximized windows, some apps don't have any close buttons (Nautilus, Epiphany) and the only quick way to close those apps is to open the overview mode and click on the close icons. I do realize there is a possibility that somebody closes windows by accident. I just think that the odds of that are quite low. Neither me or any of my family members of friends have complained that it would have happened. So there is no compelling reason to remove those buttons - in contrary, make them permanently visible so that people can discover them easily and that use them also on touch screens! (In general, avoid any hover effects since they don't work then I'm using Gnome on my tablet.)
Safari on iOS show permanent close buttons when viewing open tabs. It looks nice and like I, Allan and Otto said - it's the right thing for tablets.
The current code for showing the close buttons is buggy in 3.7.92. Always showing the close buttons would fix the issues.
(In reply to comment #6) > The current code for showing the close buttons is buggy in 3.7.92. Can you be more specific please? What exactly doesn't work?
In playing around with the close button, I discovered that if you move your mouse slowly over the top right of a window the close button doesn't appear, but you can still click and the window will close. Also, I managed to somehow get break the timer which is supposed to hide the close button after a given amount of time for one window once. Minor bugs, but bugs nonetheless.
*** Bug 691083 has been marked as a duplicate of this bug. ***
*** Bug 664995 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > In playing around with the close button, I discovered that if you move your > mouse slowly over the top right of a window the close button doesn't appear, > but you can still click and the window will close. > > Also, I managed to somehow get break the timer which is supposed to hide the > close button after a given amount of time for one window once. > > Minor bugs, but bugs nonetheless. Yeah I've found similar bugs. Confirm that.
Created attachment 255995 [details] [review] always show the close button for the thumbnails in the overview
Review of attachment 255995 [details] [review]: I don't think we want to always show the border, so you should take the close buttons out of _animateVisible()/_animateInvisible(), but leave the functions alone otherwise (in particular changing all occurrences of _animateInvisible() to _animateVisible() doesn't make any sense, even if we do want to show the borders for all previews - why show something that is never hidden?). Also, please extend the commit message a bit - see http://lists.cairographics.org/archives/cairo/2008-September/015092.html for the preferred format. ::: js/ui/workspace.js @@ -493,3 @@ this._parentActor.raise_top(); - if (this._windowCanClose()) { This test is still needed
we only have title and border animation now, so we can rename CLOSE_BUTTON_FADE_TIME to DECORATION_FADE_TIME for example ?
(In reply to comment #13) is the mentioned test specifically needed in _animateVisible() function? or it can be moved to some other function?
Created attachment 256036 [details] [review] close button for thumbnails appears in the oevrview Close button now appears in the overview even without the hovering. But, the border of thumbnails appears only while hovering. Close button is removed from the function _animateVisible() and _animateInvisible() and placed in the show() function with the rest. Same can be done with the border, if required.
Created attachment 256149 [details] [review] close button appears in the overview close button appears for thumbnails in the overview. suspended close button problem when overview exits is solved.
Review of attachment 256149 [details] [review]: Have to rework commit message. Something like: workspace: Make close button always visible (explanation why we need that) ::: js/ui/workspace.js @@ +355,3 @@ Tweener.addTween(this.title, { opacity: 255, + time: CLOSE_BUTTON_FADE_TIME, unwanted tabs @@ +362,3 @@ + Tweener.addTween(this.closeButton, + { opacity: 255 }); + } you forgot: time: CLOSE_BUTTON_FADE_TIME @@ +507,2 @@ this.title.add_style_pseudo_class('hover'); + this.closeButton.add_style_pseudo_class('hover'); I don't see the needed of this. In fact we don't have window-close:hover pseudo class in the theme. @@ +518,2 @@ this.title.remove_style_pseudo_class('hover'); + this.closeButton.remove_style_pseudo_class('hover'); Same @@ +554,3 @@ this.border.hide(); this.title.remove_style_pseudo_class('hover'); + this.closeButton.remove_style_pseudo_class('hover'); Same
Created attachment 256327 [details] [review] close button for thumbnails always appear in overview. close button is made permanent for a thumbnail in the overview. CLOSE_BUTTON_FADE_TIME is renamed as DECORATION_FADE_TIME as there is no need to fade close-button anymore with the border. and each related function is also renamed accordingly. -const CLOSE_BUTTON_FADE_TIME = 0.1; +const DECORATION_FADE_TIME = 0.1; _onEnter: function() { @@ -536,15 +523,15 @@ const WindowOverlay = new Lang.Class({ return; this._animateVisible(); - this.emit('show-close-button'); + this.emit('show-decoration'); }, _onLeave: function() { if (this._idleToggleCloseId == 0) - this._idleToggleCloseId = Mainloop.timeout_add(750, Lang.bind(this, this._idleToggleCloseButton)); + this._idleToggleCloseId = Mainloop.timeout_add(750, Lang.bind(this, this._idleToggleDecoration)); }, - _idleToggleCloseButton: function() { + _idleToggleDecoration: function() { @@ -1489,7 +1476,7 @@ const Workspace = new Lang.Class({ this.actor.add_actor(clone.actor); - overlay.connect('show-close-button', Lang.bind(this, this._onShowOverlayClose)); + overlay.connect('show-decoration', Lang.bind(this, this._onShowOverlayDecoration)); @@ -1502,12 +1489,12 @@ const Workspace = new Lang.Class({ return [clone, overlay]; }, - _onShowOverlayClose: function (windowOverlay) { + _onShowOverlayDecoration: function (windowOverlay) { for (let i = 0; i < this._windowOverlays.length; i++) { let overlay = this._windowOverlays[i]; if (overlay == windowOverlay) continue; - overlay.hideCloseButton(); + overlay.hideDecoration(); }
Created attachment 256330 [details] [review] Updated Traditional Chinese translation(Hong Kong and Taiwan)
Created attachment 256331 [details] [review] close button appears in the overview close button appears in the overview permanently
Created attachment 256332 [details] [review] close button appears in the overview close button appears in the overview permanently
Comment on attachment 256332 [details] [review] close button appears in the overview Close button now appears permanently for the thumbnails in the overview, so that windows can be closed on touchscreens. IN workspace.js, CLOSE_BUTTON_FADE_TIME is changed to DECORATION_FADE_TIME as close button does not fades with the thumbnail border. Moreover, related function names are also changed accordingly.
Review of attachment 256332 [details] [review]: The commit message needs be reworked with the comments Florian suggested ::: js/ui/workspace.js @@ -311,1 @@ why are you changing that? It is not related to the patch. (and also previous identation was fine) @@ -323,3 @@ - Lang.bind(this, this._onStyleChanged)); - button.connect('style-changed', - Lang.bind(this, this._onStyleChanged)); Same, why are you changing that? It is not related to the patch. (and also previous identation was fine) @@ -501,3 @@ - transition: 'easeOutQuad' }); - } - As Florian said before, this test is still needed.
(In reply to comment #24) > Review of attachment 256332 [details] [review]: > > The commit message needs be reworked with the comments Florian suggested > > ::: js/ui/workspace.js > @@ -311,1 @@ > > > why are you changing that? It is not related to the patch. (and also previous > identation was fine) > > @@ -323,3 @@ > - Lang.bind(this, this._onStyleChanged)); > - button.connect('style-changed', > - Lang.bind(this, this._onStyleChanged)); > > Same, why are you changing that? It is not related to the patch. (and also > previous identation was fine) > > @@ -501,3 @@ > - transition: 'easeOutQuad' }); > - } > - > > As Florian said before, this test is still needed. Didn't see you changed the code to another place sorry, reviewing again
Review of attachment 256332 [details] [review]: ::: js/ui/workspace.js @@ -501,3 @@ - transition: 'easeOutQuad' }); - } - Forget that, you move the code to another place, which is fine.
Created attachment 256357 [details] [review] close button appears in the overview close button appears in the overview permanently close button for the thumbnails always appear in the overview, so windows can be closed on touchscreens.
After designers saw the patch in action, they deciced that looks too much bloated. So we hold on the change until we find a better solution for touch devices. Thanks for your great work pankhuri!
Maybe it will be possible to implement drag to the bottom of the screen, which should close windows?
(In reply to iliyabo from comment #29) > Maybe it will be possible to implement drag to the bottom of the screen, > which should close windows? I find that unintuitive, because there is no easy way to tell the user that this feature exists and how to use it. gnome-initial-setup is just too easy to forget. (In reply to Carlos Soriano from comment #28) > After designers saw the patch in action, they deciced that looks too much > bloated. So we hold on the change until we find a better solution for touch > devices. Bloated? I do not understand. The close buttons are quite small, so that they are easily missed when using a touch screen.
(In reply to Christian Stadelmann from comment #30) > (In reply to iliyabo from comment #29) > > Maybe it will be possible to implement drag to the bottom of the screen, > > which should close windows? > > I find that unintuitive, because there is no easy way to tell the user that > this feature exists and how to use it. gnome-initial-setup is just too easy > to forget. I don't think so. Consider the other touchscreen gestures in Gnome - four-finger swipe (which IMO is harder to figure out than swiping to close if you don't know it exists), not to mention the AppSwitch Action (long-press with 3 fingers and then the fourth to switch). Also many apps for smartphones use similar gesture(android/ios app switcher to remove an app from recents, browsers such as chrome and opera use swipe to close the tab, the Gallery app to delete a photo)
It's fairly clear that "we hold on the change until we find a better solution for touch devices" is not working as an approach to dealing with this, since touch usability on the overview has now been broken for 5 years. Designers, please take actual responsibility for this by either: * signing off on always-visible close buttons, on the basis that you haven't approved any alternative in 5 years; or * proposing and/or approving an alternative. "Touch will be broken in the overview indefinitely, because we don't think it's pretty enough" is a pretty terrible position to have for 5 years. And just for good measure, here's a concrete proposal: * if there is a touchscreen present, and the overview is not launched via the mouse, show all the close buttons for that specific instance (launch of the overview via touch, Super key or hardware "Win" button launch are all legitimate "I might want to use the touchscreen" cases).
(In reply to Stephen from comment #32) > * if there is a touchscreen present, and the overview is not launched via > the mouse, show all the close buttons for that specific instance (launch of > the overview via touch, Super key or hardware "Win" button launch are all > legitimate "I might want to use the touchscreen" cases). I'd go a step further: Always show the close button unconditionally. Even when no touch screen is present. This is way easier to implement and has less code paths, so the code path relevant for touch devices will get more testing.
Ideally, we wouldn't need to change the UI, but we'd have a gesture for that, similar to dismissing open applications on mobile.
> Ideally, Yes, but that's kind of my point. In the interim, basic functionality should be provided, otherwise it could very easily be another 5 years until gesture-based closing actually makes it into a release. I'd propose a commitment to make touch-closing work one way or the other by next release - if a gesture solution isn't merged by then, then make the close buttons available without hover one way or the other (either unconditionally, or per my suggestion.) > similar to dismissing open applications on mobile FWIW, Android provides both gesture- and button-based closing.
What if we show the close buttons after a timeout? Doing so, it doesn't interfere when a user want to quickly select a window. Android does the same in the windows switcher: after you open it, if you don't do anything (e.g., you don't scroll the windows list) it shows the close buttons after few seconds. On a side note, since that currently the windows' title are shown only on hover, we can do the same for the titles. If the user doesn't interact with the overview for a while, we can give her/him more information.
(In reply to Alessandro Bono from comment #36) > What if we show the close buttons after a timeout? Doing so, it doesn't > interfere when a user want to quickly select a window. > > Android does the same in the windows switcher: after you open it, if you > don't do anything (e.g., you don't scroll the windows list) it shows the > close buttons after few seconds. But it also has gestures so users can close applications and not need to wait this time for a close button to appear.
(In reply to Alessandro Bono from comment #36) > What if we show the close buttons after a timeout? Doing so, it doesn't > interfere when a user want to quickly select a window. Always showing the close buttons does not interfere with the user quickly selecting a window. The close button is so tiny in overview mode, that it is very unlikely to accidentally hit it. (In reply to Christian Stadelmann from comment #33) > Always show the close button unconditionally. Even when no touch screen is present. This is way easier to implement and has less code paths, so the code path relevant for touch devices will get more testing. How about that? Any opinions? PS: I'd find it more intuitive to find the close button on first use of gnome-shell if it were displayed by default.
The core problem in regard to this bug is not a lack of good ideas, it's (relative) lack of interest in supporting touch devices properly on the part of core GNOME designers/devs/maintainers (and 3rd-party contributors are unlikely to submit patches given the result of pankhuri's attempt to fix this issue, see above). I'm curious given the long-standing (5 years) half-implemented state touch support why the GNOME Foundation is bothering to endorse Purism's smartphone project: https://puri.sm/posts/gnome-foundation-partners-with-purism-to-support-its-efforts-to-build-the-librem-5-smartphone/
This task is about showing close buttons for thumbnails in the overview. Please move meta discussions about general touch screen support or Foundation endorsing devices to better suited mailing lists: https://mail.gnome.org/ - thanks!
It's still impossible to close a window in overview mode using a touch screen on Gnome 3.34, Arch Linux.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.