On Sunday 01 December 2002 08:43, Zack Rusin wrote:
<snip>
> interface in the KTextEditor : RichTextInterface. RichTextInterface
> might sound scary but all it adds is : setFont, setColor, setSize,
> setItalic, setBold, QString htmlText and QString asciiText. I think
> that's all we'd need for our purposes.
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.
For rich text in emails, the most important things are (in order of
importance):
1. bold, italics and underline (*bold*, /italics/ and _underline_)
2. fixed and proportional font (ascii art vs. flowed text)
2a. lists (bullet and ordered)
3. horizontal alignment ( this is centered )
4. left/right margin
5. size
6. color
7. font
(2/2a) can even be expressed in text/plain format (2: format=flowed
only), while everything but (I guess) margins can be expressed in
t/enriched.
If KMail send HTML-mails, then people are softly forced to accept html
mail. That's a big step backwards in perceived security of KMail.
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;
// ...
};
namespace KMail {
class PlainTextVisitor : public KTextEditor::RichTextVisitor {
QString mBuffer;
public:
QString result() const {
return breakLongLines( mBuffer );
}
void visitPlainText( const QString & plainText ) {
mBuffer += plainText;
}
void visitBoldText( const QString & boldText ) {
mBuffer += '*' + boldText + '*';
}
void visitItalicText( const QString & italicText ) {
mBuffer += '/' + italicText + '/';
}
void visitHardLineBreak() {
mBuffer += '\n';
}
};
class HtmlVisitor : public KTextEditor::RichTextVisitor {
QString mBuffer;
public:
HtmlVisitor( const QString & title )
: KTextEditor::RichTextVisitor(),
mBuffer( "<html><head><title>" + title + "</title></head><body>" )
{
}
QString result() const { return mBuffer + "</body> </html>"; }
void visitPlainText( const QString & plainText ) {
mBuffer += excapeHtml( plainText );
}
void visitBoldText( const QString & boldText ) {
mBuffer += "<strong>" + escapeHtml( boldText ) + "</strong>";
}
void visitItalicText( const QString & italicText ) {
mBuffer += "<em>" + escapveHtml( italicText ) + "</emph>";
}
voidVisitHardLineBreak() {
mBuffer += "<br/>";
}
};
}; // namespace KMail
> - refactoring most of the
> things into libkdenetwork (so that both KNode and KMail can use it),
> - changes to the address line widget,
I like the Netscape table widgets, so: Mozilla style or config'able.
> - changes to the attachment handling code.
<snip>
Keep. Unify with mime part tree viewer.
> Comments?
Marc
--
'When you see the ping of death, duck and cover.'
-- Bruce Schneier, Crypto-Gram Oct 2002
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021201/139d2f64/attachment.sig>