KRichTextEdit for kdelibs

[Thomas McGuire]

Hi,

On Sunday 20 April 2008 13:10:39 Stephen Kelly wrote:
> Thomas McGuire wrote:
>
> > 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?
Hm, then I need to subclass two classes instead of one. However, it has a 
nicer separation between actions (the guiclient) and the textedit itself. Do 
whatever you prefer and see how it goes. This looks like a good idea which 
could work.
BTW, I think the part is not necessary, after all KXmlGuiWindow doesn't use 
parts either.

> > - 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 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.
Yep, I agree, the guiclient/widget stuff is the most important.
The list style thing is very minor anyway, I'll be happy with anything 
KRichTextEdit provides, I don't plan to change the behavior, so I wouldn't use 
the AbstractListHelper.

> > 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
Ah, I see. Looks nice.

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/20080420/f1f91329/attachment.sig>