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


[Home] [TitleIndex] [WordIndex

Introduction

We first splitted the subject into:

We then focused mainly on /WindowManagement, considering that the 2 other topics were two wide to consider in the same session.

In particular, we identified some typical window management features:

We also looked at some recent research results coming from the Windows 7 blog. For example:

The following sections detail some of the ideas that were discussed for several topics

Backgrounding or GOOMF!

There are many application windows we would prefer not to see, or that stay visible while they should go away. Applications that typically trigger this typical user reaction ("Get Out Of My Face!" or GOOMF), are, or are related to:

In particular, we discussed if the typical applications we would like to background that way are in fact features that belong to a set of generic system services that we expect to be present, like the audio subsystem with just a volume control.

We should seek application developers support to do this right (new/revised API, library, etc.)

Also, we categorized windows between:

Persistent application windows usually belong to a workspace. Moving to a different workspace is like a "mental context switch".

Grouping Applications

Related to both launching and managing application windows, we identified a pattern in "grouping application windows" by functional domains. Like, having Inkscape and a collection of smaller utilities in the same workspace. The idea is to ease the interaction between the main application and "satellite" applications.

The idea was later extended, after the discussion on getting rid of the hierarchical filesystem, by proposing to bind a workspace to a "virtual folder" that would host the different document(s)/parts the user is working on with the applications launched in the same workspace.

The idea was also linked with an Exposé-like mode: applications of the same workspace should be grouped in the expose view.

Maximized windows and fullscreen

We discussed the common practice of working with most application windows being fullscreen, or rather in "maximize" mode. Almost everyone uses Evolution/Thunderbird or Firefox in maximized mode. Real fullscreen, though more rare, would be a desirable feature if it was made available to all applications by the window manager. We discussed the difference between: - maximized height window (see also preferred aspect ratio below) - fully maximized window (the default nowadays) - fullscreen as a further step for maximizing windows

With growing numbers of large widescreen screens, it is also desirable to have 2 "maximized" windows laid out side by side. With widescreen displays, the normal way to maximize a window wastes too much screen space. Applications should be able to tell their preferred aspect ratio to display all of a document page, for example.

This lead us to tiling. Most users don't like to resize windows precisely, they use the maximize button. However, when they really want to have multiple windows visible at the same time, most don't like to have spaces, or to have to adjust manually the window position to align them properly. At some point, tiling could also be used to manage a sort of sidebar of small application windows.

Related to tiling, we discussed also the possibility to group windows together, so that they are tied by an edge and can be moved together for example.

Application tabs

We think that application tabs, like Firefox tabs, are a window management failure. The window manager should be able to provide such a service to applications. And discussed how to possibly manage tabs when ALT-tab'ing.

Merge with the Widget/Applet discussion

During a second meeting, the Window Management discussion group and the Widget discussion group exchanged concepts

Live Icons

One of the ideas resulting from this merge, is the opportunity to have "live icons". Instead of having applets or panel icons, an application could update its appearance, like in a dock, with status information. For example: displaying the number of unread emails on the TB app. icon, or displaying an SVG preview of a document in the taskbar.

That would move data about an application, making it available in an icon; associating icons/dialogs/applets/applications/notifications of the same "flow".

Notifications

Notifications should be centralized. The user should have the ability to tune the notification "volume", ie prioritizing which notifications he wants to see, and which he wants to mute. Where should notifications show up? are system/applications/applet/web updates notifications different? There should be standard applet representations for different views; with support for theming.

Note: applications should be able to use the standard freedesktop service.


CategoryUsability


2024-10-23 11:06