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

List:       koffice-devel
Subject:    Re: KWord Doc Structure Area refreshing
From:       Gary Cramblitt <garycramblitt () comcast ! net>
Date:       2005-12-24 14:48:37
Message-ID: 200512240948.37619.garycramblitt () comcast ! net
[Download RAW message or body]

On Saturday 24 December 2005 03:13, Thomas Zander wrote:
> On Friday 23 December 2005 22:19, Gary Cramblitt wrote:
> > The simplest way to get the dsa to refresh was to emit a signal
> > whenever a command is added to the command history, hence I added
> > commandHistoryChanged signal to kocommandhistory.
>
> That kind of looks like a nice trick, I'm not sure that it makes sense
> design wise :)  (i.e. does not break in unpredictable ways in the future)
>
> I'd like to point out the signals from KWFrameViewManager[1] (which is a
> member of KWCanvas and also reachable in KWView[2]).
> In the frameViewManager there are more slots then there are signals; thats
> because the class is currently in flux; the KWFramesListener[3] can be
> inherited to get the rest of the signals.  Feel free to convert those
> callback methods to signals in the viewManager, if this concept is weird
> to you. (see the fireEvents method for that)

OK.  David also objected to the command history approach.  I've reverted it.

As it stands right now, with the command history approach reverted and 
emitting docStructChanged signal in KWDocument::paragraphModified, but not 
using KWViewManager, most things in the document structure area update, 
except:

  1.  If I delete text in the first 20 characters of a paragraph by selecting 
it and pressing Delete.  Or change paragraph text by pasting.  (The first 20 
characters of the paragraph are used as the "name" of the paragraph in the 
dsa.)

  2.  I restore paragraph text using Undo.

  3.  I change the style of a numbered list item.

  4.  I change the order of paragraphs using drag and drop.

There are probably some other cases as well.  All of these issues have to do 
with paragraphs, not frames or framesets, so I don't need to mess with  
KWFrameViewManager at all (as it stands right now).


If I were to use KWFrameViewManager, which approach should I use?  Do you 
plan/want to convert the rest of the events to signals, or should I use the 
listener approach?  I need to be informed of all the events (except possibly 
FrameSelectionChanged) and some are signals and some are sent via listeners, 
so I'd have to do both, which strikes me as ugly.

Also, for optimization purposes, I need to know which frame/framesets have 
changed.  This signal doesn't tell me that.

    /// emitted after a frameset that had at least one selected frame was 
renamed.
    void sigFrameSetRenamed();

I need to know whenever a frameset has been renamed, period.  Is this signal 
what I want?

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