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

List:       koffice-devel
Subject:    Re: KWord frames refactor
From:       Gary Cramblitt <garycramblitt () comcast ! net>
Date:       2005-10-24 12:33:58
Message-ID: 200510240833.58600.garycramblitt () comcast ! net
[Download RAW message or body]

On Sunday 23 October 2005 03:30 pm, Thomas Zander wrote:

> The changes to the model (i.e. frame and framesets) will be emitted by
> signals connecting to the KWFrameViewManager from the doc and the
> framesets, and will then update the appropriate views after _all_ the
> signals have been handled.
> The idea here is that only after all the changes to the model have been
> done should the view update, eliminating most race conditions I have seen
> in the current code.  See the .h file for details.

Yes!  I was working on the document structure area code last night.  I have 
noted that KWord fails to emit the docStructureChanged signal in several 
places (for example, after modifying frame/frameset properties), resulting in 
a stale doc structure area and crashes if user tries to perform functions 
with the stale data.  But when I added those additional signal emits, 
KView::docStructChanged seemed to generate the race conditions you mention, 
so your refactoring will be welcome indeed.  There are repaint()s scattered 
all through the frame, frameset, doc, canvas, and view code, and all of these 
should be update()s.

Ultimately, the doc struct area should be just another view of the data model.

After working with KWord for a couple of weeks, I gotta say the painting is 
currently a mess.

Your changes will be disruptive for a while, but they are needed. Go for it.

-- 
Gary Cramblitt (aka PhantomsDad)
_______________________________________________
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]