KTextEditor

[Zack Rusin]

On Monday 07 October 2002 16:26, Joseph Wenninger wrote:
> The problem you will always have with interfaces is, that not all
> implementors can or want to implement everything provided by an
> interface, you will always have to support workarounds, if you are
> trying to use user configurable plugins, because not all features
> have to be available. (You can easily check if a feature is available
> with qt_cast and inherits. dynamic_cast is not that a good solution,
> if you work with dlopened libraries).

And that's exactly where my problem is at. I'd love to let users choose 
the default text editing component for KDE and use it within KMail, but 
for KMail needs a rich text editing component would be preferable to 
code editing component (e.g. KRichTextEdit vs Kate). Some users could 
make Vim their default editing component because they code in Vim and 
at the same time wouldn't want to compose email's using vim. 
As far as additional interfaces go we could use two:
SpellChecking with a method like ::setIncrementalCheckin( bool on ); the 
rest would be handled by KPart internally. The other one would be 
RichText with methods like 
void setGlobalFont( const QFont& );
void setFont( const QFont&, uint start, uint end );
void setColor( const QColor&, uint start, uint end );
QString exportToHTML() const;
QString exportToText() const;
That's all we'd ever need. 

Zack

-- 
Tact is the ability to tell a man he has an open mind when he
has a hole in his head.