gzz: d.system vs. d.2 (was 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)

[Ted Nelson <ted@xxxxxxxxxx>]

Actually, what I meant to suggest was that the cells could be
 connected on BOTH d.1/d.2 and d.system/d.system-list.

That way, the system *actually* looks along d.system etc.,
 but you can look at them and rearrange them on d.1/d.2.

This is merely a suggestion and not *ex cathedra* :)

Best, Ted


At 12:24 PM 7/11/00 +0300, you wrote:
>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
>
>
>
_________________________________________
Theodor Holm Nelson              
Project Professor, Keio University SFC Campus, Fujisawa, Japan
Visiting Professor, University of Southampton, England
 ?  e-mail: ted@xxxxxxxxxx   ?  world-wide fax 1/415/332-0136
 ?  http://www.sfc.keio.ac.jp/~ted/    ?  http://www.xanadu.net
 ? Coordinates in USA      Tel. 415/ 331-4422
  Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
_________________________________________