[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-11-29 18:41:01
Message-ID: 200811291941.06263.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Pierre,

these are mostly Qt questions, not so much KOffice ones.  Any changes in 
behavior following from our discussions should happen in Qt.
Coincidence is that I am one of the people in Qt Software working on this; 
so I do have some more insights and I can apply patches on Qt if we end up 
with those.

On Saturday 29. November 2008 12:29:15 Pierre Stirnweiss wrote:
> I am in the test phase to understand the inner working of things. I have
> questions regarding some behaviour of the QTextDocument I have seen. The
> basic question is: are these behaviours wanted or unwanted.
>
> 1) according to documentation, all changes made to the QTextDocument
> between a QTextCursor::beginEditBlock and a QTextCursor::endEditBlock are
> considered as one editing action.
>
> - the signal undoCommandAdded is sent for every edit actions inside the
> begin/endEditBlock. Shouldn't there be just one undoCommandAdded when the
> endEditBlock() is called?

Without looking at the code you have a good point. I expect one signal to be 
emitted when 1 undo action has been added.
If this is not the case i think its a bug that has to be fixed in Qt.
I'm kind of offline (visiting parents), so I can't check right now.

> - subsequent key strokes are merged. this is normal behaviour. however,
>   ( beginEditBlock(), keystrokes..., endEditBlock() ) is merged with a
> subsequent   ( beginEditBlock(), keystrokes..., endEditBlock() ). I think
> the QTextDocument should NOT merge these two EditBlock since they were
> explicitly grouped into two different blocks

I can see your point; there might be a little problem that this same 
behavior is used quite often in an implicit way.
If you type text each keystroke essentially is a 
beginEditBlock()+endEditBlock().
I don't know how you can differentiate between two different ways of doing 
this.

> 2) following behaviour of typing text:
[]
> Shouldn't there be consistency between the cases?

Reading your examples I'm ashamed to admit I don't see the inconsistency; 
all text-only changes without other changes in between are merged...

What behavior did you have in mind?

> Thanks for your insight,

Thanks for your feedback!
-- 
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]