From: Tom B. (Tehom) <te...@pa...> - 2011-10-10 17:35:04
|
I just committed code that makes the Matrix editor update the velocity ruler. It's a pretty small change; most of the work was in ferreting out the exact parts that needed the change. One compromise I made that's less than ideal: updating PropertyControlItem now causes an extra update of MatrixElement. ISTM the proper alternative would have meant giving MatrixElement logic to only update when dirty, which means it would need to know when Event is dirty, which implies that both would need some sort of timestamp (or tickstamp). That would either be inconsistent with the way other views of events are drawn or would imply changing them too. That'd be a big change, certainly not something I should launch myself. So I didn't. Other details: * Segment now derives from QObject; Qt insists on it being the first base. * Segment now has a signal, contentsChanged. Contents-modifying commands cause it to emit that signal. That's done thru BasicCommand, so I suspect that includes all the relevant commands. * That signal connects to rulers visiting the segment via ControlRulerWidget. Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2011-10-10 18:00:10
|
On Monday, October 10, 2011, Tom Breton (Tehom) wrote: > tickstamp). That would either be inconsistent with the way other views of > events are drawn or would imply changing them too. That'd be a big > change, certainly not something I should launch myself. So I didn't. If the inefficiency isn't massively crippling, I'd rather live with the status quo than open that can of worms. Whenever we start trying to tinker around with update mechanisms, we always wind up chasing down bugs for years afterwards. > * Segment now derives from QObject; Qt insists on it being the first base. Part of me admires the obvious simplicity of that solution, while part of me is still rooted in a past when Qt wasn't allowed in base/. First we let in QString, and now Segment is a QObject. It's pretty shocking to this old timer, but I can't think of any good reason why we should still care about trying to keep Qt out of base/. Qt has been our common law wife for a long time now, so we might as well just get married and be done with it. I'm stomping down the stodgy, conservative part of me that is objecting to this, and we'll just move along and see where it goes from here. It looks like a workable solution to the problem, and a nice bit of work. -- D. Michael McIntyre |
From: Yves G. <yc....@wa...> - 2011-10-10 18:29:18
|
Le lundi 10 octobre 2011 à 19:59:58, D. Michael McIntyre a écrit : >First we let in QString, and now Segment is a QObject. It's pretty shocking >to this old timer, but I can't think of any good reason why we should still >care about trying to keep Qt out of base/. Qt has been our common law wife >for a long time now, so we might as well just get married and be done with >it. Anyway Qt was already in base/ since we have linked segments. Yves |
From: Tom B. (Tehom) <te...@pa...> - 2011-10-10 19:22:44
|
> On Monday, October 10, 2011, Tom Breton (Tehom) wrote: > >> tickstamp). That would either be inconsistent with the way other views >> of >> events are drawn or would imply changing them too. That'd be a big >> change, certainly not something I should launch myself. So I didn't. > > If the inefficiency isn't massively crippling, I'd rather live with the > status > quo than open that can of worms. Whenever we start trying to tinker > around > with update mechanisms, we always wind up chasing down bugs for years > afterwards. Right, it's far from crippling. I can't actually see any slowup. >> * Segment now derives from QObject; Qt insists on it being the first >> base. > > Part of me admires the obvious simplicity of that solution, while part of > me > is still rooted in a past when Qt wasn't allowed in base/. I actually sympathize with that concern. I looked at other ways to do it. I looked at MatrixWidget, but unlike NotationWidget, MatrixWidget doesn't seem to have a workable signal to forward to the rulers (I mentioned that even NotationWidget seems to be only succeeding by accident) Then I considered emitting the signal from commands. But that didn't prove reasonable. BasicCommand does know which segment is affected, but does not know anything about segment connections or ruler slots. And ISTM it shouldn't have to know that. That proved to me that the segment updating signal is about segments, so I bit the bullet and made Segment a QObject. > First we let in QString, and now Segment is a QObject. It's pretty > shocking > to this old timer, but I can't think of any good reason why we should > still > care about trying to keep Qt out of base/. Qt has been our common law > wife > for a long time now, so we might as well just get married and be done with > it. > > I'm stomping down the stodgy, conservative part of me that is objecting to > this, and we'll just move along and see where it goes from here. It looks > like a workable solution to the problem, and a nice bit of work. Thank you! Tom Breton (Tehom) |
From: cjnf <chr...@go...> - 2011-10-10 20:14:49
|
Hi Michael, Tom & RG devs, I've been keeping an eye on the list for problems with the code I wrote in '09. I do recall (very vaguely) some problems with getting the rulers to update to matrix changes but would be pretty confident that they did update to note adds/deletes/moves etc. > >> * Segment now derives from QObject; Qt insists on it being the first > >> base. > > > > Part of me admires the obvious simplicity of that solution, while part of > > me > > is still rooted in a past when Qt wasn't allowed in base/. > > I actually sympathize with that concern. I looked at other ways to do it. > I looked at MatrixWidget, but unlike NotationWidget, MatrixWidget doesn't > seem to have a workable signal to forward to the rulers (I mentioned that > even NotationWidget seems to be only succeeding by accident) Then I > considered emitting the signal from commands. But that didn't prove > reasonable. BasicCommand does know which segment is affected, but does > not know anything about segment connections or ruler slots. And ISTM it > shouldn't have to know that. > > That proved to me that the segment updating signal is about segments, so I > bit the bullet and made Segment a QObject. Wasn't there an "observer" mechanism of some sort to notify the rulers of segment changes? If I recall correctly, it confused the hell out of me when I first saw it but was pretty elegant. Something like the ruler would inherit an observer class and register itself with the segment on creation. The segment keeps a list of observers and calls their segmentchanged method when something changes ... or some such. Quite possible I'm misremembering! Regards Chris |
From: D. M. M. <mic...@ro...> - 2011-10-10 20:33:08
|
On Monday, October 10, 2011, cjnf wrote: > Wasn't there an "observer" mechanism of some sort to notify the rulers > of segment changes? If I recall correctly, it confused the hell out of > me when I first saw it but was pretty elegant. Something like the ruler > would inherit an observer class and register itself with the segment on > creation. The segment keeps a list of observers and calls their > segmentchanged method when something changes ... or some such. That sounds about right, actually. I've never done any work that involved using that mechanism, and so I've never understood it very well. It could well be that making Segment a QObject is reinventing the wheel, and this was supposed to be accomplished using the SegmentObserver mechanism. I find that I'm pretty ambivalent about how things get done as long as they work. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2011-10-11 04:07:26
|
> Hi Michael, Tom & RG devs, > I've been keeping an eye on the list for problems with the code I wrote > in '09. Thank you for commenting on this. > I do recall (very vaguely) some problems with getting the rulers > to update to matrix changes but would be pretty confident that they did > update to note adds/deletes/moves etc. To note adds etc, but not to velocity changes. > Wasn't there an "observer" mechanism of some sort to notify the rulers > of segment changes? If I recall correctly, it confused the hell out of > me when I first saw it but was pretty elegant. Something like the ruler > would inherit an observer class and register itself with the segment on > creation. The segment keeps a list of observers and calls their > segmentchanged method when something changes ... or some such. 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, and I know that Notation's redrawing was not coming thru it. I think I assumed at that point that SegmentObserver's was intended for another purpose. Perhaps I was wrong in assuming that. I looked at SegmentObserver again just now, and I may have been premature. Since you are more familiar with SegmentObserver than I am, may I ask you a few clarifying questions? 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? Tom Breton (Tehom) |
From: Chris C. <ca...@al...> - 2011-10-11 08:41:32
|
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) <te...@pa...> 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 |
From: Chris C. <ca...@al...> - 2011-10-11 08:43:08
|
On 11 October 2011 09:41, Chris Cannam <ca...@al...> wrote: > 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 (Actually, reading this over I have a suspicion that even adding/removing events was not in the original remit of SegmentObserver -- that the observer was originally intended to handle changes more at the segment scale and perhaps the add/remove events updates were added afterwards. I might be wrong about that though, my recollection is hazy.) Chris |
From: Tom B. (Tehom) <te...@pa...> - 2011-10-11 18:11:20
|
[much information snipped] Thanks, Chris. I think I understand SegmentObserver's intended use a little better now. Tom Breton (Tehom) |