Imagine that your computer's screen is larger than your physical monitor. To make this example more specific, imagine that it is four times wider and four times taller than your physical computer monitor. The "virtual" computer screen that you would then have at your disposal is 16 times as big (4 x 4) as your real screen.
But of course you can only see one physical screen's worth at a time (full-size at least). So your physical screen becomes a "viewport" through which you see this much larger virtual screen.
In principle, the virtual screen can be any size and the vieport can be moved to show any part of it. In practice, it is usually convenient to make the virtual screen width and height integral multiples of the physical screen's width and height.
It is also sometimes convenient to think of the virtual screen as being divided up into a grid of physical-screen-sized rectangles. That way you know where you are within it. But this grid is just a navigational aid. The underlying virtual screen is just one big screen (there are no grid marks necessarily displayed on it) and you don't have to move your viewport just to rectangles on the grid.
This "virtual screen" or "viewport" system is, I put it to you, in principle the most basic way to conceptualize and work with screen resources which exceed the capacity of a single physical screen. You can't get much simpler than "a virtual screen larger than your physical screen."
(Aside: FVWM calls this facility the provision of a "large virtual desktop.")
This system of "viewports" has three advantages, two practical and one philosophical.
The first practical advantage is simply that it gives you as much screen as you need. Your computer screen is your office and workshop. You can't get real work done in a tiny closet; you need a relatively large office.
The second practical advantage is that it allows you to work with windows which are larger than your physical screen. If your windows are limited to at most the physical screen size, then to view anything larger you must either view only a tiny part of it and scroll around within it, or shrink it down to a tiny size.
So for example say you have a photograph which is 3800 pixels wide (easily within the capacity of even a medium-grade camera today (2014)). You wish to look at the whole thing close-up, just as you might once have looked at a very large print of it. Say your screen is 1920x1080 pixels, so that in practice within a single window you're limited to probably 1800x1000 or so. If your viewer window is limited to your screen size, and you want to look at it 1 camera pixel per 1 screen pixel, you can see at best 1/4 of this photograph. You have to scroll around within it to see it all, which is by no means satisfactory.
With a large virtual screen, you just display a window big enough to show the whole image, 1:1. You can only see one screen's worth at once, but you can move the screen easily around the entire photograph (with no need for scrollbars).
You might argue that the scrolling within your image viewer did the same thing, but that is not the case. The scrolling within the image viewer gives you a view of a part of the image, divorced from everything else. You can't bring up another window within the image viewer's scrolling window to do something prompted by a part of the image - this is so alien to the approach that it's hard even to imagine.
The Viewport paradigm lays the large image/window out on your virtual screen all at once, along with everything else that you might want to have on your screen.
On the philosophical side, the virtual screen / viewport paradigm has the advantage that it functions perfectly as a metaphor for a large desk or table. If you move left or right, you're just moving left or right on the same screen. If you push a window halfway off the screen to the right, when you move your viewport to the right you find the part you pushed off. (This becomes a serious problem with "grids of workspaces," as we'll see below.
A "Workspace" is just a computer screen. (We'll see later that it can be either a virtual screen or a physical screen, but since 2003 Workspaces have been physical-screen sized.)
You can have multiple Workspaces. But the point about Workspaces is that they're all entirely indpendent of one another. They don't connect. At all.
(Aside: FVWM calls Workspaces "multiple disjoint desktops.")
True, you can use a little program which shows your various workspaces arranged in a grid. That's very common in KDE and Gnome. But this is just a way of collecting and going to your Workspaces. Each Workspace in the grid of them is completely separate from every other Workspace in the grid.
This leads to some pretty obvious confusion, because the grid of Viewports (see above) is intuitive while a grid of Workspaces is not. It isn't hard to find remarks by puzzled users online wondering what happens to the other half of a window when they slide it off the edge of one Workspace and expect (naturally) for it to show up in "the next Workspace over." It doesn't show up there, of course, because there is no such thing as the next Workspace over - they're all independent.
Workspaces have their place, but when the navigation to them implies that they're in a row, or in a grid (as is usually done), they are inherently confusing.
Fortunately, Viewports and Workspaces play well together. Viewports are the more basic of the two. So at a first level, you configure your interface with a large virtual screen accessed with the Viewport mechanism. (How large is a matter of choice; I find 4x4 times the physical screen size to be convenient.)
Having such a Viewport scheme basically gives you a large office/workshop. But sometimes you have two jobs (or sometimes you have a job and personal activities which need at least logical separation). To accomodate this, you set up multiple Workspaces, each of which is a Viewport/virtual screen. Each "Workspace" then becomes what a "workspace" logically should be: a place for doing one particular kind of work.
Navigating workspaces by trying to place them in a row or grid is, as we've seen, illogical. It implies that you can slide objects from one to the other when you can't. It's best just to think of Workspaces as they are: separate. This is accomodated very well by the FVWM Pager. You set it up to show a grid for the virtual screen (Viewport mechanism) in a Workspace, and then to tell you in its titlebar which Workspace you're in. If you wish, you can think of this as a "stack" of Workspaces, each of which implements Viewports.
Until 2003, the most promising desktop was Gnome, and the window manager of choice running under Gnome was Enlightenment. Enlightenment provided both Viewports and Workspaces, and all was well in the world.
Then one of the developers of Gnome decided that Viewports were too complicated a concept for users to handle, and ripped them out of Enlightenment. All that remained were Workspaces (and grids of Workspaces). This act of senseless vandalism marked the beginning of the decline of Linux user interface design.
Normally this wouldn't have been a big problem, because the normal Linux and open source way has always been to provide many options. The natural response to this was simply to use a different window manager - one that did support Viewports. (The obvious candidate is FVWM, which has always supported Viewports.) But at the same time the desktop developers were becoming more ambitious, and were staking claims over the once-clean division between window managers and desktops. Now only certain window managers are "supported" by particular desktops - a disaster for modular system design, but a fine territorial grab for desktop developers. FVWM under Gnome became a losing proposition.
For many years after that - and perhaps even today - you could solve the problem by running KDE instead, with FVWM under it. But around 2010 this combination, while still theoretically possible, also became in practice unworkable.
(There is a curious footnote to all of this. It appears from at least some online documentation that I've read that the Compiz window manager has rediscovered the idea of viewports. That's great, insofar as it goes. But Compiz is a part of the great food fight which characterizes Linux desktop design in the 2010s. (Ironically, Compiz (a window manager) inverts the power-grab of the desktop developers into window manager territory. Compiz considers the Unity desktop shell to be a "plugin" to the Compiz window manager.) This is a mess I don't even want to get near.)
The solution is radically simple: don't use a "desktop" at all, but rather use only a window manager which supports both Viewports and Workspaces. FVWM is such a window manager.
You sacrifice the rotating cubes and chorus lines of dancing fish that you get with modern desktops, but in place of this you get a substantially faster working environment which provides greater basic functionality.
All portions of this document not noted otherwise are Copyright © 2014 by David M. MacMillan and Rollande Krandall.
Circuitous Root is a Registered Trademark of David M. MacMillan and Rollande Krandall.
This work is licensed under the Creative Commons "Attribution - ShareAlike" license. See http://creativecommons.org/licenses/by-sa/3.0/ for its terms.
Presented originally by Circuitous Root®
Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]
