KTextEditor && richtext (Re: [Design] New composer.)

[Zack Rusin]

On Sunday 01 December 2002 08:18, Marc Mutz wrote:
> I'm still of the opinion that we should start with text/enriched
> composing instead of text/html. If font, bold, italic, size and color
> are the only attributes of text (we'd need at least <tt>, too!)
> anyway, then text/html is overkill. t/enriched can do all that plus
> horizontal alignment.

Yes I agree it's just that I'll take whatever KTextEditor components let 
me too. And text/enriched is not an option in any of them.

>
> For rich text in emails, the most important things are (in order of
> importance):
<snip>

ACK.

> The only problem I see with KTextEdior is that we (KMail) should
> automatically choose the right format. If people are forced to choose
> between html, t/enriched and plain text, they will choose poorly.
> KMail can try to send t/p, t/e and t/h in that order, transparently
> adding mp/alternative for at least t/h.
>
> KTextEditor doesn't seem to provide an interface to access the markup
> from the outside. So how about adding a visitor interface:
>
> class KTextEditor {
> //...
> class RichTextVisitor {
> virtual void visitPlainText( const QString & plainText ) = 0;
> virtual void visitBoldText( const QString & boldText ) = 0;
> virtual void visitItalicText( const QString & italicText ) =0;
> virtual void visitHardLineBreak() = 0;
> };
> /** Accpet a visitor and show him the format of the text without
>     exposing your internal text representation */
> void accept( RichTextVisitor & visitor ) = 0;
> // ...
> };

<snip>
Well, it'd be the ideal solution. It'd be perfect but... (there's always 
a but, isn't there?). 
The problem is that KTextEditor interfaces are implemented by already 
working editors. So with the Visitor we'd have an incredible amount of 
parsing we'd have to do on a couple of levels.
Lets say that we have a QTextEdit based KTextEditor component. Whenever 
we'd like to work with visitors. We'd have to get the full text from 
QTextEdit component in HTML, now use some kind of HTML parser that 
would go through the text recognizing the tags and calling the 
respective visitor functions with the contents. 
Would that be hard? Propably not. In fact using QDomDocument, and 
passing around recognizable tags text to the Visitor wouldn't be that 
bad. 
So all in all it's a matter of implementing at least one fully working 
editor that would do all that. I see what I can do about that.
We'd also have a rather huge problem with automatic detection of the 
format. You see one of my biggest goals is to make sure that emails in 
reader window look almost the same as in the composer. So if you have 
set that second level quoting font color to yellow and first level 
quoting font color to blue for the reader win, that's how you'd see 
them in the composer. (look at the Evolution composer screenshot I 
provided in the last email to see more less what I mean).


Zack

-- 
heuristic algorithm seeks stochastic relationship