Clientspace, userspace

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Hi all,

Today's big realization was that when separating clientspace from
userspace, we should make the *windowspace* top-level and everything
else inclusions. (Mabe we've talked about that before, but if so, I
don't remember.)

The windowspace is the space that has all the data about what's shown on
the screen: the window positions, the views shown in each window, the
dimensions, and THE CURSOR POSITIONS (in fact, the windows' maincells
are the cursors of those windows also). Now, when the client starts up,
what it'll load is the windowspace, and all the other stuff will be
included in it. The other way around, this means that NOTHING ELSE
depends on the windowspace. And this means that--

We can expunge (remove from the system) old versions of the windowspace
which we don't need any more, without breaking anything else!!

This means that the dreaded cursor versioning problem finally has an
adequate solution. We can simply forget about the old cursor positions
without problems. This also means that we need not make any compromises
about saving because of the amount of cursor data saving often will
create. Theoretically, _we can even save the user's data on every
keystroke, but save the cursor data much less often._

And, we can undo the changes in the user data independently from the
changes in cursor position. (This is very important for undo usability.)

The basic design Tuukka and I talked about on IRC has four parts:

- The windowspace, as explained above. A space with the default layout
is forked for a new user. It includes the userspace.
- The userspace, which contains all of a user's personal data. An
essentially empty space is forked for a new user. Includes the
configuration and the internals space.
- The configurations space (slice) with all the system data users want
to configure: dimension lists, key bindings, view lists. A space with
the default settings is used (until a user modifies it).
- The internals space (slice), with stuff that 'enacts' the system and
normal users don't want to think about. For example, the implementations
of the clasm library goes here. The normal space containing these things
is used.

There is one problem: We easily want to be able to fork a new
windowspace for an existing clientspace; but the cursors in the
windowspace need to point somewhere to start with, or we'll just get
errors. If we fork a generic windowspace, of course the cursors cannot
point anywhere yet.

And there's a nice solution: When a window's cursor is found to point
nowhere on view generation, we simply make it point to the homecell of
the userspace. This is nice because it's a behaviour we want anyway-- if
a cursor is set to nowhere because of a bug in the program, we do *not*
want to get a "RASTER ERROR"!

- Benja