KRichTextEdit for kdelibs

[Stephen Kelly]

Thomas McGuire wrote:
> 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)?

I've assumed it's possible. All applications except the demo application
would have to subclass it I reckon. Whether it's possible is kind of what
I'm asking. KXMLGUIClient is already used in kontact. It's the base class
of Kontact::Plugin, and seems to be to the lifting when merging application
guis into kontact. The way it seems to work in Kontact though is that you
need a kpart for your app, then a Kontact::Plugin wrapper as well. I'll be
doing some experimentation with this to find out if both are needed in this
case too.

> How does the inheritance 
> structure look like, KRichTextEdit : public KXMLGuiClient, public
> KTextEdit? 

The way I see it working would be this:

http://img518.imageshack.us/img518/9853/krichtextumllp9.png

Is it reasonably clear? So an application would subclass KRichTextEdit if
neccessary and use it in a subclass of KRichTextGuiClient which contains
whatever additional actions it has to perform on the KRichTextEdit (along
with an additional .rc file not shown). Then add the appTextEditGuiClient
into the application. Any thoughts on that?

> 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).

Sure, I'll put examples in the docs. 

> The actions would then be plugged in by adding them to the XML 
> rc file, like it is done now, right?

Yep. That's the idea.

<snip>
> - 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).

Thanks for looking into that. I've fixed some of them locally now. There's
more coding issues with it, but I wanted to focus on design issues before
getting stuck into them.

The list style behaviour was deliberate to avoid mixing of styles like this:

 * Foo
 * Bar
   A. Bar-Foo
   1. Bar-Bar
   C. Bar-Bat
 * Bat

So I made it so that sibling items in a list neccessarily have the same list
style (that's what the NestedListHelper is for). If the cursor is on
Bar-Bar above, and the user selects none, would you have all of the items
in the Bar sublist change to none? I wouldn't expect that. Perhaps there
just needs to be some separation of the style and none actions in the UI if
it really is inconsistent.

I had an idea too that I could use some kind of AbstractListHelper, so that
applications could reimplement it with different definitions of the
functions like reformat list, onListIndentMore etc. I think that's a
discussion for a bit later down the line though. I'd like to focus on
getting a basic working reusable part/guiclient/widget first as a starting
point.

> 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).

manageLink() is going to call a different dialog in kjots than it does in
kmail. It'll use a combobox/completion system/not-sure-yet to also allow
linking to existing books and pages easily. I thought it might need to be
kept separate for some reason, but I don't remember why now. 

http://img501.imageshack.us/img501/8320/kjotslinkdialogtv3.png

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

Thanks. Hopefully it can be done a reusable way. I'll be looking through lxr
for other apps already using KXMLGUIClient to do this.

> 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.

Sounds good.

Regards,

Steve.