[Top][All Lists]
[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
- [Gzz] Linked or associated nodes vs. xuLinked enfilades, Matti Katila, 2003/05/09
- Re: [Gzz] Linked or associated nodes vs. xuLinked enfilades, Tuomas Lukka, 2003/05/10
- Re: [Gzz] Linked or associated nodes,
Matti Katila <=
- Re: [Gzz] Linked or associated nodes, Tuomas Lukka, 2003/05/10
- Re: [Gzz] Linked or associated nodes, Matti Katila, 2003/05/12
- Re: [Gzz] Linked or associated nodes, Tuomas Lukka, 2003/05/12
- Re: [Gzz] Linked or associated nodes, Matti Katila, 2003/05/12
- Re: [Gzz] Linked or associated nodes, Tuomas Lukka, 2003/05/12
Re: [Gzz] Linked or associated nodes vs. xuLinked enfilades, Alatalo Toni, 2003/05/11
Re: [Gzz] Linked or associated nodes vs. xuLinked enfilades, Benja Fallenstein, 2003/05/10