gzz-dev
[Top][All Lists]
Advanced

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

[Gzz] Linked or associated nodes vs. xuLinked enfilades


From: Matti Katila
Subject: [Gzz] Linked or associated nodes vs. xuLinked enfilades
Date: Sat, 10 May 2003 00:50:06 +0300 (EEST)

Well, this issue drives me crazy. Too much thinking. There are too many
variables, too many pros and cons.

Some history:

In ancient times there used to be one node and some text in content of 
the node. It was quite nice to be able to link in structure a node to 
other one. Not a link like xuLink but content could be changed and the 
link would stay as it is. 

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, i.e. it was not doable to link two 
nodes one after other and then edit the content(some thanks to 
linebroken too (linebroken was designed to simple paragraphs so it is 
justified for it to not be good for canvas use)).

   {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). There's no structure to say at 
least {Marry has a lamb.} next sentence is {Marry is a girl.}.

This implicates that having no structure for nodes one after other makes 
none of text editability.


Different approach:

Just put things as always, one node and text into content, and use 
xuLinks. Pros naturally is that linebroken can be used, or can we?

Yes and no, for example:

*This is the maximum of text width*
***********************************

def foobar():
    if foo and bar and asdf and jkl and fiuu:
        pass     

-would perhaps be:

def foobar():
    if foo and bar and asdf and jkl 
and fiuu:
        pass     

hmm, not nice. Ok, you might be thinking that this is programming example 
with bad named variables and not a real case for text writing, really?
Think for example rst text where you want to keep intending and that is 
close to previous example.

Shortly thinking xuLink might be a good answer for linking problem(in 
structure level you can't link more than one node to one(at least 
currently (this is not well enough explained!, fyi))). By saing shortly I 
mean in time. For example you have canvasA where is an annotation what is 
linked to B,C and D (xuLink). You copy the annotation text to another 
canvasB but all xuLink of course follow. So, now you are not interested 
about, let's say C and D. How can I unconnect those but keep annotation 
in canvasA to be right?

Even association is in canvasA to B, C and D that doesn't implication
that association with that text should be in canvasB with C and D or even 
B. With node structure we can change that but with xuLinks we can't, and 
that implications that xuLinking can't be used.

So if we can't use xuLinks that implications that we can't use 
linebreaking with it's current status.


In posted peg 'canvas_text--mudyc' I din't make clear enough all issues 
close to problems presented in this mail. Basically I wanted to say that 
we need additional information in structure if we like to work with text 
not with one note or annotation. Still missing 50% of all issues what I 
have been thinked but much closer already.


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.

   -Matti





reply via email to

[Prev in Thread] Current Thread [Next in Thread]