gzz-dev
[Top][All Lists]
Advanced

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

Re: [Gzz] Linked or associated nodes


From: Matti Katila
Subject: Re: [Gzz] Linked or associated nodes
Date: Sat, 10 May 2003 21:17:37 +0300 (EEST)


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.


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.

> 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?
 
>> 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.


>> (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.*

>>    {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.
 
> (BTW: it's "Mary", not "Marry" - to marry is a verb.)

Hmm, I must have been though about marring too much ;)
 
>> 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?
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.
 
> Third way: new RDF structure.

?
 
> Here, you need editing: say the point the example intends to make
> *before* the example, and it's much easier to follow.
> 
>       However, this is a problem for e.g. computer code
>       where you want to retain the spacing and indentation.
>        
>               *This is the maximum of text width*
>               ***********************************
> 
>       If we blindly break the lines in 
>       
>               def foobar():
>                   if foo and bar and asdf and jkl and fiuu:
>                       pass     
>       
>       we get
> 
>               def foobar():
>                    if foo and bar and asdf and jkl 
>               and fiuu:
>                            pass     
> 
> Are you implying that we need to be able to say that this is code
> and some other text is not, for formatting?

Yes, there are many issues about text editability. Something like 
different loadable modes or macros like in famous text editors.


>> 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) :)  


   -Matti





reply via email to

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