Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] :gzz: d.system (wuz Re: [zzdev ] :gzz: Alte ring "system list" (wuz Re: [zzdev] :gzz: Story of an unsu spected crash spiral (v.0706)

["Tuomas J. Lukka" <lukka@xxxxxx>]

On Tue, 11 Jul 2000, Tuukka Hastrup wrote:
> On 11 Jul, Tuomas J. Lukka wrote:
> >> Like always, I suggest re-thinking and a new implementation. I still
> >> don't quite understand how you're going to keep going with these d.1,
> >> d.2 and d.3 as "universal" dimensions - I could think there'll always
> >> be clashes like this.
> > 
> > Clashes? I don't see this as a clash; we need to make some part of 
> > the space non-user-modifiable. A new dimension for that is fine.
> 
> Depends on how do you look at this. A clash as we have to divide d.2
> into to two to allow hiding the other part. A new dimension works fine,
> sure.

No, the point is that there are two different things here: 
there's the user's view of the whole space and there's the system list.

At the moment, the system list is forced to be in the default view
but it doesn't have to. It would be much more beautiful to start 
from a screen with just one cell than with the current, frightening
array of cells that users don't need to see since everything can be
done from the keyboard.

> >> My intuition says we should change d.1 and d.2 in system space to
> >> d.system and d.system-list. 
> > 
> > One of the ideas is that d.1, d.2 and d.3 are the dimensions the user
> > will be looking at most often.
> 
> Yup, this I've been told. Now, wasn't it that we were to change the
> current system space so that the ranks don't run along d.1 and d.2 but
> some new system-only (read-only, I think) dimensions?

No, only the main system rank that the system uses to find stuff
like the bindings, the default dimension list etc.

> >> And I think we should make sure no user
> >> will want to explore and modify these. 
> > 
> > The window list and the bindings are *supposed* to be user-modifiable.
> > As are the view parameters; the user should be able to make a new view
> > type easily.
> 
> Of course. IMHO it won't be easy to define these restrictions as just
> by defining some connections to be read-only. What about the cell data?
> Like when we run along the rank and search for "Bindings" or such.

Marking cells readonly will be possible (good point).

> > We don't want to lock the user out of the loop; we just want one part
> > of the system to remain stable so that the system knows it can access
> > certain things through a path from the home cell.
> 
> So maybe we're to use two new dimensions that the user can't modify,
> and use some hard-coded paths to access the data.

No because the user must be able to modify the bindings.
The user shouldn't be able to change where the system looks for the 
bindings but the bindings are something the user has full rights to change
at will.

> >> There should be nothing so
> >> special there: we'll make a new Action list for the user (not in that
> >> awful linear format) etc. Nothing says the user must use the same
> >> Actions-list as the system's using. 
> > 
> > We should have a list of the actions somewhere from where they can be
> > cloned to wherever the user wants.
> 
> Which doesn't mean they can't be initially in some reasonable order.

Of course they should be in a reasonable order.

> >> Could it
> >> already be time for some advanced UI components?
> > 
> > What do you mean by those?
> 
> This menu-thing we've talked about. It needs the new flob and cursor
> stuff though. And maybe we'd answer the problems with dimension and
> view handling with some sort of "wizard views" that would first check
> the changed cell configuration before commiting the changes into the
> system space.

Sounds more complicated than it really needs to be for ZigZag.

Complicated != advanced.

	Tuomas