First of all, a Display Manager (or DM, e.g. xdm, gdm, kdm) is not the same as a Desktop Environment (or DE, e.g. GNOME, KDE, XFCE).
The Display Manager takes care of graphical login, and decides (or lets you choose) what session to run. Or what session*s* in case you choose the "switch user" menu option.
A Desktop Environment is basically a collection of programs (display manager, window manager, session manager, panels, configuration tools, etc.) and libraries (e.g. Gtk) that intend to give a consistent and integrated environment to work in.
A Window Manager manages windows: where to place them, move them, resize them, minimize/maximize them, tile them, etc.). It also handles the shortcuts to do those things. In some cases the window manager also paints the borders of windows, in other cases this task is off-handed to a "window decorator".
The "Run Application" dialog in GNOME is part of gnome-panel
, but in another DE it could be another part of the environment.
Who is in charge of painting windows etc. depends; in case there is a "compositor" in use (often part of the window manager, e.g. in Compiz) then the compositor paints the windows on the screen, otherwise (as was usual in the past) it's the X-server doing that.
The Main Menu(s) are put on the screen by a part of gnome-panel, but the data used comes from a bunch of files in /usr/share/applications/
(possibly combined with an equivalent directory in your home for personal changes). Those files have a structure defined by FreeDesktop.org (a platform for different DEs to collaborate on common infrastructure), so that GNOME and KDE know about the same programs (but still can show them differently, and in some cases prioritize "native" programs over "foreign" ones).
And yes, different users can use a different session configuration (and can even define their own ones). In GDM, try the Session drop-down for the available choices.
Furthermore, it is possible to mix & match several components, but that will sometimes result in less cooperation and a loss of "smoothness" in how things work. One very well known example where things get exchanges is of course Compiz, which replaces Metacity if you want fancy desktop effects. But there are lots of other changes possible.
You can use feh -FrzD30 /path/to/pictures
to start a slideshow with a 30-second pause between pictures (change 30 to whatever you want the delay to be). Using slim
(as a login manager) I was able to get the slideshow to start at login and present a gui on exit (Esc) with the following ~/.xinitrc
:
feh -FrzD30 /path/to/pix
exec fluxbox
You'll have to use slim and change your WM to fluxbox
(though I suggest you do install and try fluxbox), or look up how to get your desktop manager to use your ~/.xinitrc
. And if you want an auto-login, you'll need to look that up for your DM too.
Best Answer
There's no similar mechanism, because the reasons are completely different.
A garbled text terminal comes from having multiple sources all writing to the terminal, with no coordination between them. So you end up with text where it doesn't belong, which is solved by making the application whose text you do want to see redisplay what it wants.
xrefresh
is the analog of that. It's more rarely needed because the X server already manages coordination between applications: each application is supposed to draw only in its own window.xrefresh
is only needed when an application behaves badly — as opposed to the situation in text terminals, where there is no way to behave better.As for the equivalent of
stty sane
to restore input settings, this doesn't normally apply because applications aren't supposed to modify global parameters — here again each application is supposed to mess up only its own windows. There are a few bad things that come up, such as an application grabbing the pointer or the keyboard (xdotool key XF86Ungrab
, or Ctrl+Alt+Keypad/ if enabled).If the display remains blank or scrambled due to a driver bug, there's no generic recovery mechanism. Anyone who's done any serious programming knows that there's no completely generic recovery mechanism after a bug, because a bug is by definition something unexpected and since you can't predict the state of the system after the bug is detected, there's no way to be sure that whatever you do will work as intended to restore it. The only sure-fire way to recover from a bug is to appeal to a higher authority: for example, if a bug is detected in a process, kill it (because of process isolation, the bug should be confined to the process) and start a new instance. If the bug is detected in the kernel, the higher authority would be the hardware — reboot the computer. In the case of a display driver bug, usually what is affected is only the state of the GPU, so resetting the GPU would be enough. As far as I know, there's no generic way to tell X.org drivers to reset the GPU and reinitialize it to their tastes. There are a couple of things you can try, but they don't always work:
Try disabling all of the displays with
xrandr
, e.g.That can help occasionally, but not very often, because usually the bug is between the driver and the GPU and isn't affected by the displays.
xrefresh
doesn't, so I suspect that ifgnome3 --replace
helps, it's because it restarts Compiz.