Richard Bown wrote: > On Thursday 10 July 2003 3:36 pm, Chris Cannam wrote: > >>Calling repaint() doesn't necessarily force the rulers to repaint -- >>they can just look up their refresh status (for composition or >>segment changes) and repaint only where necessary. > > Um, hang on. I was just talking about QWidget::repaint() (or sim) that > will definitely repaint a widget.
Yeah, sorry -- but it'll batch repaints until the next event loop (i.e. it doesn't repaint immediately) and also we have control over the paintEvent so we can cache information in there and choose to repaint from cache (or via parent widget's paintEvent only) if nothing has changed. > moment I know that if I modify Segments/Events as part of a command then > views will get updated but I can't see where the magic is happening. > Obviously through MultiViewCommandHistory somewhere but where? Well, only sorta. The history's commandExecuted signal connects to the view's update() slot (basically a more forceful repaint(), i.e. it ultimately ends up at paintEvent). This is in editviewbase. And that checks the refresh status of the segment/composition to decide whether to do a proper refresh (from the subclass view) or just to call the parent class's paintEvent (repaint what's already there). The refresh status itself is set entirely within segment or composition, by the methods that change things in the segment or composition itself -- not by the command history. Chris ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps _______________________________________________ Rosegarden-devel mailing list [EMAIL PROTECTED] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
