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

List:       koffice-devel
Subject:    Re: questions regarding QTextDocument behaviour
From:       Thomas Zander <zander () kde ! org>
Date:       2008-12-05 11:21:12
Message-ID: 200812051221.12624.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 30. November 2008 09:01:31 Pierre Stirnweiss wrote:
> Ok, here is the deal:
> - for the insert paragraph thingie. when keying some text, a "macro
> command" is opened. Then on pressing "enter", a call to
> KoTextSelectionHandler:nextParagraph is made. This in turn call for opening
> a macro (call ignored because one is already opened). Several stuff is made
> (new block created, style applied,..), each are commands that get parented
> correctly. But then, the nextParagraph method calls for stopMacro which end
> the "macro command". On returning to the TextTool, a further setBlockFormat
> is done for the text direction stuff. This one is not parented, hence two
> different undo commands for the single "carriage return" action.

Yes, thats expected and Ok. Since the user never sees those undo actions, just 
the macro one.

> - for the formatting ignored, the same mechanism is at work, on keying
> text, a macro command is opened, when formatting is called, the startMacro
> from the formatting action is ignored because one is already opened and all
> formatting actions are parented in the key press one.

Right, thats a bug indeed.

> This is what I propose:
> - keeping the idea of "macro command" which parents any subsequent "undo
> command" created after undoCommandAdded signal, I would like to avoid
> having "opened command" at the end of a user action. This is as far as I
> have seen so far only the case for text keying.
AFAIK even there there is no open command; we use m_processingKeyPress for 
that.

> I think we could use the 
> merging facility in that case. That would make things clearer. I will try
> an implementation, and commit if it compiles/work with correct behavior.

Hmm, I'd be interrested in an explenation your idea; I can't see how that 
would work..

> - then, I would like to group everything that is related to a user action
> in one place. For example, I don't see why a new paragraph action (this is
> just one example, I am pretty sure there are others) is half made in the
> TextSelectionHandler and in the TextTool. This is confusing and a hell to
> debug.

I can see why you find it confusing; but unfortunately its required. The 
clearest description is given in the API docs for KoTextSelectionHandler. It 
provides public API to manipulate selected text.
So we need that feature in the kotext module if scripts and others want to be 
able to insert a newline.
See also the docs for kotext;
http://www.koffice.org/developer/apidocs/libs-kotext/index.html

I'll write something about your previous patches and thoughts how to continue 
shortly.

-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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