[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] ``xu_link_space--benja``: Put xanalogical links into the same
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] ``xu_link_space--benja``: Put xanalogical links into the same space |
Date: |
Sat, 16 Nov 2002 20:29:20 +0200 |
User-agent: |
Mutt/1.4i |
>
> ===================================================================
> ``xu_link_space--benja``: Put xanalogical links into the same space
> ===================================================================
>
> Xanalogical links are currently stored in a different space,
> because we do not want the cells that make up the link
> to be shown as transclusions. However, this introduces
> additional complexity, such as the need to know about
> two different ``Space`` objects in many places,
Which places?
> or
> to have a Storm pointer reference in the main space that allows
> loading the link space.
Why is this a problem?
> Additionally, links are not the only place where we do not
> necessarily want transclusions to be shown. Other examples
> include marking spans to make links (we do not want
> the mark cells to show), an applitude to render textured
> vector graphics (we do not want the cells containing
> the textures to show), and so on. Whenever a cell's contents
> are not actually 'user contents' but are used in the
> lower-level fabric of the system, we don't usually want
> them to show up as transclusions.
This is true.
> Finally, links should be first-class members of a space,
> available for connections. For example, it should be possible
> to connect an explanation to a link (like 'this is related
> because...'), which could be rendered in the middle between
> the link's endpoints on the screen. It should be possible
> for such an explanation to be a clone of something else
> in the space etc.
This is also true.
I think the two latter reasons are much better than the first one;
you might want to concentrate more on them.
> Thus, I propose to put the links into the same space
> and to have a more generally useful way for avoiding
> to show them as transclusions.
Ok, agreed.
> As for this way, for now I propose
> to have a dimension ``a.hidden-transclusion``; if
> a cell has a posward connection on ``a.hidden-transclusion``,
> it will not by default be shown in that kind of context.
> (Of course, for diagnostic views, we may want to view
> such cells also.)
Hmmmm... This sounds like a really bad kludge. Any other way?
> Notes:
>
> - The respective applitudes creating the cells are responsible
> for putting the additional connection in.
> - Often, the connection on ``a.hidden-transclusion`` will
> simply be to the cell itself, thus forming a single-cell
> ringrank. Since it doesn't matter what the connection
> is to, this is convenient.
> - The ``a.`` prefix is for 'attribute,' since this
> is an attribute of a cell.
Ted did have in his designs flags and attributes of cells...
Tuomas