(sorry for the delay, I get around to reply to this one only now)
On Friday 18 July 2003 11:10, Chris Cannam wrote:
> I notice the mmap code modifies EditViewBase so as to update the
> mmapped segment when something is found to have changed in the
> edit view. This looks surpassing iffy to me: 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. In the case of several editviews, only one of
them will trigger changes at a time, so the mmapped segment gets updated only
once.
> The problem: My code wants to know when something's changed in
> the composition or a segment (or the studio or elsewhere) so
> that it knows it has to do a refresh, but it doesn't necessarily
> want to refresh immediately anything changes (better to batch
> and do the refresh when the data is next needed, or when we're
> next idle).
But 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.
> There are two parts to this.
>
> 1. We have to make sure we get control somehow during the next
> event loop or whenever the refresh is to happen. For edit
> views, we do this by attaching the command history's
> commandExecuted signal to our QWidget update method, which
> causes Qt to batch an update request and call paintEvent on
> the widget from the next event loop.
>
> This part is less obvious for something that is not a widget,
> like the mmap management code. I'm sure it's possible to
> register that Qt should call us back during the next event
> loop even if we aren't a widget, though.
You solved this part by using QObject::event() and QApplication::postEvent(),
but again I think we should reflect changes synchronously here. In the
SequenceManager, the command history's 'commandExecuted' signal should
trigger an immediate remap if found needed.
> 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 ?
> 2. When we get control, we have to know what's changed so
> that we can refresh it. The two different ways to do this
> are:
I stand by the fact the "when we get control" == "right away" in the case of
the SequenceManager. However, this part of your discussion is also relevant
to edit views.
> a. Use RefreshStatuses. These exist on Composition and
> Segment at the moment. To use these, we request a
> refresh status ID from the Composition or Segment, and
> that gives us a personal refresh status for that object:
> we can reset it, and then query whether it's changed
> since you did so. This has its problems:
>
> * Although the Segment refresh status includes handy
> information about which region of the Segment has
> changed, the Composition status tells us nothing
> except that _something_ has changed. This is why the
> segment canvas has that complicated code that compares
> the Composition against its stored set of Segments to
> find out whether a Segment has been added or removed
> or what. It's much harder to come up with a good
> structure for explaining changes in the Composition
> than it is for the Segment.
I agree on principle, but as you said later maintaining a structure describing
composition changes is not trivial, and in fact will be akin to redoing the
commands themselves. We'd fall back on the previous scheme where we'd prod
commands for info on what happened.
> * If we want to get refresh status for lots of things --
> such as all the segments in a composition -- then we
> have to keep track of refresh status IDs for all of
> them separately.
Agreed again. It works for editviews where only a limited number of segments
(usually a single one) are displayed, but it gets tedious when watching a
whole composition.
> b. Use Observers. These have existed for a while on Segment
> and now (since the merge) exist on Composition as well.
> [....]
>
> * It imposes an overhead on modifications to the Segment
> or Composition, because our observer's callback has to
> be called every time something changes.
But this overhead is pretty light, especially compared to expensive operations
like a layout.
> What d'you think? I could just go ahead and do some of this,
> I guess.
I think the SequenceManager should be a composition observer, and refresh
mmapped segments synchronously as they are edited.
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. I'm not sure that user
QEvents are an option, because they can be directed to one QObject only. So
this leaves us with signal/slots, even though we already have dozens of
these. Perhaps simply formalizing them a little would be enough, go through
all the "slotRefreshDialog()"s and try to find a common pattern which we can
reuse.
--
Guillaume.
http://www.telegraph-road.org
-------------------------------------------------------
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
