On Saturday 26 July 2003 12:52, Guillaume Laurent wrote: > On Friday 18 July 2003 11:10, Chris Cannam wrote: > > what if something > > changes while there are many edit views visible, or none? does > > the mmapped segment get updated many times, or never? > > Well, I don't see how can something change without any visible edit > view, and therefore no user interaction.
The main window is not an edit view. You can make dozens if not hundreds of different kinds of edits without having an edit view. > In the case of several > editviews, only one of them will trigger changes at a time, so the > mmapped segment gets updated only once. I don't get this part. They all have (sorry, had) separate refresh-status IDs, and they all got paintEvent calls following a commandExecuted. None of them ever had any way of knowing that some other edit view had already refreshed the segment. > in some cases, like the mmapped segments, it does want to update > immediately, because the sequencer could be playing and you want to > reflect changes synchronously, not whenever you're idle. Well, this is the question. I maintain that you don't want "immediate" in the sense of "every time an observer calls back", because you at least want to batch up the various edits that make up a single command. For example, if you quantize a segment, you certainly don't want the segment to be refreshed separately after every individual event is quantized (which is what a SegmentObserver would do). For CompositionObservers the case is less clear-cut, of course, but I think the principle (that in general you want to batch changes and the Observer can't help you do that) is fairly clear. Also, we're not really talking about "when you're idle", we're talking about "when you next return to the event loop". This is likely to be almost immediately after the command has executed -- it may be before the GUI is updated (depending on the order the events end up on the queue), or it may be immediately after, or it may be the first time the progress indicator is updated during the GUI update. I think that's synchronous enough, given that the only case in which it makes a difference is when the sequencer is _just about_ to play the thing you're changing, but others may disagree. > > Also, invoking > > this from commandExecuted means that we miss out on things > > that change without using commands (including some very > > obvious things like changing the transpose level on a > > segment). > > I though all changes were done using commands ? Especially a > transpose level change, how do you undo that otherwise ? Changing the transpose level (in the combo box on the segment parameter box) is non-undoable. Why? I can't remember. I think you tried to implement it, ran into some problem or other, and Bownie got in a strop and declared that we shouldn't bother. There is certainly a case for saying that things like this and the instrument parameter box changes (also not commands) should not be true undoable commands on the command history, from a simple usability point of view. > On the other hand, refresh statuses are fine for editviews, but > lacking for other things like instrument properties dialogs and > stuff, since the only thing they describe is the time span of the > change. Segment refresh statuses only describe the time span of the change. A putative Instrument Refresh Status would be more use: it wouldn't necessarily have to record _any_ information, much like the Composition one -- knowing that an instrument has changed should be enough. Probably better to work out which studio objects the sequencer actually needs to know about changes to first, of course, or at least which ones it needs a new mechanism for (e.g. the DCOP mechanism for Devices works OK already -- I have been thinking of making it use shared-memory to do the bulk device dump, but that's a quite different matter, the basic protocol would stay the same). Chris ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Rosegarden-devel mailing list [EMAIL PROTECTED] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
