summaryrefslogtreecommitdiffstats
path: root/twin/wm-spec/x24.html
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-11-07 21:50:33 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-11-07 21:50:33 -0600
commit0b6057404f65218182ab27a9483a21065ef61fca (patch)
treeb8b06dfa2deb965bebfbe131a772124e3e693a96 /twin/wm-spec/x24.html
parent43d99cc2477266cb9072e179137f0e8485370b3d (diff)
downloadtdebase-0b6057404f65218182ab27a9483a21065ef61fca.tar.gz
tdebase-0b6057404f65218182ab27a9483a21065ef61fca.zip
Rename kwin to twin (Part 2 of 2)
Diffstat (limited to 'twin/wm-spec/x24.html')
-rw-r--r--twin/wm-spec/x24.html496
1 files changed, 496 insertions, 0 deletions
diff --git a/twin/wm-spec/x24.html b/twin/wm-spec/x24.html
new file mode 100644
index 000000000..47b406d0b
--- /dev/null
+++ b/twin/wm-spec/x24.html
@@ -0,0 +1,496 @@
+<HTML
+><HEAD
+><TITLE
+>Non-ICCCM features</TITLE
+><META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.72
+"><LINK
+REL="HOME"
+HREF="index.html"><LINK
+REL="PREVIOUS"
+HREF="index.html"><LINK
+REL="NEXT"
+TITLE="Root Window Properties (+Related Messages)"
+HREF="x107.html"></HEAD
+><BODY
+CLASS="SECT1"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+SUMMARY="Header navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+></TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="index.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="x107.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN24"
+>2. Non-ICCCM features</A
+></H1
+><P
+>There is a number of window management features or behaviours which are
+not specified in the ICCCM, but are commonly met in modern Window Managers and Desktop Environments.</P
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN27"
+>2.1. Additional States</A
+></H2
+><P
+>The ICCCM allows Window Managers to implement additional window states, which will
+appear to clients as substates of NormalState and IconicState. Two
+commonly met examples are Maximized and Shaded. A Window Manager may implement these
+as proper substates of NormalState and IconicState, or it may treat them
+as independent flags, allowing e.g. a maximized window to be iconified
+and to re-appear as maximized upon de-iconification.</P
+><DIV
+CLASS="SECT3"
+><H3
+CLASS="SECT3"
+><A
+NAME="AEN30"
+>2.1.1. Maximization</A
+></H3
+><P
+>Maximization is a very old feature of Window Managers. There was even a ZoomedState
+in early ICCCM drafts. Maximizing a window should give it as much of the
+screen area as possible (this may not be the full screen area, but only
+a smaller 'workarea', since the Window Manager may have reserved certain areas for other
+windows). A Window Manager is expected to remember the geometry of a maximized window
+and restore it upon de-maximization. Modern Window Managers typically allow separate
+horizontal and vertical maximization.</P
+><P
+>With the introduction of the Xinerama extension in X11 R6.4, maximization
+has become more involved. Xinerama allows a screen to span multiple
+monitors in a freely configurable geometry. In such a setting, maximizing
+a window would ideally not grow it to fill the whole screen, but only the
+monitor it is shown on. There are of course borderline cases for windows
+crossing monitor boundaries, and 'real' maximization to the full screen may
+sometimes be useful.</P
+></DIV
+><DIV
+CLASS="SECT3"
+><H3
+CLASS="SECT3"
+><A
+NAME="AEN34"
+>2.1.2. Shading</A
+></H3
+><P
+>Some Desktop Environments offer shading (also known as rollup) as an alternative to
+iconfication. A shaded window typically shows only the titlebar, the client
+window is hidden, thus shading is not useful for windows which are not
+decorated with a titlebar.</P
+></DIV
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN37"
+>2.2. Modality</A
+></H2
+><P
+>The Window Manager _TRANSIENT_FOR hint of the ICCCM allows clients to specify that a
+toplevel window may be closed before the client finishes. A typical example
+of a transient window is a dialog. Some dialogs can be open for a long time,
+while the user continues to work in the main window. Other dialogs have to be
+closed before the user can continue to work in the main window. This property
+is called modality. While clients can implement modal windows in an ICCCM
+compliant way using the globally active input model, some Window Managers offer support
+for handling modality.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="LARGEDESKS"
+>2.3. Large Desktops</A
+></H2
+><P
+>The Window Manager may offer to arrange the managed windows on a desktop that is
+larger than the root window. The screen functions as a viewport on this large
+desktop. Different policies regarding the positioning of the viewport on the
+desktop can be implemented: The Window Manager may only allow to change the viewport
+position in increments of the screen size (paging) or it may allow arbitrary
+positions (scrolling).</P
+><P
+>To fulfill the ICCCM principle that clients should behave the same
+regardless wether a Window Manager is running or not, Window Managers which
+implement large desktops must interpret all client-provided geometries with
+respect to the current viewport.</P
+><DIV
+CLASS="SECT3"
+><H3
+CLASS="SECT3"
+><A
+NAME="LARGEDESKSIMPL"
+>2.3.1. Implementation note</A
+></H3
+><P
+>There are two options for implementing a large desktop: The first is to
+keep the managed windows (or, if reparenting, their frames) as children
+of the root window. Moving the viewport is achieved by moving all managed
+windows in the opposite direction.</P
+><P
+>The second alternative is to reparent all managed windows to a dedicated
+large window (somewhat inappropriately called a 'virtual root'). Moving
+the viewport is then achieved by moving the virtual root in the opposite
+direction.</P
+><P
+>Both alternatives are completely ICCCM compliant, although the second one
+may be somewhat problematic for clients trying to figure out the Window Manager decorations
+around their toplevel windows and for clients trying to draw background
+images on the root window.</P
+></DIV
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN49"
+>2.4. Sticky windows</A
+></H2
+><P
+>A Window Manager which implements a large desktop typically offers a way for the user
+to make certain windows 'stick to the glass', i.e. these windows will stay
+at the same position on the screen when the viewport is moved.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN52"
+>2.5. Virtual Desktops</A
+></H2
+><P
+>Most X servers have only a single screen. The Window Manager may virtualize this
+resource and offer multiple so-called 'virtual desktops', of which only one
+can be shown on the screen at a time. There is some variation among the
+features of virtual desktop implementations. There may be a fixed number
+of desktops, or new ones may be created dynamically. The size of the desktops
+may be fixed or variable. If the desktops are larger than the root window,
+their viewports (see <A
+HREF="x24.html#LARGEDESKS"
+>Section 2.3</A
+>) may be independent or forced to be at the same
+position.</P
+><P
+>A Window Manager which implements virtual desktops generally offers a way for the user
+to move clients between desktops. Clients may be allowed to occupy more than
+one desktop simultaneously.</P
+><DIV
+CLASS="SECT3"
+><H3
+CLASS="SECT3"
+><A
+NAME="AEN57"
+>2.5.1. Implementation note</A
+></H3
+><P
+>There are at least two options for implementing virtual desktops.
+The first is to use multiple virtual roots (see <A
+HREF="x24.html#LARGEDESKSIMPL"
+>Section 2.3.1</A
+>) and change the current
+desktop by manipulating the stacking order of the virtual roots. This is
+completely ICCCM compliant, but has the issues outlined in <A
+HREF="x24.html#LARGEDESKSIMPL"
+>Section 2.3.1</A
+></P
+><P
+>The second option is to keep all managed windows as children of the root
+window and unmap the frames of those which are not on the current
+desktop. Unmapped windows should be placed in IconicState, according to
+the ICCCM. Windows which are actually iconified or minimized
+should have the _NET_WM_STATE_HIDDEN property set, to
+communicate to Pagers that the window should not be represented as
+"onscreen."</P
+></DIV
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN63"
+>2.6. Pagers</A
+></H2
+><P
+>A pager offers a different UI for window management tasks. It shows a
+miniature view of the desktop(s) representing managed windows by small
+rectangles and allows the user to initiate various Window Manager actions by manipulating
+these representations. Typically offered actions are activation (see <A
+HREF="x24.html#ACTIVATION"
+>Section 2.8</A
+>),
+moving, restacking, iconification, maximization and closing. On a large
+desktop, the pager may offer a way to move the viewport. On virtual desktops,
+the pager may offer ways to move windows between desktops and to change the
+current desktop.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN67"
+>2.7. Taskbars</A
+></H2
+><P
+>A taskbar offers another UI for window management tasks. It typically
+represents client windows as a list of buttons labelled with the window
+titles and possibly icons. Pressing a button initiates a Window Manager action on the
+represented window, typical actions being activation and iconification.
+In environments with a taskbar, icons are often considered inappropriate,
+since the iconified windows are already represented in the taskbar.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="ACTIVATION"
+>2.8. Activation</A
+></H2
+><P
+>In the X world, activating a window means to give it the input focus.
+This may not be possible if the window is unmapped, because it is on a
+different desktop. Thus, activating a window may involve additional steps
+like moving it to the current desktop (or changing to the desktop the window
+is on), deiconifying it or raising it.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN73"
+>2.9. Animated iconification</A
+></H2
+><P
+>Some Window Managers display some form of animation when (de-)iconifying a window.
+This may be a line drawing connecting the corners of the window with
+the corners of the icon or the window may be opaquely moved and resized
+on some trajectory joining the window location and the icon location.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN76"
+>2.10. Window-in-window MDI</A
+></H2
+><P
+>Window-in-window MDI is a multiple document interface known from MS
+Windows platforms. Programs employing it have a single top-level window
+which contains a workspace which contains the subwindows for the open
+documents. These subwindows are decorated with Window Manager frames and can be
+manipulated within their parent window just like ordinary top-level
+windows on the root window.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN79"
+>2.11. Layered stacking order</A
+></H2
+><P
+>Some Window Managers keep the toplevel windows not in a single linear stack,
+but subdivide the stack into several layers. There is a lot of variation
+among the features of layered stacking order implementations. The number of
+layers may or may not be fixed. The layer of a toplevel window may be explicit
+and directly modifyable or derived from other properties of the window, e.g.
+the <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>type</I
+></SPAN
+> of the window. The stacking order may or may not
+be strict, i.e. not allow the user to raise or lower windows beyond their
+layer.</P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="AEN83"
+>2.12. Scope of this spec</A
+></H2
+><P
+>This spec tries to address the following issues:</P
+><P
+></P
+><UL
+><LI
+><P
+>Allow clients to influence their initial state with respect
+to maximization, shading, stickyness, desktop, stacking order.</P
+></LI
+><LI
+><P
+>Improve the Window Managers ability to vary window
+decorations and maintain the stacking order by allowing clients to hint the
+Window Manager about the type of their windows.</P
+></LI
+><LI
+><P
+>Enable pagers and taskbars to be implemented as separate
+clients and allow them to work with any compliant Window Manager.</P
+></LI
+></UL
+><P
+>This spec doesn't cover any of the following:</P
+><P
+></P
+><UL
+><LI
+><P
+>Other IPC mechanisms like ICE or Corba.</P
+></LI
+><LI
+><P
+>Window Manager configuration.</P
+></LI
+><LI
+><P
+>Window Manager documentation.</P
+></LI
+><LI
+><P
+>Clients appearing on a proper subset of desktops.</P
+></LI
+><LI
+><P
+>Window-in-window MDI.</P
+></LI
+></UL
+><P
+>The Window Manager is supposed to be in charge of window management
+policy, so that there is consistent behaviour on the user's screen no matter
+who wrote the clients.</P
+><P
+>The spec offers a lot of external control about Window Manager actions.
+This is intended mainly to allow pagers, taskbars and similar Window Manager
+UIs to be implemented as separate clients. "Ordinary" clients shouldn't use
+these except maybe in response to a direct user request (i.e. setting a
+config option to start maximized or specifying a -desk n cmdline
+argument).</P
+></DIV
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+><A
+HREF="index.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="index.html"
+ACCESSKEY="H"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="x107.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+>&nbsp;</TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>Root Window Properties (+Related Messages)</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+> \ No newline at end of file