KRichTextEdit for kdelibs

[Eric Laffoon]

On Saturday 19 April 2008 8:36:41 am Thomas McGuire wrote:
> Hi,
>
> Am Samstag 19 April 2008 12:57:53 schrieb Jakub Stachowski:
> > > * a KRichTextEdit, which started of as KMEditor in libkdepim, and I
> > > took all the mail-type stuff out of it like signatures, quoting and
> > > boxing.
> >
> > Is this enough for mail clients? For example KMail currently is unable to
> > reply to HTML email without losing original formatting. That
> > unfortunately forced me to use Thunderbird at work :-(
> > I wonder if KHTML or QWebKit widget with contentEditable=true would be
> > possible here.
>
> I don't know if this is possible. Quanta has a VPL editor which uses KHTML,
> but as far as I know, it has some problems.
> Who knows, maybe calling QTextEdit::setHtml() with the HTML of the original
> mail actually does The Right Thing. I haven't tried that yet, though.
>
> Regards,
> Thomas

Actually there's plenty of folly to go around. With Quanta we ended up with 
several complete rewrites. The complexity was enhanced by needing to support 
more than just HTML in the parser, so we had to sync trees. All that aside, 
what the VPL set up did was precisely match the DTD using the XML based tag 
files and parser. In fact Quanta can read DTDs on the fly and integrate this 
in the markup engine. So there you have a none too simple start, and it gets 
worse. Quanta is designed to allow the user to select their markup options 
like text (span) or block (div) and extending the full power of the HTML and 
CSS to the user. That's probably too granular for a user oriented graphical 
markup tool. What you end up with is the slippery slope of compromises and 
realities that devolve to a nightmare where developers accept that email 
won't be W3C compliant and achieve uniformity the same way as fast food, cut 
corners... add grease and pour sugar on top. That's mass consumption.

Our longshot hope has been webkit, which has had extensive work done on it in 
the new Qt. Andras recently finished doing some work to make the parser 
incredibly fast even on huge files. So if we had working code I'd love to 
share it. The problem is the amount of work it has proven to be and getting 
somone to devote the time. Our problem is also we have often been outside the 
loop, so something comes along in KDE that's almost adequate to our needs, 
but not quite. Then it ends up unmaintained by the next version. It would 
also be great to have something that works for our most demanding needs that 
could be adapted to less demanding needs. It's a tall order, but having a 
number of projects using it would mean a great potential for the requred 
developer effort.

I'd be willing to look at how we could offload the bare essentials to make a 
visual HTML component work if I could get someone to collaborate with. 
Unfortunately we need to throw out our code and start over, but I think it's 
possible that the framework for what we wanted to do may finally be much 
closer. One thing we do have is the experience in knowing what ends up not 
working. One can easily invest  months getting to the point of realizing the 
entire approach is not capable of returning the desired result. If you're 
interested let me know or open a discussion on quanta-devel.

-- 
Eric Laffoon
Project Lead - kdewebdev module