GNOME Shell 40 design: how will the horizontal workspaces interact with multi-screen layouts?

First, thank you for working on refining the GNOME Shell user experience for GNOME 40.

As I suspect the “New Shell design (feedback)” thread will quickly become a furball, I am starting a separate thread here to discuss the specific question of workspaces management on multi-head.

For example, I can imagine these screen layout scenarios:

  • Two monitors side-by-side, both horizontal (my current setup)
  • Two monitors side by side, one horizontal and the other vertical (I use this on occasion)
  • Three or four vertical monitors side-by-side
  • Two or three horizontal monitors stacked above each other (I use this on occasion)
  • A “L-shaped” or “T-shaped” arrangement, with one monitor on the side and the third monitor above the primary monitor for example

I did not see mockups & animatics about that, but maybe I did not look in the right place? @allanday, how do you envision the horizontal “filmstrip” workspaces behaving on multi-head setups, whether horizontal, vertical or hybrid?

It sometimes seems to me like multi-monitor setups are a bit of an afterthought (like that crasher I found recently that had flown under the radar for quite a long time because it only happens with some monitor layouts), yet they are worth thinking hard about, especially in the context of a pandemic where remote working and multitasking (with visioconferencing etc.) have redefined many people’s personal productivity needs.

3 Likes

Hey @jfft!

The design team has certainly spoken about multi-monitor and it has been included in some of our early testing, but I think it’s fair to say that the designs aren’t fully fleshed out in that regard.

how do you envision the horizontal “filmstrip” workspaces behaving on multi-head setups, whether horizontal, vertical or hybrid?

We’re just showing the current display as part of the “film strip”. The workspace previews keep the same aspect ratio of that display, so it adapts to vertical orientations.

Where this gets potentially tricky is when workspaces-only-on-primary is set to false, which is more common for setups like yours (two external displays right next to each other). In that case, the literal workspace preview breaks down a bit. It would be nice to have a single preview of the combined workspace from all displays, but I’m not sure how practical that would be.

There’s also a bit of friction using using horizontal transitions when you have multiple displays side-by-side. Though the fact that all the other desktop platforms arrange their workspaces horizontally makes me think that this is something that can be overcome.

Does that make sense?

Hi,

Thanks for your work!

Current redesign has potential for solving a little problematic multi screen situation issue 2644. But showing one combined workspace for all screen will will quickly become cumbersome for people with more than two monitors (think, 2 rows 2 columns). I think this issue can be solved once and for all configurations.

I think showing one preview for one monitor will be much more universal. Monitors always have frames (some are really thin but they are still visible) so there is visual separation between multiple previews.

Tried to visualize this idea on this ugly image. Black lines represents monitor frames. First monitor has favorites bar and top bar rest of monitors have only preview working the same as on first screen.

This way supporting more screens become much easier because having 2 monitors, 3 monitors, 2rows-2cols, 3rows-3cols all configurations will work the same and will still be fully usable. With one combined preview this configurations will become really hard to use, I suppose.

And this idea could work with having independent workspaces per screen issue 37, which would be totally awesome (Pretty please?).

2 Likes

@Aelspire Hey! This looks cool. I was thinking about something similar.

I have for long had some gripes with workspaces-only-on-primary set to false and I think the new design makes it a bit clunkier. However with a change from changing workspace for all monitors at the same time to changing workspace only for one monitor at a time I see quite a potential with the new design.

To start with my work setup is two external screens + the laptop screen in an horiztonal row. My external screens are both used in a primary fashion in that I don’t really have a preference in which one I put what one. But they are often used as one for the code editor or editors and one for running the application I work on or showing documentation (or both at the same time with tiling). The laptop screen either shows slack or my emails.

I would prefer switching workspace for these screens individually so that I could switch between different workspaces for code editors between different subprojects on one screen or showing the application or documentation on the other.

With the design @Aelspire shows, the overview would work great and reusing the design flow for dragging apps between workspaces could work amazingly with for example ctrl+click for dragging whole workspaces between monitors (I quite often want to do this to quickly swap the contents of my two external monitors).

FWIW this is my permanent setup. My main screen (with the black top bar, in front of me) is in portrait and my second monitor (on the right side) is in landscape. I use Multi Monitors Add-On to have workspaces enabled on both monitors, along with their previews. I do think of the combination of the two monitors as a single huge workspace, and I really hope I can keep using it as such.

1 Like

The design team has certainly spoken about multi-monitor and it has been included in some of our early testing, but I think it’s fair to say that the designs aren’t fully fleshed out in that regard.

Oh, maybe I missed something, were there some notes/mockups about that, or those were just informal discussions and open-ended questions?

[…]
Does that make sense?

