But the new design solves some issues like the gestures. They are now much more logical. And this improves also touchscreen navigation.
This is a pretty interesting non sequitur.
The problem is not changing things: the problem is changing them, while keeping the changed code around alongside a switch to go from one state to another.
Because, assuming you have two screens side by side:
- you will have two horizontal workspace switchers side by side, and thus donât have any spatial cue as to what workspace on the left screen correspond to what workspace on the right screen
- this will be even worse if the workspace switchers are made independent, as a) youâll have even less spatial cues for the workspace correspondance, b) youâll have to do twice the shortcuts, mouse moves, and gestures to change both the workspace on the left screen and the workspace on the right screen
- you will never be able to have a global view of all the workspaces (I often have 5 to 10 workspaces open at work) without having the app grid open (consuming all the screen real-estate), as clearly shown in the mockups. This is a pity for those that donât use the app grid but only the great type-to-search feature.
- the only way to move a window from workspace 1 to workspace 10 is by sliding a window on a very long distance through multiple screen width, which is impossible on a touchpad. (I use a touchpad also on my desktop setup and all laptop users do too.) Again see the âWindow Drag & Dropâ mockup.
1 Like
More logical how? From what I can tell, theyâre less logical and less intuitive - as has been explained previously in the thread. You pan away, and yet the view zooms out. You pan away again, and the view zooms out further. That doesnât make sense.
1 Like
I strongly disagree. I use a Magic Trackpad with Gnome 38 and often use the full-hand swipe up/down to change workspaces and it feels very natural.
The issue is that the full-hand pinch in/out is not correctly implemented and doesnât work well. Not using the full-hand pinch in/out in the proposed new layout is not solving this issue. It is just a cheap workaround.
And it brings so much more issues in return.
1 Like
The problem is not fixing the gesture issues but overcoming it by changing a good design and bringing a whole new set of issues on the table.
Last I checked workspaces are only on the main monitor, so Iâm not sure what your getting at?
But there is only one switcher anyway?
True you wonât have the thumbnails when opening Activities anymore
I donât see an open app list here? The dash is on the bottom not the side but itâs not much different to 3.38 really (and type to search is still available)
Ah perhaps it isnât clear in the image: The previews are all shrunk to fit on screen when you start dragging a window, the mouse movement should be about the same as it is now - possibly even slightly less since your only going side to side
They are not. You can span the workspaces over all the screens. It is activatable through Gnome Tweaks but this is a feature in the code of Gnome Shell. (Btw issue 2644 should be fixed as the Multi-Monitor extension does it: just enabling the thumbnails on all the screensâŚ)
If the workspace spanning feature is removed from Gnome Shellâs source code, then yes there will be only one switcher. But then my point stands again: all Jetbrains IDEs, Darktable and DaVinci Resolve (and lots of other apps, I am sure) wonât be usable in their multi-screen layouts.
That is really a problem when you use Gnome for work.
I thought you could also drag and drop windows in the âApp Gridâ mode (where you can see more workspace thumbnails), my bad.
But then my 5 to 10 workspaces are shrunk so much as a middle horizontal workspace strip that the screen real-estate is only occupied by blank space on top and bottom⌠Whereas in the current design, you still see the windows remaining in the current workspace and decide whether you need to move more windows. In the new design, youâll have to move back and forth, right ?
In anyway, my point stands, this wonât be usable in multi-monitor setups for creative or development work.
âŚand therefore unsupported
1 Like
Gnome Shell implements the feature and Gnome Tweaks activates its. I would argue this is supported.
Are you kidding me? What do you do when you have multiple such apps open in multiple-screen layouts, one on top of another? For instance, and I know I am not the only one to do that, I always have multiple projects open in IDEA, each on its own spanned workspace with additional editor windows, browser or terminal on the second screen. Or I can have DaVinci in dual-monitor layout in one spanned workspace and some other applications in other spanned workspaces. Or having the darkroom tab of Darktable doing zoomed-in retouch on the left screen of a spanned workspace and a fullscreen view of my photo on the right screen, while having other applications in other spanned workspaces.
Do you need more explanations?
Couldnât all of this also be solved by a smaller change like only changing the location and orientation of the current workspaces overview from the vertical one on the right side to a horizontal one at the bottom?
So, I really like the new design and Iâm excited to try it. I have only two comments:
-
The new design really screams out for a hot bottom edge (or at least a hot area the width of the dash on the bottom edge) instead of a hot upper-left corner. That would solve the mouse travel issues, and would feel a bit less arbitrary than the current hot-corner.
-
I do want to cautiously echo that
workspaces-only-on-primarybeing set to true has never made sense to me as a default, I switched it to false as soon as I figured out that you could, and I think itâs really important that the experience withworkspaces-only-on-primaryset to false not regress. Iâm optimistic , though, that itâs possible to make it work with the new design.
Iâm not a fan of the new design at all and since I donât think anyone really cares about that, I also wonât give any constructive feedback. If extension developers wonât be able to fix the problems I see, Iâll just switch to a different DE.
You can be sure thereâll be plenty of extensions to revert the old behavior. But Iâd still recommend you to try it really without any extensions once GNOME 40 is out
Iâm sure there will be extensions eventually, but with all these changes, I doubt theyâll be ready in time when Gnome 40 airs on Fedora 34. For sure Iâll give the new layout a try, but my imagination is actually good enough to know that the new layout is a huge step back usability wise. Gnome is all about making use of workspaces⌠and now you wonât be able to see all of your workspaces anymore in the overview⌠itâs in the applications grid all of the sudden, where no one would expect it. So how do you switch to workspace number 5 lets say? Until now it was one mouse click away⌠but with the new layout you need to scroll through all the workspaces in between or remember the number of the workspace and switch to it directly via keyboard shortcut.
Then the dash on the bottom⌠yes, lets make the mouse cursor travel even longer from the topâŚ
Itâs a good solution for having more space for the icons so they donât get so tiny if you have many favorites, but I donât want to move the mouse across the whole screen two times just to open an application.
The easiest solution would be to put a dock or panel on the bottom of the desktop. Itâs what most people are used to, itâs the most practical⌠and no, itâs not distracting.
Something I also donât get is the whole argument about gestures⌠what do you need gestures for? If you want to open the overview, you can by pressing the super key or by clicking on activities. If you want to have a gesture for it, then simply use three finger scroll down. For switching between workspaces, you can use normal scrolling. So why do we need to change the direction in the overview? Itâs a preferable scrolling behavior on touchscreens Iâve read? How? On android the app grid scrolls vertically⌠on web browsers you scroll vertically, so how is this even an argument?
Itâs not so much about changing the scrolling direction in the overview, itâs about the impact it has on the layout and usability. I have no complains about the horizontal workspace layout on elementary os, but it also has previews on the bottom of all of the open workspaces.
5 Likes
Sure, thatâs an entirely acceptable goal.
âAdding an optionâ to toggle between two solutions because you donât like one, on the other hand, is not a solution.
I recommend you read this essay, which describes fairly well the ethos of GNOME since the late 1.x days.
Then why I are we imposed a full design change, which clearly have not taken into consideration multi-monitor setups ?
I fully agree. I am all for a clean code-base with fewer cases.
What I am requesting is for this design change to be reconsidered and that the very common use-case with multi-monitor setups be included.
If this is not the case, then at least the proposed new design have to be developed from the ground up with enough extension points so that it can be tweaked by extensions (and that those tweaks be supported).
I was very eager for the full Pipewire experience in Fedora 34. I am now worried about this proposed new shell design comming in without any deprecation notice.
1 Like
I second this. This would make the navigation even more logical and spatial. It would reduce mouse travel issues not only compared to current gnome40, but also current gnome 3.38. Currently, to access the dash, you go to the top corner and slightly down. With bottom dash and hot bottom edge, you would only need one straight move, and your cursor is likely to be closer to the bottom than the top left corner.
+1 on that, too. It would go much better with this new workflow.
EDIT: It actually seems to be a bit less ergonomic of a movement, though. Just compare that by doing the current âflickâ with your mouse versus âpushingâ through the bottom edge. It would also be less discoverable, since you couldnât couple it with an actual button as it is now. But otherwise it just makes more sense and would practically eliminate the travel distance, as you noted.
Yes, the problem is that it makes the activities button kinda weirdly placed. Iâd argue that moving the dash to the bottom already does that though. That necessarily increases the mouse travel between the activities button and the dash. If the top left corner remains the only place to access the activities overview, then moving the dash to the bottom is kinda usability regression. If additional way of accessing activities is introduced, it can turn out into a legitimate improvement.
On touch screens, it would be nice to trigger the overview by swiping up from bottom edge.
I think I disagree with this. You can test the movement by using dash-to-dock with intellihide (or to a lesser extent, docky/plank or macos dock). On discoverability, while there is no button to mark it, itâs not that hard to find, and gnome-tour has a good onboarding that can be used to show this. Also, since activities is now the default view, itâs visible also there.