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

List:       koffice-devel
Subject:    Re: track change (was : Re: TextTool commands)
From:       Thomas Zander <zander () kde ! org>
Date:       2007-04-11 20:43:32
Message-ID: 200704112243.33279.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 11 April 2007 21:16, Pierre Stirnweiss wrote:
> On Monday 09 April 2007 21:46:04 Thomas Zander wrote:
> > On Monday 09 April 2007 20:32, Pierre Stirnweiss wrote:
> > > As I said, this signal is, to my mind, just not detailed enough:
> >
> > Well, I tried to explain that it isn't. And I'm quite unsure why you
> > say it is.
>
> To my point of view there is a difference between having:
> - these are the changes (explicitely) and
> - changes happened there, figure out what they were.
>
> The first one is to me more robust and more elegant.

More robust, true.
more elegant? Well, thats only true if you don't need to implement loads 
of actions and duplicate (and keep uptodate) functionality from Qt.
Then the elegant very quickly evaporates.
So, I'm sure you see problems with the approach I described here, and I'm 
certainly open to other suggestions.  But the suggestion you made earlier 
just does not scale and is far from what I call elegant.

> > So, to avoid any more timeloss I just coded a working example that
> > shows the before and after state of the text on each user action
> > using debug output
>
> For me doing a undo/redo cycle to find out what was changed is a
> workaround. It might be better that the one I was considering but it is
> by no mean exempt of drawbacks:
> - an undo/redo cycle seem to trigger two repaint which might be
> noticeable by the user if there is some heavy inline object.

I"m not sure how you determined there are multiple repaints. It would 
surprise me as the design I made for relayout allows this kind of thing 
to happen.  I don't see multiple repaints here.

> - this cycle triggers the usual signals (contentsChange,
> undo/redo,...). We have therefore to inform all the listeners that they
> should ignore these signals (done with the
> "m_tool->m_allowAddUndoCommand = false", and the disconnect).

Not 'listeners' but one listener. The definition of a text tool is that it 
is code that handles input.  And there is only one tool active at any 
time. Again, definition.

In short; I'd hate to design for a usecase that I find unlikely to happen. 
And surely to be unwanted currently.

> > .  Works great! :)
>
> Actually it works great as long as you don't hit undo. 

Good catch!
Not a hard problem to work around. I can take a look if you want.


Look, I understand you want an elegant solution that works great.  We all 
do. You made some proposals based on commands that I have severe doubts 
about. For a lot of reasons.  I don't think its worth researching it 
further, but you are always free to do as you want. Show me code that 
works is a great way to proof me wrong ;)
In absence of a truly great solution I think the one I coded has more 
potential and, well, there actually is code that works in most cases 
already.


> So since I don't want to waste anymore of your time and don't want to
> jeopardize the existing text shape, is it OK for me to create a alttext
> shape which would be a place I could experiment. Its compilation would
> depend on a cmake variable, disabled by default?

I'm not sure why you ask me. Its open source and you can do whatever you 
want with the code.  (well almost ;)
Or are you in possesion of an svn account and want to work in koffice SVN?
Hmm, better either use a branch or one of the distributed source control 
systems that don't require you to put stuff in KDE svn.

Have a good evening!
-- 
Thomas Zander

[Attachment #5 (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]