Projects/Metacity/WindowTypes – GNOME Wiki Archive

Rationale

The FreeDesktop window manager specification defines several types of window that window managers should understand, and Metacity largely supports these. However, the surfeit of extra flags for window behavior, the lack of a type for progress windows, and Metacity's current presentation of the other types, combine to produce windows with redundant controls and behavior that is unnecessarily difficult to predict by looking at them. This can be resolved by clearly defining distinct appearance and behavior of each type of window, to make the interface simpler, more understandable, and more efficient.

Design

How window types work currently

_NET_WM_WINDOW_TYPE
Havoc Pennington: "it is a fact of the architecture that there's a fixed number of window types."

Proposal for obvious window types

	Distinguishing marks				Behavior
	Title bar	Close	Maximize	Minimize	Modal	Alt+Tabbable	Window switcher
Panel	no	no	no	no	no	no	no
Panel	Floats above all other windows (except utility windows with no parent, e.g. an IME used to type into a Launcher's text field). Examples: `gnome-panel`, `gnome-launch-box`.
Alert	Yes	no	no	no	yes, unless parent is root window	takes the place of the parent (unless parent is the root window)	no, unless parent is the root window
Alert	A necessary interruption to your work. The only kind of window that, when it opens, automatically causes a window switcher button to throb.
Dialog	Yes	no	no	no	yes, unless parent is root window	takes the place of the parent (unless parent is the root window)	no (unless parent is the root window)
Dialog	Prompts for further information about something you asked for. Closable using the "Cancel" button or at least one other button present (e.g. "Print").
Progress window	Yes	no	no	Yes	no	Yes	Yes
Progress window	Embodies a slow non-user activity and displays its progress. When the action stops, the window closes; if the window is closable manually (using a "Cancel"/"Stop" button), the action stops. Examples: file copying progress, splash screens.
Normal window	Yes	Yes	Yes	Yes	no	Yes	Yes
Normal window	General-purpose. Appropriate for preferences windows, assistants (a.k.a. wizards), games, accessories, and any window that displays multiple documents (e.g. an e-mail client's main window).
File window	Yes	Yes	Yes	Yes	no	Yes	Yes
File window	Embodies a single document, folder, or device: e.g. a folder in Nautilus, or a note in Tomboy. Visibly differs from a normal window only in that its title bar contains a draggable icon representing the document. (To be implemented later.)
Utility	Mini	Yes	no	Yes	no	Yes, but only when starting from its parent or sibling (unless it has none)	Only if minimized
Utility	Functionally equivalent to a standard window, except that it floats above its parent, and is open/reopened only when its parent (or any of its parent's utility windows) is focused. (If a utility window has no parent, e.g. an IME window, it floats above all other windows, including other utility windows.) Appropriate for toolboxes, formatting palettes, and Find/Change windows. When any utility windows are open, the most-recently-focused non-utility window comes first in the Alt+Tab cycle (this avoids interfering with rapid Alt+Tabbing between two non-utility windows), followed by all the open utility windows in order of recency, followed by the second-most-recently-focused non-utility window, the third-most-recently-focused non-utility window, and so on.

Visual design

Titles that are centered, but don't look centered, look bad.
Title bar buttons that never do anything also look bad. A control should only be present at all if it can ever become available.
The reason Mac OS X and Windows title bars sometimes include buttons that don't do anything is that they don't want to disturb the usual position of each title bar button -- it would be bad for the Minimize button to appear where the Close button usually is, for example -- and nor do they want strange gaps apearing in the title bar. At least, that's the reason Mac OS X does this; Windows sometimes puts buttons in the wrong place regardless.
A close button that's right next to a much less consequential button is unnecessarily dangerous.

With careful positioning, we can avoid all four of these problems at once.

How do we get there?

Update the HIG to recommend use of _NET_WM_WINDOW_TYPE_NORMAL for preferences windows.
Recommend that in the wm-spec, _NET_WM_WINDOW_TYPE_TOOLBAR be deprecated in favor of _NET_WM_WINDOW_TYPE_UTILITY.
Introduce _NET_WM_WINDOW_TYPE_PROGRESS for progress windows. See if it works (maybe try it in Nautilus).
Recommend the introduction of _NET_WM_WINDOW_TYPE_PROGRESS to the wm-spec.
Update the HIG to recommend use of _NET_WM_WINDOW_TYPE_PROGRESS for progress windows.
Remove close buttons (and the Alt+F4 keyboard combo) from alerts and dialogs, but leave the "Close" menu item in place (for a couple of years?) as a last resort. (Perhaps remove the button+combo during development of one release, like "fatal-criticals" in 2.14, then after that release hide it permanently?) Patch the hurt apps.
- In GNOME, many instant-apply windows have redundant "Close" buttons, and also declare themselves to be dialogs. Fortuitously, these two mistakes cancel each other out. When close buttons are removed from dialog title bars, the "Close" buttons will still be available in these windows until they are fixed to be normal windows.
Ignore several of the _NET_WM_STATEs, for greater predictability:...

Implementation

Unresolved issues

Should a window that is not maximizable also not be resizable? (Brought up at http://bugzilla.gnome.org/show_bug.cgi?id=315910#c6, but I'm pretty sure I've seen the same question elsewhere)
Missing type to represent other types of windows: (a) dock like stuff (_NET_WM_WINDOW_TYPE_DOCK) such as gnome-panel or gnome-launch-box, which currently are kept above other windows and don't have decorations and don't automatically get focus on click and don't appear in the alt-tab list (in ctrl-alt-tab list instead) and are placed on all workspaces by default and don't show up in the pager or taskbar and whose edges tend to be used to define the edge of the "screen" and whose placement isn't constrained or otherwise handled by metacity, (b) splash screens (_NET_WM_WINDOW_TYPE_SPLASH; I don't want to dig out current behavior again like I did for dock, so I'm skipping it...), and (c) "desktop" windows (i.e. the nautilus drawn windows containing your background and icons on it).
- If override-redirect windows shouldn't be in the list, why should desktop windows should be in the list? Also, are the root window and the desktop window distinct? Which of them often have children? -- mpt
  - Override redirect window might make sense to keep in the list as long as you are thinking of this page being a useful gathering point for data for both Metacity and gtk+. Anyway, the desktop window is somewhat different in that metacity does manage it -- and has had problems before (e.g. clicking on the desktop window and then typing alt+space would bring up metacity's window menu for the desktop window, which just didn't make sense). So we do need to make sure metacity's rules for such windows are right, and thus seemed to fit on this page to me.
"The only kind of window that should cause a window switcher button to throb." -- what about a minimized application whose task is complete? or an IRC client where someone is speaking to me?
- Good point, clarified. I was thinking of the automatic throbbing when a window opens, not the throbbing an app asks for manually. -- mpt
  - You seem to also be ignoring the case where windows aren't given focus due to user interactions with other applications between the time the window was launched and when it showed up? There needs to be some kind of notification for those too. (Granted, we also have to fix some buggy apps that claim their windows were launched hours ago instead of milliseconds ago)
    - Can you give an example? Throbbing should mean "I need attention", not "I'm slow". For example, if a task is taking long enough that the program decides it should display a progress window to show the remainder, the progress window shouldn't throb (this bug occurs in Synaptic). -- mpt
      - I fully agree with not throbbing for things like progress windows. That obviously makes no sense (and I was unaware of any apps which did that, not having used Synaptic for years). Users should receive some kind of notification when new windows appear. Usually, that notification is that the window is placed on top and gets focus. But, if the user began a different task between the time they launched the application and when the new window appears, then the new window should not take focus and should not be placed on top over the window they are now working in. The throbbing is an alternative notification mechanism for these cases. (Though it was triggered a bit too often until some recent bugfixes -- if the window wasn't obscured by any others then there was no need to throb)
    - Do you mean this sort of thing: I launch OOo, I switch to firefox while its loading, and OOo throbs when it's ready? I find that sort of throbbing annoying. It doesn't *need* my attention, like mpt says, the throbbing just says 'yeah, I'm slow, sorry'. It's a pain to switch to an app just to stop the annoying throbbing on my taskbar -- joachim
      - There's a big difference between "I am slow" and "I was slow". A better question, perhaps, is why you launched OOo if you don't want to use it soon after it actually appears. Most users I believe would want to use it soon after it appears (that's why they launched it after all), and if it appears below their focused window then it'll just frustrate the users. Granted, there were some bugs only recently fixed where the new window wasn't at all obscured and the taskbar would flash anyway, but those were just bugs.
By 'custom' do you just mean override-redirect windows? That's what it looks like from the description. If so, Metacity (as a window manager) has nothing to do with them. Also, they can't have a metacity-drawn titlebar, and many of these windows are in fact not only modal but are system-modal. (The system-modal behavior is because these apps nearly always grab the pointer and the keyboard so that no other app or even the window manager gets keyboard or mouse events; the app just releases the grabs and closes the override-redirect window when it gets a click outside that window (and passes the click on to other programs, usually) or gets an Escape keypress). Some argue the existence of override-redirect windows are a bug and that any such windows should just be implemented as normal windows with additional hints to the window manager (in particular, me and also the accessibility people, for different reasons), but that's not likely to happen in the short term.
- Ok, removed. (I guess that's why Alt+Tab fails when a menu is open. Also, what if an app hangs while it has such a window open?) -- mpt
  - Yes, exactly. I've pondered a spec to get toolkits and window managers to be able to cooperate to allow things like alt-tab to work during grabs (Edit: now filed as bug gnomebug:344059), but it definitely would be a fair amount of work to implement. Anyway, if an app hangs while it has a grab, the user loses badly. Sometimes, apps might only have grabbed the keyboard or the mouse but not both (which is somewhat rare) in which case the user may be able to use the ungrabbed input device to kill the app. If both are grabbed and the user is an expert, they can switch to a virtual console (or log in from a different machine) and use command-line programs to kill the offending app. If both are grabbed and the user isn't an expert, it's time to reboot -- by hitting the reset button on the machine.
You haven't specified which types should come with a maximization ability.
- Fixed.
Isn't alt-tabbable and showing in the window switcher redundant? Or are there cases when you want the two lists of windows to really not be the same? (We've gotten multiple bug reports whenever we make the lists not be the same in the past)
- Well, the obvious counterexample is that alerts and dialogs with parents should not appear in the window switcher, but should take the Alt+Tab place of their parent. The other exception is utility windows, which should not appear in the window switcher because that would cause it to jarringly populate/depopulate whenever a window with many child utility windows was focused/unfocused. -- mpt
None of the picture attachments seem to work -- can that be fixed so we can look at them?
Should we make menus, titlebar buttons, and the titlebar-right-click menus be consistent in all cases (i.e. if there is no close button, should Alt+F4 and right-click->close both be disabled as well)? If not, in which cases should one be allowed when others are not?
- Yes, I think they should be consistent, except during the transition period I've suggested. -- mpt
What do you mean by a "draggable icon representing the document"? Where would it be placed, what would it look like, who would be responsible for drawing it, and do we need to worry about more generalized infrastructure for requests like these (see also bug 82567 and bug 145400)?
- draggable document icons is a long-term thing. There's a nice mockup here: http://tango-project.org/Window_Experiments -- joachim
I don't understand your alt-tabbing descriptions for utility windows.
- Fixed, I think. (Is the new wording understandable?)
  - Yes, that's much more clear now, thanks.
is 'root window' the desktop? I started a GnomeGlossary page for this sort of thing BTW -- joachim
- Maybe, but not usually. If nautilus draws the desktop (i.e. if /apps/nautilus/preferences/show_desktop is true, as it is by default), then nautilus creates a full screen 'desktop' window that covers the root window, and on which it draws your desktop icons and shows your background. In that case, nautilus is your 'desktop'. Other apps could be used in nautilus' place in this way. If no such app has created any such window, then the root window will serve as the 'desktop'. Despite the fact that the root window belongs to X, there are ways for other apps (e.g. the gnome control center) to make the root window display some image; this mechanism is utilized to allow users to have their desired background when the root window is the 'desktop'.