KRichTextEdit for kdelibs

[Thomas McGuire]

Hi,

Am Samstag 19 April 2008 11:54:28 schrieb Stephen Kelly:
> I've been working on a RichTextEdit component for kde. My original idea was
> that it could be reused and extended by applications like kmail, kjots and
> kopete, or any application that uses rich text. I thought that given a
> KPart, an app developer would get the rich text toolbar actions (such as
> bold, italic etc) for free, and just add application specific actions to a
> derived KPart.
>
> After talking with dfaure on irc it seems that's not what KParts are for,
> but I might be able to achieve that with KXMLGUIClient. I'll be looking
> into that if it's possible. I'd like to hear your thoughts on it.

Thanks for working on this.
I have no idea how KXMLGUIClient works, but it would certainly be great if the 
rich text actions could be provided by kdelibs instead of creating the actions 
in each apps. How does it work? Would it still be possible for KMail to 
subclass that (which we need to do)? How does the inheritance structure look 
like, KRichTextEdit : public KXMLGuiClient, public KTextEdit? It would be nice 
if the API docs would then include a small usage example (because this stuff 
is probably not as easy to use as a KTextEdit).
The actions would then be plugged in by adding them to the XML rc file, like 
it is done now, right?
A part would indeed be no solution for KMail, because of the need to subclass.

> My progress so far is in playground now:
>
>  http://websvn.kde.org/trunk/playground/libs/krichtext/
>
> It contains
>
> * 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.
Some small observations:

- You should remove enum Placement there, it is not used.
- I think all the @since 4.1 can be removed here, and one @since added to the 
  class definition instead.
- The focusChanged() signal can probably be removed, KMail doesn't use it 
  anymore, and I guess no other app will use it.
- It looks like currentLinkText() will also select the link text, which is   
  unexpected and will cause problems for KMail, which displays the current 
  link text in the status bar. For this reason, selectLinkText() in KMeditor 
  takes a QTextCursor* instead of directly setting the text cursor.
- What is the reason that KRichTextEditPrivate has a method setTextCursor(), 
  which just calls the same method of the q class?
- It looks like slotInsertHorizontalRule() could use 
  beginEditBlock/endEditBlock so undo is only one operation.
- Changing the list style is inconsistent: When changing from bullet to 
  circle, the whole list changes, but when changing from bullet to none, only 
  the current item changes. Yeah, I know it is inconsistent in KMeditor as 
  well.
- The parameters for updateLink() should be const QString &.
- Last and least, the coding style is inconsistent (that is the fault of 
  KDEPIM, where some of the code comes from, of course).

If the XMLGUIClient things don't work out for some reason, stuff like 
manageLink() should be moved to KRichTextEdit instead (it doesn't use anything 
else).

Anyway, excellent work, I'm looking forward to this being in kdelibs.

> * a KRichTextPart, which started out as KRichTextEditPart in
> kopete/chatwindow, but I don't know if any of the original remains. I
> didn't put the licence headers from the kopete file into this one, but I
> can put them there if neccessary.
>
> * KRichTextEditor, which is a simple demo application containing the
> KRichTextPart.
>
> There are several open issues with this stuff, but I'd like to know whether
> something like this can get into kdelibs before I spend time listing them.
> Once I know how to change the KRichTextPart into a KRichTextGuiClient I can
> start porting kjots and maybe kmeditor if tmcguire is willing and kopete.
Sure. I would like to help out with the porting of KMeditor. I would prefer to 
do that when the classes are in kdelibs, so we don't have to create separate 
work branches. Then, I could also help with some smaller issues with the rich 
text classes in kdelibs.

Regards,
Thomas



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080419/48481ab5/attachment.sig>