Re: [Gzz] Linked or associated nodes

[Tuomas Lukka]

On Sat, May 10, 2003 at 09:17:37PM +0300, Matti Katila wrote:
> I should have explained the context more deeply.
> Linked or associated nodes I mean the PPConnector thing.
> A node in main canvas has buoy and those two nodes have been linked or 
> associated.

Good, very good to start with this.

> On Sat, 10 May 2003, Tuomas Lukka wrote:
> > On Sat, May 10, 2003 at 12:50:06AM +0300, Matti Katila wrote:
> [one node with content]
> >> This would be enough for ancient times and for ancient people but today 
> >> more and more of users want to be able to edit the text without worrying 
> >> where the node ends and next begins, 
> > How exactly must the user be aware where a node ends and another one begins?
> 
> No he/she shouldn't be aware. That's the point of all this.

No, what I meant is that you imply that some system forces the user 
to be aware. What system does that and how?

> > An alternative structure: all text of a single "stream" in one node.
> 
> Do you mean like:
> 
>  { Donald is a duck. Cat eats the duck. Where is Donald's hat? }
> 
> All text in the single node? This is the current structure, so what's the 
> alternative?

Alternative to what you propose. The question is: what really is wrong
with the current things. 

You're proposing mechanisms to do something before you say what
the something you *want* to do is.

Because there are several approaches. One is to make the text content
of nodes richer, in the sense of e.g. allowing full XHTML inside nodes.
This would solve e.g. the spacing and indent problem using just the HTML
code for those.

So could we start with listing what exactly we want.

> >> i.e. it was not doable to link two 
> >> nodes one after other and then edit the content
> > Why? How?
> 
> So, let's say I write:
> 
>    { Donald Duck is a comic star. }
> 
> And want to link it to another canvas, where is more information of the 
> sailor duck. After linking that I want another sentence. I write the next 
> sentence and want to link that to somewhere but not in the same place as 
> previous sentence.
> 
>    { He is very cute when he's angry. }
> 
> Wanna link that sentence to canvas where are pictures of angry duck faces.
> 
> Ok, now we have:
> 
>    Donald Duck is a comic star. He is very cute when he's angry.
>   (20,0)                       (60,0)
> 
> Coordinates are marked under the nodes. So if I modify the first sentence 
> sligtly:
> 
>    Donald is a comic duck.      He is very cute when he's angry.
>   (20,0)                  ^^^^^(60,0)
> 
> You see what happens because the text content nodes aren't joined in no 
> way to each other in structural level. The are no text editability.

Aahh, now I understand what you wanted to say originally. This example
really clarifies your original sentence.

Hmm, if you had originally said something like

        For example, linking different parts 
        of a single text to different nodes would be impossible ;
        the easiest kludge would be to place two nodes
        with the text fragments next to each other spatially
        but editing would be really difficult.

I think I might have understood the point.

Yes, this is part of the intent of the PP links: they're pretty 
coarse-grained.

> >> (some thanks to 
> >> linebroken too (linebroken was designed to simple paragraphs so it is 
> >> justified for it to not be good for canvas use)).
> > What? Now you've lost me. What does "linebroken" refer to, exactly,
> > and what exactly does it have to do with this?
> 
> Excuse my short words:
>   org.nongnu.libvob.linebreaking.*

Ok, you should now understand that it's a fairly primitive set of classes
which have not yet been developed to where they should be.

They do need the features you talk about. Instead of "we can't
use linebroken" you should say "we need to change linebroken to make also
this possible".

> >>    {Marry has a lamb.} {Marry is a girl.}
> >> There's no structure to keep these two nodes separately but linked because 
> >> of context(same paper and next of other). 
> > 
> > You mean *spatial* structure. That *is* also structure.
> 
> But spatial structure is *not* programmable in sense of text editability, 
> see the example of angry duck.

Yes, if you want them as parts of the same text.

However, if you want them just to be spatially *close* to each
other ("ranskalaiset viivat"), it is actually easy.

> > (BTW: it's "Mary", not "Marry" - to marry is a verb.)
> 
> Hmm, I must have been though about marring too much ;)

And "marring" is something really different once again ;) ;)

> >> There's no structure to say at 
> >> least {Mary has a lamb.} next sentence is {Mary is a girl.}.
> >
> > Spatial structure.
> 
> So, do you have a good algorithm to do text editing programming with that?

Ok, when I said "spatial" there, I meant it from a slightly different
angle, not as in producing flowed text paragraphs but as just placing
the sentences on top of each other for easy rearrangement.

> Some issues:
>   - overlapping texts
>   - text formatting
>   - not every text belongs to one paragraph (for example in one canvas can 
>     be different paragraphs of texts)
>  
> > Another way: put both texts in same node.
> 
> That implies that all linkings to buoys is done from one node and that's 
> the reason why I even started to talk about additional structure.

Why are you convinced that links to buoys need to be from a part 
of the node?

There are still more options, if we use something like XHTML inside
the nodes: using an XHTML anchor!

> >> Issue:
> >> In discussion with Benja, he saw a big problem in joining nodes, i.e,
> >> {cat} linked to A and {dog} linked to B
> >> 
> >> If we want to join {cat} + {dog} we can do:
> >>    - join cat and dog to be in one big node and join links.
> >>        - this causes problems if one want to separate cat from dog
> >>          because we can't anymore to say if B or A was dog's link or 
> >>          some otherwise.
> >>    - join cat and dog next to each other and don't do anything else.
> >>        - this is equivalent with xuLink style but text is more modifiable.
> > 
> > *OR* make a tree-like supernode.
> 
> Benja already was worried about the count of nodes (although not in the 
> same context) :)  

After some timing tests, I can say that we can afford about 1000 nodes per
window. Maybe a little less. With caching parts of the structure, 
some more.

        Tuomas