[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: little reminder on the 3.2 release schedule
From:       Don Sanders <sanders () kde ! org>
Date:       2003-09-22 0:50:33
[Download RAW message or body]

On Monday 22 September 2003 03:31, Ingo Klöcker wrote:
> On Sunday 21 September 2003 19:05, JES wrote:
> > On Friday 19 September 2003 23:06 pm, Ingo Klöcker wrote:
> > > > > I still would prefer doing HTML editing together with the
> > > > > kompose framework Zack is working on for post 3.2. But I
> > > > > first would have to see this in action.
> > > >
> > > > The Kompose framework won't magically implement HTML support,
> > > > someone still has to do that work, the tasks are somewhat
> > > > orthogonal.
> > >
> > > True. But I guess that most of the work to put HTML support
> > > into KMComposer will be done again in order to add HTML support
> > > to some Komposer plugin. Or does the HTML support not heavily
> > > rely on the underlying KEdit (which is based on some long
> > > deprecated Qt class) and on the current layout handling in
> > > KMComposer?
> > > I'm not saying that the work should be stopped. But I'm pretty
> > > sure that most of the work will not be portable to the Komposer
> > > framework so that then the work will have to start from
> > > scratch. Anyway, if I'm wrong with this assumption then just
> > > ignore me. ;-)
> >
> > I'm trying to implement HTML editing support, but as far as I can
> > see now, it has very little to do with KEdit. It only gets the
> > html message from  KEdit.
>
> So you are just implementing raw HTML editting support (as opposed
> to WYSIWYG HTML editting support)? What exactly are you doing? Just
> adding a few buttons for some HTML tags? Or are you just
> implementing the backend which creates multipart/alternative
> messages?

Looking at the patch JES has been working on creating 
multipart/alternative messages, and editing HTML messages in the 
drafts folder. This is work that is completely independent of KEdit. 
Also the Komposer framework will surely require a KMail class for 
Komposer composers to talk back to KMail and get a message sent once 
it has been written. JES' work should be part of this KMail class.

My work has been to use KFontAction, KFontSizeAction and the qtextedit 
interface (which underlies the KEdit interface) to add WYSIWG HTML 
editing support. (Fonts, sizes, emphasis, lists, justification, no 
tables, inline images, colors yet). This work can be reused in a 
Komposer composer implementation based on KRichTextEdit (I think 
that's the right one).

The main problem with this approach seems to be that there are 
problems getting the spell checking to work with it, it might be 
necessary to disable spell checking for HTML mail. But I guess any 
KRichTextEdit Komposer composer is going to have the same spelling 
problem, and if we solve this problem for 3.2 then that solution can 
be reused by any KRichTextEdit Komposer composer.

Don.
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]