[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
:zz: Re Home cells? as impacted by Zzpush Interf., Slices
- To: zzdev@xxxxxxxxxx
- Subject: :zz: Re Home cells? as impacted by Zzpush Interf., Slices
- From: Ted Nelson <ted@xxxxxxxxxx>
- Date: Sat, 21 Nov 1998 20:45:18 +0900
- Cc: ted@xxxxxxxxxxxxxx
- In-reply-to: <19981118042617.19566.qmail@xxxxxxxxxx>
- Reply-to: zzdev@xxxxxxxxxx
M'J asks interestingly about multi home cells.
Let me winkle at this one slowly, in terms of two
concepts that are a-waitin'.
One is Zzpush, the long-awaited interface for Netscape / IE.
1) Zzpush is intended to open a plurality of browser windows,
each with its own cursor and refresh sequence on a spatially-
connectged list (and potentially each with its own home cell,
though that hasn't been discussed; presumably such a home
cell would be connected in some particular spatial fashion to
the window, in the same way as its refresh list).
2) The intended method for merging spaces is intended to be
the *slice*, and my grand ukase on the matter has been ignored
by acclamation. But the general idea is that slices may be
merged and connected in an interpenetrating fashion.
(A *default* method would be much simpler to begin with,
using the same cellname alternately on different slices, and
not allow rearrangement (or perhaps other connections and
other operations) across slice boundaries.
As I understand Mark-Jason's suggestion, it's to combine
the naming of homecells with connections in d.1.
I would suggest we create some dimension like d.homecells
to deal with this, so that as new slices come and go with
their own windows and their homecells, they will appear
and disappear seamlessly.
Nothing final about this, just chiming in.
At 11:26 PM 11/17/98 -0500, you wrote:
>
>The homes shouldn't be identified by position, but rather by label.
>The way you can rearrange them or add your own homes for new things.
>
>Suppose they were identified by position, so that #1 was always cursor
>home, and #2 was always delete home, and #3 was always select_home.
>Then one person would add some functions that made #4 the nostril
>home, and someone else would add some functions that assumed that #4
>was the bunny rabbit home, and then it would be hard to merge their
>spaces; they couldn't reorganize the homes, or anything like that.
>
>Suppose instead that when it's looking for FOO_HOME, it jkust searches
>+d.1ward from HOME until it finds some cell that's labelled with FOO.
>Then you can permute the homes, add new ones in the middle or at the
>end, or you can import someone else's KEYBINDING_HOME and link it in
>for a while to see if you like it, etc.
>
>Sorry, that wasn't too coherent.
>
>Mark-Jason Dominus mjd@xxxxxxxxxx
>
>
____________________________________________________
Theodor Holm Nelson, Visiting Professor of Environmental Information
Keio University, Shonan Fujisawa Campus, Fujisawa, Japan
Home Fax from USA: 011-81-466-46-7368 (If in Japan, 0466-46-7368)
Professorial home page http://www.sfc.keio.ac.jp/~ted/
_____________________________________________________
Permanent: Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
Tel. 415/ 331-4422, fax 415/332-0136
http://www.xanadu.net
PERMANENT E-MAIL: ted@xxxxxxxxxx
_____________________________________________________
Quotation of the day, 98.11.21:
"Life is EXTREMELY strange, except we don't notice." TN98