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

List:       koffice-devel
Subject:    Re: track change (was : Re: TextTool commands)
From:       Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date:       2007-04-12 16:35:42
Message-ID: 200704121835.43147.pierre.stirnweiss () t-online ! de
[Download RAW message or body]

On Wednesday 11 April 2007 22:43:32 Thomas Zander wrote:
> On Wednesday 11 April 2007 21:16, Pierre Stirnweiss wrote:
> > On Monday 09 April 2007 21:46:04 Thomas Zander wrote:
>
> 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.
>
I was not saying my initial suggestion was elegant, I thought it was a 
acceptable workaround. It seems the elegant solution can only come from Qt 
text engine (more information with the signals). 


> 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 was just a thought. My reasoning was as follow. A QtextDocument->undo() 
will change the doc's content and make it dirty. A call to a redraw would 
therefore be made. Same for the subsequent redo.
I was obviously wrong :)


> 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?
Yes this is the reason I asked you.

> 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.
Yes, I don't want to mess up the source either. This is why I was thinking of 
doing a alternative text shape in the shapes directory (this would be easy to 
delete later). 
I didn't want to suggest a branch because I thought it would be a waste of 
repository space to duplicate entirely Koffice just for an additional 
directory with 10ish files and that keeping the two in sync would be 
difficult. I am not really familiar with the workings of subversion so excuse 
me if I am saying enormities there.

How would a branch work? Can I checkout from trunk and commit to some place 
else?

>
> Have a good evening!


_______________________________________________
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]