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 781796 - Modern fullscreen multitasking with split window for GNOME (Add a “distraction free” mode)
Modern fullscreen multitasking with split window for GNOME (Add a “distractio...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: window-management
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-04-26 19:43 UTC by AGS
Modified: 2021-07-05 14:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
SVG formatted graphic describing distraction free mode (233.40 KB, image/svg+xml)
2017-04-26 19:43 UTC, AGS
Details

Description AGS 2017-04-26 19:43:46 UTC
Created attachment 350503 [details]
SVG formatted graphic describing distraction free mode

When a user maximizes a window [1] in macOS it pushes the top bar out of the way and creates it's own workspace. In this mode the user can drag another window into this workspace and have a side-by-side split [2], the user can even grab the partition and realign the split. This window handling is extremely useful for coding and other intensive tasks where there’s a need to minimize distractions. It also makes apps just look and feel better when maximized.

Here's my proposal for how this could be implemented in GNOME and I've included an attachment with a graphic that shows how this could look:

- User maximizes window and it moves itself into a new workspace. 
- In this workspace the top shell panel is hidden and reveals itself if the user applies pressure to the top area of the screen. 
- If the app has a plain titlebar it is removed. 
- In the app has a headerbar it is always visible and is positioned at the very top of the screen.
- When the user drags it out of the workspace the app will unmaximize.

When the user snaps apps in side-by-side split mode the following apply:

- User snaps windows in split mode the apps are treated as if they are maximized so the rules above apply for maximized windows.
- There's a separator handle in the partition between the two apps that allows the user to drag the alignment of the split.

If there's no way to distinguish between plain titlebars and headerbars in Mutter/Wayland then that might make it difficult to determine what rule to apply. Another added complexity could be Qt applications or those written in other toolkits like Intellij and Eclipse. In those cases the default for non-GTK apps could be to remove the titlebar when maximized. 

One more consideration would be for the close/minimize buttons on the titlebar and where that button goes when the app is maximized. Perhaps these could go in the app menu in the panel when the app is maximized.

[1] https://support.apple.com/kb/PH18744?locale=en_US
[2] https://support.apple.com/en-us/HT204948
Comment 2 Alejandro HC 2017-04-26 21:49:03 UTC
+1 sounds really good.
Comment 3 Allan Day 2017-04-27 15:12:48 UTC
(In reply to Florian Müllner from comment #1)
> Related:
> https://bugzilla.gnome.org/show_bug.cgi?id=676832
> https://bugzilla.gnome.org/show_bug.cgi?id=695352

The main thing that I can see in this bug that isn't covered by these two is being able to drag side-by-side windows to resize them. I thought that we had a bug for this, but I can't find one.

I think it's important not to confuse maximize and fullscreen - they are different things. The relevant design page is:

https://wiki.gnome.org/Design/OS/WindowStates
Comment 4 Florian Müllner 2017-04-27 15:22:46 UTC
(In reply to Allan Day from comment #3)
> The main thing that I can see in this bug that isn't covered by these two is
> being able to drag side-by-side windows to resize them. I thought that we
> had a bug for this, but I can't find one.

Of course we do:
https://bugzilla.gnome.org/show_bug.cgi?id=645153
Comment 5 AGS 2017-04-27 22:15:41 UTC
(In reply to Allan Day from comment #3)
> (In reply to Florian Müllner from comment #1)
> > Related:
> > https://bugzilla.gnome.org/show_bug.cgi?id=676832
> > https://bugzilla.gnome.org/show_bug.cgi?id=695352
> 
> The main thing that I can see in this bug that isn't covered by these two is
> being able to drag side-by-side windows to resize them. I thought that we
> had a bug for this, but I can't find one.
> 
> I think it's important not to confuse maximize and fullscreen - they are
> different things. The relevant design page is:
> 
> https://wiki.gnome.org/Design/OS/WindowStates

You're right I should have used the term 'fullscreen' in my description as they are different. The built-in fullscreen mode of most apps including GNOME core apps already removes the titlebar and hides the headerbar. The "distraction free" mode enhancement is only relevant for fullscreen windows.

Here's an updated enhancement description:

- In the activities overview the user snaps two fullscreen windows into side-by-side split mode by dragging the windows together.
- The user is able to resize the split by dragging a separator between to the two app windows.
- User can undo the split by exiting fullscreen mode or dragging the windows apart in the overview. 

Many apps suspend compositing in fullscreen mode but this enhancement is largely for productivity apps that don't need this. Would this require a new policy or a way to control this on a per-app basis? When running in Wayland is this even relevant?
Comment 6 Allan Day 2017-04-28 12:35:29 UTC
(In reply to AGS from comment #5)
... 
> - In the activities overview the user snaps two fullscreen windows into
> side-by-side split mode by dragging the windows together.
> - The user is able to resize the split by dragging a separator between to
> the two app windows.
> - User can undo the split by exiting fullscreen mode or dragging the windows
> apart in the overview. 

I don't understand why this would be specific to fullscreen windows.
Comment 7 AGS 2017-04-28 20:41:05 UTC
(In reply to Allan Day from comment #6) 
> I don't understand why this would be specific to fullscreen windows.

The default way that macOS handles “maximize” is to fullscreen the window and move it into an “app workspace”. Maximize is a fallback behavior in macOS for older apps that aren’t fullscreen capable. You can force a maximize by holding <alt> and then clicking the window titlebar. 

Fullscreen creates a workspace for each fullscreen app:

Laptop screen: [virtual desktop 1] [ fullscreen app A ] ← two workspaces
Monitor: [ virtual desktop 2 ]  [ fullscreen app B ] [ fullscreen app C ] ← three workspaces

GNOME users frequently install extensions like “Hide Top Bar”, “Maximus NG” or “Pixel Saver” to approximate “distraction free” mode with maximized windows. What’s interesting is that the default fullscreen behavior in GNOME already has this kind of functionality already built in and does it far better.

Current fullscreen in GNOME:

- App window is expanded to fill the entire screen space.
- Titlebars and borders are removed from the window.
- Headerbars are hidden or remain visible and this depends on how the app handles fullscreen.
- Top panel is removed.

The enhancement would extend fullscreen functionality so that:

- Fullscreen windows form their own “app workspaces” that are separate from “virtual desktops” with a visual cue like an icon so the user can tell the difference.
- User can snap together fullscreen apps side-by-side by dragging an app window into an existing “app workspace”.
- User can realign the split between these fullscreen windows by grabbing a separator between these windows.
Comment 8 Allan Day 2017-05-02 13:26:40 UTC
(In reply to AGS from comment #7)
...
> The enhancement would extend fullscreen functionality so that:
> 
> - Fullscreen windows form their own “app workspaces” that are separate from
> “virtual desktops” with a visual cue like an icon so the user can tell the
> difference.
> - User can snap together fullscreen apps side-by-side by dragging an app
> window into an existing “app workspace”.
> - User can realign the split between these fullscreen windows by grabbing a
> separator between these windows.

Fullscreen mode is typically for immersive activities where you don't want window chrome in the way - such as viewing a video, watching a slideshow, playing a game.

Side-by-side windows are generally when you want to work with two windows at once - for example, writing a document while reading another.

While the two cases might overlap - you might want to use two windows at once and have an immersive experience - my impression is that that's generally not the case.

It's worth remembering that window management is somewhat different on Mac - they don't use maximize in the same way that we do.
Comment 9 AGS 2017-05-03 05:05:25 UTC
(In reply to Allan Day from comment #8)
> Fullscreen mode is typically for immersive activities where you don't want
> window chrome in the way - such as viewing a video, watching a slideshow,
> playing a game.

Fair enough, "distraction free" mode focuses on productivity scenarios so it's an optimization of the current maximize behavior. 

In my attempt to simplify this as much as possible enhanced maximize would:
- Hide the top panel which could be revealed with a swipe gesture or mouse pressure to the top of the screen.
- Remove legacy titlebars, unfortunately not all apps have moved to headerbars yet!
- Provide a way for the user to adjust the split when maximized windows are in side-by-side mode.

Also wanted to include something I saw on the Fedora Desktop mailing list:

> From: Jiri Eischmann
> User's Feedback
> last week I asked on my Czech blog what people are missing on the Linux
> desktop, mainly Fedora Workstation. It was picked by all major Czech
> Linux sites and received literally hundreds of responses. I went
> through them and created a summary for you. Some of it are well-known
> issues/features, some points were new to me. If something is not clear,
> just let me know and I'll be happy to explain it:
> (...)
> * When you use one of the tiling gestures you then can't change the
> size of the tiled window.

https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/SG5UPFMQWXMCRVGGGWBKAOCM3PDKUNDX/
Comment 10 Allan Day 2017-05-05 09:03:38 UTC
(In reply to AGS from comment #9)
> (In reply to Allan Day from comment #8)
> > Fullscreen mode is typically for immersive activities where you don't want
> > window chrome in the way - such as viewing a video, watching a slideshow,
> > playing a game.
> 
> Fair enough, "distraction free" mode focuses on productivity scenarios so
> it's an optimization of the current maximize behavior. 
> 
> In my attempt to simplify this as much as possible enhanced maximize would:
> - Hide the top panel which could be revealed with a swipe gesture or mouse
> pressure to the top of the screen.
> - Remove legacy titlebars, unfortunately not all apps have moved to
> headerbars yet!

I'm confused. This sounds like you're trying to turn maximization into fullscreen. That's a different proposal from the one at the beginning of this bug report.

Given that maximized is the standard window state for many applications, it wouldn't make sense to hide the top bar and title bar. People will not be happy to lose a lot of their window close buttons.

> - Provide a way for the user to adjust the split when maximized windows are
> in side-by-side mode.
> 
> Also wanted to include something I saw on the Fedora Desktop mailing list:
> 
> > From: Jiri Eischmann
> > User's Feedback
> > last week I asked on my Czech blog what people are missing on the Linux
> > desktop, mainly Fedora Workstation. It was picked by all major Czech
> > Linux sites and received literally hundreds of responses. I went
> > through them and created a summary for you. Some of it are well-known
> > issues/features, some points were new to me. If something is not clear,
> > just let me know and I'll be happy to explain it:
> > (...)
> > * When you use one of the tiling gestures you then can't change the
> > size of the tiled window.
> 
> https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.
> org/message/SG5UPFMQWXMCRVGGGWBKAOCM3PDKUNDX/

As already stated, that's bug https://bugzilla.gnome.org/show_bug.cgi?id=645153.
Comment 11 AGS 2017-05-05 11:45:30 UTC
(In reply to Allan Day from comment #10)
> I'm confused. This sounds like you're trying to turn maximization into
> fullscreen. That's a different proposal from the one at the beginning of
> this bug report.
> 
> Given that maximized is the standard window state for many applications, it
> wouldn't make sense to hide the top bar and title bar. People will not be
> happy to lose a lot of their window close buttons.

Sorry for the confusion, I misinterpreted your comments about fullscreen and I'm providing some background as to why fullscreen is relevant here.

Maximize in GNOME is a legacy window state that's remained unchanged since GNOME 2. Platforms like macOS, Android and iOS utilize more modern ways of creating a "distraction free" mode. Like I stated earlier in the bug comments in macOS they've even gone so far as to make fullscreen the primary "maximization" state for most apps in a way deprecating the older "maximize". 

I'm not suggesting the existing maximize in GNOME should be deprecated but that fullscreen be enhanced.

In macOS side-by-side split view [1] is achieved with two fullscreen apps and the split is resizable. This is identical to how multitasking works in both Android [2] and iOS [3]. Here is a feature comparison of all three platforms:

* macOS: Split View in OS X El Capitan or later lets you fill your Mac screen with two apps, without having to manually move and resize windows.

* iOS: On iPad, you can use Multitasking to work with two apps at the same time, answer emails while watching a video, switch apps using gestures, and more.

* Android: Android 7.0 adds support for displaying more than one app at the same time. On handheld devices, two apps can run side-by-side or one-above-the-other in split-screen mode. On TV devices, apps can use picture-in-picture mode to continue video playback while users are interacting with another app.

The enhancement calls for GNOME to have fully modern multitasking capability with two fullscreen windows. This is what users are trying to achieve when they use various shell extensions that remove titlebars and the top panel. If you look at my enhancement below it's nearly identical to the multitasking features stated above:

> - Fullscreen windows form their own “app workspaces” that are separate from “virtual desktops” with a visual cue like an icon so the user can tell the difference.
> - User can snap together fullscreen apps side-by-side by dragging an app window into an existing “app workspace”.
> - User can realign the split between these fullscreen windows by grabbing a separator between these windows.

Now I want to further explain what I mean by "app workspaces". If an app is fullscreen it should move into a new workspace. This workspace is solely for the use of that fullscreen window or two fullscreen windows if the user is multitasking. This is useful for users on hybrid and convertible devices where it's more natural to swipe to change workspaces rather than use something like alt-tab.


[1] https://support.apple.com/en-us/HT204948, Use two Mac apps side by side in Split View
[2] https://support.apple.com/en-us/HT207582, Use Multitasking on your iPad
[3] https://developer.android.com/guide/topics/ui/multi-window.html, Multi-Window Support
Comment 12 AGS 2017-05-13 04:41:36 UTC
After reviewing the bug report "make windows resizable by window-border-drag when in half-fullscreen-snap-mode" [1] I noticed the following comment by Florian Mullner:

> 1. one window tiled at the bottom of the stack and another tiled at the top are tied together, > independent from the number of "normal" windows in between
>
> 2. two tiled windows at the top of the stack are not tied together if the first one has been
> resized before the second one has been tiled
>
> I think it makes more sense to always tie windows together if they are "stack neighbors" (that > implies that when resizing a tiled windows to 2/3, a newly tiled window should take up 1/3). I > think using actual "neighbors" is probably good enough, we can always get fancier at a later
> point (e.g. tie windows together if they appear to be neighbors, i.e. normal windows "between" > them are fully covered by the first tiled window)."

A fullscreen window should move to it's own workspace to avoid these sort of complex situations and guarantee that split windows are always "stack neighbors". There's already a bug titled "Give each full screen window its own special workspace" [2] that mentions this approach. There should be a limit of 1 fullscreen window or 2 split fullscreen windows per workspace.

Additionally the following rules should apply:

- When a user attempts to drag a window into a workspace with a single fullscreen window they form a split.
- When a user attempts to drag a window into a workspace with two split fullscreen windows it is bounced down the next available workspace.
- When a single fullscreen window is brought into a normal state it should remain in the workspace it's in.
- When one of a pair of fullscreen split windows is brought into normal state it should bounce to the next workspace.

There should be a visual cue such as a fullscreen icon next to workspaces that have a fullscreen window or pair of split fullscreen windows. The workspace should glow red or have a slight red outline to indicate an operation is not possible according to the rules above.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=645153#c29
[2] https://bugzilla.gnome.org/show_bug.cgi?id=676832
Comment 13 GNOME Infrastructure Team 2021-07-05 14:41:09 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.