The desktop environment: Difference between revisions

From SprezzOSWiki
No edit summary
 
(20 intermediate revisions by the same user not shown)
Line 1: Line 1:
Depending on the [[graphics]] capabilities of your machine, it might be possible to engage a user interface based on pixels rather than character cells. These are typically referred to as GUIs (Graphical User Interfaces), and have underpinned the vast majority of interactive computing for many years. Most GUIs are minor variations on idioms of the ''desktop environment'', that is:
Depending on the [[graphics]] capabilities of your machine, it might be possible to drive a user interface enjoying pixel- rather than character cell-level resolution. These are typically referred to as GUIs (Graphical User Interfaces), and have underpinned the vast majority of interactive computing for many years. The primary distinguishing features of GUIs include:
* higher resolutions (and perhaps more colors) than character displays of the same size, and
* deep support for interactive job control ("multitasking") via built-in z-axes with well-integrated controls.
Note that the first difference can be offset via framebuffer consoles, and the second by console multiplexers and/or glyph-based window managers. A great many programs, however, are written using toolkits and widgets that only support pixel and/or vector displays, not character cells and glyphs. Toolkits could conceivably be written to implement such programs in terms of glyphs and cells, but such technology is not known to exist today, and there seems no plausible need for it:
* character cells typically operate at a device's lowest resolutions, with no gain in other parameters (e.g. color, framerate),
* terminal emulation in a pixel environment is a thoroughly explored problem space, and
* networked GUIs separate execution from rendering, operating over bytestreams such as those provided by [[Remote_access#SSH|SSH]].
 
==GUIs==
Most GUIs are minor variations on idioms of the ''desktop metaphor'', that is:
* Interactive applications present sets of distinct ''windows'', objects of varying opacity taking dynamic size in 2 dimensions
* Interactive applications present sets of distinct ''windows'', objects of varying opacity taking dynamic size in 2 dimensions
** The contents of the windows, subject to overlap, are controlled by the application
** The contents of the windows, subject to overlap, are controlled by the application
Line 13: Line 22:
** '''''A single workspace exhibiting [http://en.wikipedia.org/wiki/Simply_connected_space non-simple connection]/[http://en.wikipedia.org/wiki/Genus_%28mathematics%29 dynamic genus], starting and ending as an e.g. sphere possessing [http://en.wikipedia.org/wiki/Metric_expansion_of_space dynamic local metric], seems a fascinating and natural one. Has this not been pursued? -- [[User:Dank|nickblack.atl]] ([[User talk:Dank|talk]])'''''
** '''''A single workspace exhibiting [http://en.wikipedia.org/wiki/Simply_connected_space non-simple connection]/[http://en.wikipedia.org/wiki/Genus_%28mathematics%29 dynamic genus], starting and ending as an e.g. sphere possessing [http://en.wikipedia.org/wiki/Metric_expansion_of_space dynamic local metric], seems a fascinating and natural one. Has this not been pursued? -- [[User:Dank|nickblack.atl]] ([[User talk:Dank|talk]])'''''
GUIs are by no means always available, for instance when using a serial terminal, when recovering during a broken [[booting|boot]], or when they are not installed (by default, [[SprezzOS 1]] does not install any GUI components). In this case, interaction is limited to a pure [[The shell environment|shell environment]].
GUIs are by no means always available, for instance when using a serial terminal, when recovering during a broken [[booting|boot]], or when they are not installed (by default, [[SprezzOS 1]] does not install any GUI components). In this case, interaction is limited to a pure [[The shell environment|shell environment]].
==GUIs==
 
The standard [[Graphics#Raster_Output|compositor/rasterizer]] on Linux is currently [[X.org]] atop a mix of kernel- and userspace Direct Rendering Infrastructure, plus a compositing window manager. Alternatives include [[Wayland]] and [[DirectFB]].
A modern GUI can be composed from various projects' elements, to the user's taste. What follows is a high-level description of a desktop GUI stack.
 
===Rasterizer===
The standard [[Graphics#Raster_Output|compositor/rasterizer]] on Linux is currently [[#X|X.org]] atop a mix of kernel- and userspace Direct Rendering Infrastructure, plus a compositing window manager. Alternatives include [[Wayland]] and [[DirectFB]].
* A rasterizer provides an interface by which applications can render to a framebuffer.
* A rasterizer provides an interface by which applications can render to a framebuffer.
** Without a rasterizer, all applications must speak cooperatively to the physical framebuffer.
** Without a rasterizer, all applications must speak cooperatively to the physical framebuffer.
* A compositing rasterizer provides virtual framebuffers to applications, which are projected via some transform to the true framebuffer.
* A compositing rasterizer provides virtual framebuffers to applications, which are projected via some transform to the true framebuffer.
** In the absence of a composting rasterizer, applications must cooperatively implement effects along the Z axis<blockquote>One might say that non-destructive overlapping is a Z-axis effect. While this is true, non-destructive overlapping can be implemented via recoverable, linear XOR transforms, and thus the overlapping bitmap itself is sufficient information to recover the original bitmap. Thus the distinction is meaningful. - [[User:Dank|nickblack.atl]] ([[User talk:Dank|talk]])</blockquote>
** 'In the absence of a composting rasterizer, applications must cooperatively implement effects along the Z axis<blockquote>''One might say that non-destructive overlapping is a Z-axis effect. While this is true, non-destructive overlapping can be implemented via composable, wholly linear XOR transforms, and thus the overlapping bitmap itself is sufficient information to recover the original bitmap. Thus the distinction is meaningful. Note that "composable" is used here in the mathematical sense, rather than that of computer graphics. - [[User:Dank|nickblack.atl]] ([[User talk:Dank|talk]])''</blockquote>
 
===Display Managers===
===Display Managers===
A '''[http://en.wikipedia.org/wiki/X_display_manager_%28program_type%29 display manager]''' is essentially a graphic equivalent of the console environment's <tt>getty</tt> apparata. They typically runs independently of window managers (indeed, they are more tightly bound to desktop environments and session managers than window managers), with privileges similar to those of the <tt>login</tt> process. XDMCP can be used to communicate with a display manager running remotely, though I wouldn't recommend it. Sprezzatech currently recommends use of Light-DM, unless one is making use of the [[KDE]] desktop environment, in which case KDM is recommended. Please note that GDM is recommended by the GNOME team for GNOME sessions, though our experience with LightDM in this capacity has been very positive. Note that only LightDM, Orthos, and XDM aim to support desktop environment independence, facilitating a single display manager experience across multiple session types. All display managers known to this author allow for selection from various session types, when present.
A '''[http://en.wikipedia.org/wiki/X_display_manager_%28program_type%29 display manager]''' is essentially a graphic equivalent of the console environment's <tt>getty</tt> apparatus. They typically run independently of window managers (indeed, they are more tightly bound to desktop environments and session managers than window managers), with privileges similar to those of the <tt>login</tt> process. XDMCP can be used to communicate with a display manager running remotely, though I wouldn't recommend it. Sprezzatech currently recommends use of LightDM, unless one is making use of the [[KDE]] desktop environment, in which case KDM is recommended. Please note that GDM is recommended by the GNOME team for GNOME sessions, though our experience with LightDM in this capacity has been very positive. Note that only LightDM, Orthos, and XDM aim to support desktop environment independence, facilitating a single display manager experience across multiple session types. All display managers known to this author allow for selection from various session types, when present.
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|+ Comparison of Display Managers
|+ Well-known Display Managers
! Name
! Name
! Package
! Package
Line 30: Line 43:
| LightDM
| LightDM
| light-dm
| light-dm
| [[X.org]]
| [[#X|X.org]]
| GTK/[[KDE]]/Razor-QT/Unity frontends
| GTK/[[KDE]]/Razor-QT/Unity frontends
|-
|-
Line 63: Line 76:
===Window Managers===
===Window Managers===
===Desktop Environments===
===Desktop Environments===
==X==
Also known as the X Window System and X11 (due to protocol version 11 having been in place since September 1987), the X.Org Server has been the mainstay of Linux GUIs almost since Linux's inception. Its primary manpage is <tt>X(7)</tt>. It is typically launched from the [[The shell environment|command line]] using <tt>startx</tt>, or indirectly via logging into a [[GUI#Display Managers|display manager]].
===startx===


==Theming==
==Theming==
SprezzOS's default theme is [[Allotrion]].
SprezzOS's default theme is [[Allotrion]].
==Networked GUIs==
===X-style forwarding===
===VNC-style forwarding===


==See Also==
==See Also==

Latest revision as of 07:19, 26 March 2013

Depending on the graphics capabilities of your machine, it might be possible to drive a user interface enjoying pixel- rather than character cell-level resolution. These are typically referred to as GUIs (Graphical User Interfaces), and have underpinned the vast majority of interactive computing for many years. The primary distinguishing features of GUIs include:

  • higher resolutions (and perhaps more colors) than character displays of the same size, and
  • deep support for interactive job control ("multitasking") via built-in z-axes with well-integrated controls.

Note that the first difference can be offset via framebuffer consoles, and the second by console multiplexers and/or glyph-based window managers. A great many programs, however, are written using toolkits and widgets that only support pixel and/or vector displays, not character cells and glyphs. Toolkits could conceivably be written to implement such programs in terms of glyphs and cells, but such technology is not known to exist today, and there seems no plausible need for it:

  • character cells typically operate at a device's lowest resolutions, with no gain in other parameters (e.g. color, framerate),
  • terminal emulation in a pixel environment is a thoroughly explored problem space, and
  • networked GUIs separate execution from rendering, operating over bytestreams such as those provided by SSH.

GUIs

Most GUIs are minor variations on idioms of the desktop metaphor, that is:

  • Interactive applications present sets of distinct windows, objects of varying opacity taking dynamic size in 2 dimensions
    • The contents of the windows, subject to overlap, are controlled by the application
    • Decorators of the windows, subject to overlap, are usually controlled by the application
    • Graphic presentation is typically influenced by a theme -- an instance of a presentation engine's parameters
  • Windows are partitioned among workspaces, 2D objects having size corresponding to the display
    • Each workspace provides a z-axis on which its windows are at least partially ordered
    • Some systems support association of windows with more than one workspace at a time
  • A root window
  • In every system known to this author, a total order is induced upon the workspaces, and only one workspace is shown at a time

GUIs are by no means always available, for instance when using a serial terminal, when recovering during a broken boot, or when they are not installed (by default, SprezzOS 1 does not install any GUI components). In this case, interaction is limited to a pure shell environment.

A modern GUI can be composed from various projects' elements, to the user's taste. What follows is a high-level description of a desktop GUI stack.

Rasterizer

The standard compositor/rasterizer on Linux is currently X.org atop a mix of kernel- and userspace Direct Rendering Infrastructure, plus a compositing window manager. Alternatives include Wayland and DirectFB.

  • A rasterizer provides an interface by which applications can render to a framebuffer.
    • Without a rasterizer, all applications must speak cooperatively to the physical framebuffer.
  • A compositing rasterizer provides virtual framebuffers to applications, which are projected via some transform to the true framebuffer.
    • 'In the absence of a composting rasterizer, applications must cooperatively implement effects along the Z axis

      One might say that non-destructive overlapping is a Z-axis effect. While this is true, non-destructive overlapping can be implemented via composable, wholly linear XOR transforms, and thus the overlapping bitmap itself is sufficient information to recover the original bitmap. Thus the distinction is meaningful. Note that "composable" is used here in the mathematical sense, rather than that of computer graphics. - nickblack.atl (talk)

Display Managers

A display manager is essentially a graphic equivalent of the console environment's getty apparatus. They typically run independently of window managers (indeed, they are more tightly bound to desktop environments and session managers than window managers), with privileges similar to those of the login process. XDMCP can be used to communicate with a display manager running remotely, though I wouldn't recommend it. Sprezzatech currently recommends use of LightDM, unless one is making use of the KDE desktop environment, in which case KDM is recommended. Please note that GDM is recommended by the GNOME team for GNOME sessions, though our experience with LightDM in this capacity has been very positive. Note that only LightDM, Orthos, and XDM aim to support desktop environment independence, facilitating a single display manager experience across multiple session types. All display managers known to this author allow for selection from various session types, when present.

Well-known Display Managers
Name Package Project of origin Notes
LightDM light-dm X.org GTK/KDE/Razor-QT/Unity frontends
GDM3 gdm3 GNOME 3 Theming completely incompatible with GDM2
GDM2 gdm GNOME 2
KDM kdm KDE Uses QT

Themeable using KDE GUI tools

Orthos orthos Independent Pure OpenGL, highly configurable
XDM xdm X11R3 As ugly as they come

Window Managers

Desktop Environments

X

Also known as the X Window System and X11 (due to protocol version 11 having been in place since September 1987), the X.Org Server has been the mainstay of Linux GUIs almost since Linux's inception. Its primary manpage is X(7). It is typically launched from the command line using startx, or indirectly via logging into a display manager.

startx

Theming

SprezzOS's default theme is Allotrion.

Networked GUIs

X-style forwarding

VNC-style forwarding

See Also

{{#switch:|subgroup|child=|none=|#default=

}}{{#ifeq:|Template|{{#ifeq:|child||{{#ifeq:|subgroup||{{#switch:the desktop environment

|doc
|sandbox
|testcases =
|#default = {{#switch:
 |plainlist
 |hlist
 |hlist hnum
 |hlist vcard
 |vcard hlist = 
 |#default = hlist
 }}
}}

}}}}}}