[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Applitude connectivity, was: Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...
- To: Tuomas Lukka <lukka@xxxxxxxxxx>
- Subject: Re: Applitude connectivity, was: Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...
- From: Benja Fallenstein <b.fallenstein@xxxxxx>
- Date: Sun, 06 Oct 2002 11:11:24 +0200
- Cc: zzdev <zzdev@xxxxxxxxxx>, gzz developers list <gzz-dev@xxxxxxxxxxxxxxxxxxxxxxxxx>
- References: <20021006073500.GK1203@xxxxxxxxxxxxxxxx>
Tuomas Lukka wrote:
programmed in a modular fashion. Also, all the applitudes have been
designed carefully so that unanticipated connections will be possible,
as far as is feasible.
This is the thing on which the whole long email rests; now,
the big question is: is the paragraph representation you suggest
in accordance with this?
Yes, I know, but I didn't answer that question, I replied to the more
general question whether applitude overlap w/ interpretation is possible
What, exactly, are the rules here?
Ok, these things *are* actually quite difficult when it comes to
paragraphs, but fortunately, with hierarchical containment things get a
little nicer ;-)
Let me first summarize the problem:
We want to have the paragraphs available as cells, for linking. The idea
is that whenever an applitude has an item X, it tries to assign exactly
one cell to it, and doesn't delete or change that cell for the whole
lifetime of item X, so that other applitudes can make connections to it
and have them stay. With paragraphs, the problem is that two paragraphs
may be joined into one, without the second paragraph really
disappearing-- its text just became part of the first. If we try to
separate the paragraphs again, by hitting "Enter" where we separated
them, the second paragraph may come back as it was-- but without the
links to it, since to the applitude, it's still a 'new' paragraph.
My proposal for paragraphs through the containment mechanism doesn't
completely solve this problem, but does alleviate it.
The point is that because of the hierarchical containment, we never need
to split or join a cell. When there were two paragraphs, P and Q, with
their own cells along d..contain-set, and the user joins the two
paragraphs, cell Q never disappears: only its "paragraph start" mark is
removed. When the user inserts a paragraph break into P, the cell isn't
really split; we just split what's *inside* it into multiple cells
*contained* in P, and one of these cells has a paragraph start mark. P
therefore now contains two paragraphs-- If we now make the links mean,
"the paragraph (the beginning of) P/Q is in," our semantics work mostly
Still, this isn't really clean. I don't like that "the paragraph the
beginning of P/Q is in" stuff too much. But structurally, I anticipate
it to work (i.e., the connections should be mostly handled well). Maybe
we can think of something cleaner... But I can't see that, yet.
One issue here is that creating paragraphs and so on will, under this
scheme, inevitably mean changes in the containment structure, though
they shouldn't be horrible. However, users who want to use the
containment structure for certain views might not like it if internal
structure like paragraphs is put on the containment dims... hmmm.
Still, I *want* to be able to see and connect paragraphs as cells. It's
part of the fun. :)