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)

[Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>]

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.

>> 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?

>> 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.
 
> 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.
 
>> 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.

>> 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.


Tuukka 

----------------------------------------
E-Mail: Tuukka.Hastrup@xxxxxx
WWW:    http://www.iki.fi/Tuukka.Hastrup
ICQ:	#11321669