[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

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

On 11 Jul, Tuomas J. Lukka wrote:
>> 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.

Yes, and because we want to separate these two different things, we
need to replace some of d.2 with a new dimension, because otherwise we
would have to define d.2 as a "user playground" and system-only at the
same time. I didn't mean nothing more.

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

Excluding dimension creation/deletion and changing bindings and some
other config stuff, at least in the future. I share your opinion that
one cell (IMHO home cell) in the beginning is the way to go. You would
then turn to another dimension or look at another view to access the
config stuff, right?

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

OK. But then we'll still need some way to handle irrational data there;
we must check for loops and what do we do when the user accidentally
moves all the binding away and can't do anything. That's why I
suggested making all the data read-only and let the user have some way
to commit reasonable configs.

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

Agreed, as well as primitive != advanced. I tried to propose something
in-between. A concrete proposal: user can create a bindings structure
like the one in use at the moment, perhaps cloning the system bindings.
When she wants the new list into action, she is just going to press some
key on "Bindings" cell. If the list seems to be OK (it's not looped,
it's not null), it is copied to replace the old bindings list of the

And what comes to read-only cells, I can see them as a temporary
solution - someone has to have the rights to modify them, but who are 
someone? In long term, I think we need a more fine-grained access
control system - something the Unix people and OO people had to find
out too.

Sometimes these dialogs feel like fighting against a windmill; I know
you have some long-term goals in your mind, but it's hard for me to
help in design when short-term and long-term goals are mixed and I
can't see the same things as you see by intuition. I could stay quiet,
but that's not a good way to use my brain, is it? I'm going to try to
express my doubt as small questions - I hope this way I can tune in to
your vision.


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