After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695352 - Allow fullscreen apps to show/hide the top panel
Allow fullscreen apps to show/hide the top panel
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 742108 749285 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-03-07 12:12 UTC by Bastien Nocera
Modified: 2021-07-05 14:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2013-03-07 12:12:13 UTC
When maximised on the screen that includes the top panel, it should be possible for the application to show/hide the top panel along with any of its own chrome.

Currently, a video player would have at least 2 separate but closely related modes for which the interaction is not sufficiently different to the user that it would be hard to explain.

The maximised mode:
https://github.com/gnome-design-team/gnome-mockups/blob/master/videos/videos-fullscreen.png
The fullscreen mode:
would be the same, but without the top panel

Instead of having 2 separate modes where the only difference is the presence of the top panel, applications should be able to show/hide the top panel (really, put it behind the application window like in fullscreen, or in front like when maximised).
Comment 1 Allan Day 2013-03-07 12:16:22 UTC
We also have some notes here:

https://live.gnome.org/GnomeOS/Design/Whiteboards/WindowStates
Comment 2 drago01 2013-03-08 23:21:14 UTC
So I have read that bug like 4 times and still don't understand what problem you are trying to solve.

Do you want to hide the panel and your chrome while being maximized? Where is the difference from just using full screen here?

Do you want to show the panel on top of your fullscreen app? Why? this pretty much always looks bad / broken ...
Comment 3 Florian Müllner 2013-03-08 23:49:53 UTC
As I understand it, the bug is about the "Overlay" window state in the design linked in comment #1. I think I'd prefer a window property to explicit show/hide methods, but in any case my main question would be how to coordinate size/position of the shell's top bar with the application's overlay chrome - in particular if we want to slide in the top bar rather than just popping it up.
Comment 4 Bastien Nocera 2013-05-28 15:13:14 UTC
(In reply to comment #3)
> As I understand it, the bug is about the "Overlay" window state in the design
> linked in comment #1. I think I'd prefer a window property to explicit
> show/hide methods, but in any case my main question would be how to coordinate
> size/position of the shell's top bar with the application's overlay chrome - in
> particular if we want to slide in the top bar rather than just popping it up.

We currently instantly show the overlays. For me, the top bar would still be there, but under the fullscreened window, and when the window property changes ("fullscreen popup shown") the topbar would be shown above. The application (or a GTK+ widget) would use the workarea API to figure out where to put the overlay.
Comment 5 Allan Day 2013-08-27 23:03:04 UTC
*** Bug 696914 has been marked as a duplicate of this bug. ***
Comment 6 Allan Day 2013-08-27 23:04:02 UTC
We ought to consider how the hot corner should work as a part of this. It might make sense to disable it while the top bar is hidden.
Comment 7 drago01 2013-08-28 05:58:00 UTC
(In reply to comment #6)
> We ought to consider how the hot corner should work as a part of this. It might
> make sense to disable it while the top bar is hidden.

Just for the record we do disable it in fullscreen applications. Which works well in most cases. The only case where it is annoying is when using gnome-documents maximized because it fullscreens itself without being asked to (which is a different bug) but if apps decide to use the hide topbar mode without an explicit user action we would just add more of this annoyance.
Comment 8 Bastien Nocera 2014-01-26 00:55:24 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > We ought to consider how the hot corner should work as a part of this. It might
> > make sense to disable it while the top bar is hidden.
> 
> Just for the record we do disable it in fullscreen applications. Which works
> well in most cases. The only case where it is annoying is when using
> gnome-documents maximized because it fullscreens itself without being asked to
> (which is a different bug) but if apps decide to use the hide topbar mode
> without an explicit user action we would just add more of this annoyance.

It would actually be less annoying, because showing the app's overlays would enable the hot corner.
Comment 9 Florian Müllner 2015-03-19 00:02:20 UTC
*** Bug 742108 has been marked as a duplicate of this bug. ***
Comment 10 Bastien Nocera 2015-05-13 11:05:52 UTC
*** Bug 749285 has been marked as a duplicate of this bug. ***
Comment 11 Bastien Nocera 2015-05-13 11:07:06 UTC
Bug 749285 was one of the use cases for that feature, showing battery information while "in the video player".
Comment 12 Bastián Díaz 2015-05-22 05:09:10 UTC
A desired behavior would be similar to that obtained with the extension "hide top bar" activating the option, "When mouse panel show Approaches edge of the screen" (in full-screen applications only).

Currently the only application that displays the top panel in full screen mode is cheese, however, is very confusing.

Edge pressure and auto-hide top bar its a good choice.
Comment 13 GNOME Infrastructure Team 2021-07-05 14:18:55 UTC
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.