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

Re: [zzdev] Nile



Tuomas Lukka wrote:
>
> Now, the biggest challenge here is to abstract and encapsulate it
> to a sufficient degree; I'd like to be able to use the same text-editing
> machinery in a variety of situations. That's why I haven't put in
> bindings for the different levels of headings etc. just yet, since
> those should be applitude-dependent and pluggable.
> 
> Similarly, things that we need for writing articles, such as
> references and figures should be put in as an independent, pluggable
> applitude.

The one thing I would like to see soon is cloning (and once we have
versioning&pull-outs, transcopying) of part of a Nile stream. The other
thing is that I would like to use it for my applitude. Now that things
start falling into place concerning the zaubertrank, I see that I
desperately need a good text editor supporting variables, i.e. something
like "bla bla <var> bla bla," where <var> is shown like normal text (by
the line breaker etc.), but treated like a single entity (somewhat like
one character) by the cursor, hopping etc. algorithms.

I think generally we need:
o textual "objects" in the stream which can be edited with the Nile commands,
o textual "objects" in the stream which cannot be edited with the Nile
commands, and
o graphical "objects" in the stream, which of course also cannot be
edited with the Nile commands.

Textual objects' applitudes would be called for FText.Part arrays or the
like. Maybe graphical objects should be, too: one could construct
FText.Part subclasses which put graphics on the screen. On the other
hand, we want to have figures which are surrounded by text, not included
into one line of the text -- there, it gets harder.

Any others I forgot?

> The whole framework needs a lot of thought.
> 
> One thing I'd like to do would be to have it be possible to have the
> currently active text at one place, and then all the connections from it to
> other places floating around it.

Yep. (What we need first, though, is a framework to *make* the
connections, and have actions which jump between them... the view comes later...)

- Benja