Hello there -- sorry I haven't commented on this yet, having been the guilty party in writing the observer classes in the first place.
That's partly the usual lack of time, partly that I'm not completely confident in the current shape of the code any more, and partly because I really like the fact that new people are actually working on it and I don't want to disrupt the flow by suggesting alternative ways of doing things that might turn out not to be so natural to anyone else. But there do seem to be some questions I can answer here. On 11 October 2011 05:07, Tom Breton (Tehom) <[email protected]> wrote: > My notes just say "SegmentObserver seems to do something different though > related." SegmentObserver's interface didn't seem to handle updating > Event properties like velocity SegmentObserver and CompositionObserver were intended to handle changes to the fabric of the segment and composition -- that is, things like (respectively) adding/removing events in a segment or changing the segment start/end times; or adding/removing segments in the composition. They implement a "standard" Observer pattern, which happens to be quite similar to the way QObject signals work, and the whole reason for their existence is the fact that Qt classes were not originally used in the base library. > Is SegmentObserver intended to handle property changes such as velocity > changes? And cause appropriate redraws? I see only eventAdded and > eventRemoved, so does that mean that SegmentObserver wants all property > changes to take the form of added/removed events? No. These observers were (are) _not_ the main mechanism used for getting change notifications through to the edit views. That mechanism is the RefreshStatus (see Composition::getRefreshStatus, Segment::getRefreshStatus etc) [originally implemented by Guillaume]. Unlike the Observer and Qt signal/slots, RefreshStatus is asynchronous -- instead of notifying you immediately when something changes, the composition/segment just keep a record of what has changed, and wait for you to ask. When you do ask, you do so by providing a status ID which is particular to your bit of code (NotationScene object or whatever), so that the composition/segment can notify you only of changes that have happened since the last time you made a request using the same ID. So, when a command that modifies some events is executed, it updates all of the segment's refresh statuses (see BasicCommand::execute() in document/BasicCommand.cpp). The commandExecuted signal is then fired and in response to that, e.g. NotationScene::checkUpdate retrieves the refresh status from the composition and segment and determines what to update. The advantage of this method, initially, was that being asynchronous it could batch up any changes that happened in a single editing sequence and then update only the relevant parts when next returning to the event loop. However, in the change from KDE3 to Qt4 versions the redraw code was largely rewritten so that these updates happened synchronously anyway (e.g. NotationScene::checkUpdate is called synchronously from commandExecuted instead of waiting for an event loop), though I think the main segment canvas still updates asynchronously. Anyway I think that advantage, if it ever really existed, is mostly lost. However, commandExecuted + a refresh status ID is definitely still the "normal" way to get notification in RG when a change to one or more events has happened, and I'd suggest continuing to use that for new code -- unless anyone is eager enough to rewrite the whole thing to use signals throughout (which would mean a lot of testing of course and is probably unwise at this point). Chris ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
