This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

Windows and Workspaces

The window picker overview shows thumbnails of every window on the current workspace. For majority of users the concept of workspaces will be hidden. They will very likely only have one workspace.

http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker.png

Technically they will have two as soon as they open up the first window, as shell will always add a blank workspace. User does not need to deal with adding and removing workspaces. If a workspace lacks any windows and it's not the last one, it gets removed. The control for workspaces is located on the right hand side and is hidden by default. Workspaces are arranged vertically. Positioning the mouse pointer to the right edge of the screen makes the workspace sidebar slide out. Similarly a dash lanucher drag or a window drag slides it out as well, regardless of cursor position. When new workspaces are added or removed, the sidebar also slides out to show this, and then slides back. The workspace thumbnails are valid drop targets for windows and launchers.

http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-1-workspace.png

The workspace sidebar slides out completely when the view shows windows from all workspaces such as when the context menud for a dash item is shown (and and application window filter is active).

http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-context-menu-pushes-windows-away.png

Verticality

It is important to clearly indicate switching workspace. Otherwise a user might get a false the notion application has crashed when it happens by accidentally hitting the key combination or clicking on a link/notification taking the user to another workspace. The suggested animation should take fraction of a second (200ms sounds reasonable) and consist of the workspace zooming out slightly to reveal position in the stack and label [1 of 4] quickly sliding down or up and zooming in on the target workspace. While the top bar is not drawn during the animation (faded out in the zoom part), the zoomed out workspace preview has the top corners rounded in a similar fashion as the top bar.

http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/workspace-switcher.png

Launching into specific workspace

To launch new application window into a new workspace, the user either switches to the last blank workspace and launches the app by clicking or drag the launcher from the dash to the workspace.

http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-2-workspaces.png http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-6-workspaces.png

http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/dash-run-in-workspace.png

Cursor indicates the app will be executed when over the target workspace

http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-9-workspaces.png

When dragging a launcher form the app picker, the app picker view fades out as soon as the drag is initiated to indicate it's not a valid drop target and the only target is either the dash or the workspace sidebar. This fadeout will not be necessary as soon as we have a fixed view for the app picker and will allow custom (user controlled) launcher arrangement.

Notes

Notable changes to previous designs

Up for discussion

Brainstorming Future Ideas


2024-10-23 11:03