Well I haven’t been using workspaces-only-on-primary = False personally, but might want to, now that you mention it; but it sounds like the question of how that would work with the new design, particularly for monitors arranged in a vertical or L layout, has not been fleshed out. I don’t know how this ought to be solved (haven’t spent a lot of time thinking about it), I was just prodding to see if you had some ideas for this, or hoping that people here can help come up with ideas otherwise; I’m guessing that in my case, I’d probably only get a feel of the possibilities when I use it in practice, but it doesn’t hurt to bring up the question in advance…

I don’t think I have notes on that particular topic.

For multimonitor, I’d personally break the discussion down like this:

  1. Any multimonitor issues with the new design which the old one doesn’t have
  2. Opportunities to improve multimonitor (unique to the new design)
  3. Opportunities to improve multimonitor (not unique to the new design)

At this point in time, the priority is 1. So far we’ve reviewed it and I don’t think we’ve identified any major issues, but if there was to be something, that’s something we’d need to focus on. I am aware of two minor issues though:

  • Two monitors side-by-side and move workspace right: the desktop on the right slides to the left. It looks like it should appear on the left display, but doesn’t.
  • People getting confused between workspaces and displays with the new overview presentation.

2 & 3 are both relevant to evaluating the new design and developing plans for the future. This is where the discussion has been more open-ended. There have been ideas around improving the overview for some configurations, as described above, but haven’t concretely agreed anything.

@allanday, I’m not sure I understand the new design’s behavior when using two monitors side by side.

a) Will both monitors change workspaces left/right at the same time ? If that is the case, then it will be very hard to have a mental representation of what are on the workspaces.

b) Will both monitors change workspaces independently ? If that is the case, then it will break the workflow of a lot of the people that have, in each workspaces, correlated windows on the two monitors. For instance, I often have a workspace for each of the projects I concurrently work on and have for each project an IDE on the left monitor, and a browser window and terminal on the right monitor.

For either a) or b), this would fall into your item 1. (any multimonitor issues with the new design which the old one doesn’t have).

1 Like

@ptitjes - the design doesn’t change how workspaces behave with regards to multiple displays.

If workspaces-only-on-primary is True(the default) then changing the workspace on the primary display won’t change it on secondary displays. If workspaces-only-on-primary is False, then changing the workspace will change on all displays. There’s no option to have a separate set of workspaces on each display. This is just how it is now.

To translate that to your questions…

a) Will both monitors change workspaces left/right at the same time ?

Only if workspaces-only-on-primary is False.

If that is the case, then it will be very hard to have a mental representation of what are on the workspaces.

Can you explain why that would be? To me it doesn’t seem any harder than with the current shell design.

b) Will both monitors change workspaces independently ?

No, we don’t support that.

Hi Alan,

Well, let me try to explain. Consider you have M monitors side by side (which is clearly the most common multi-screens layout) and N workspaces (with workspaces-only-on-primary == false).

With the current design, you can mentally represent the workspaces as a vertical “film” strip of spanned workspaces. This film strip is N-workspaces height and M-monitors width. This is plain and simple. You can switch workspaces by moving the film strip up and down.

With the proposed new design, you can only mentally represent the workspaces as M horizontal “picture” strips of non-spanned workspaces. The picture strips seem to overlap as the monitors are side by side but in fact they do not. The mental image for this is really confusing and completely unintuitive.

I hope you understand. I can make you a sketch, if you want.

That’s good for me, as changing workspaces and moving windows would be too much trouble. But I believe the people using multiple monitors side by side will be very confused as it is very difficult to grasp a mental image of the workspaces as I explained above.

As a side question: how would draging windows from one screen to another, if dragging a window on the right makes the workspaces get smaller and slide to reach the further workspaces on the right ? This is also an issue, right ?

1 Like

If I get you right, it zooms out, as soon as you drag in that view. See A shell UX update – GNOME Shell & Mutter for a video of it.

Razze, thanks for the video. Looking at it, it seems it really won’t interact well with moving a window to a monitor on the right…

Hi Alan,

You never came back to the issues I pointed out about how horizontal workspaces were impossible to have a mental image of when you use more than one monitor! I believe this is a major issue as all the people using Gnome at work have two monitors with workspaces-only-on-primary=false.

Please, can you state your point of view as how this important use case has been taken in account in your user reviews and how we can mitigate this, if ever by delaying the integration of the proposed new design.

Thank you.

I think the changes are too big for a “put it all back” option. However, I am seeing this particular concern a lot for people with horizontal multi-screen setups. I wonder if it would be possible to have an option which would put the dash on the side put workspaces horizontally, effectively rotating the whole metaphor by 90°.

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.