DispatcherUI "fix" #1991
Merged
DispatcherUI "fix" #1991
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Dispatcher class itself doesn't support such an option, because the playback range is something only the UI knows about. We were then trying to emulate the PlaybackRange option by pushing the playback range into the frameRange plug, replacing any custom range the user might have entered. We did keep track of the old custom range so it could be restored when changing back, but we had a bug whereby the playback range could stomp over the user's custom range. Rather than fix the problem, this commit just removes the PlaybackRange option entirely. It was problematic to implement anyway, and the only reason it had even a chance of working was that the DispatcherWindow was always around in the background to monitor changes to the playback range and push them into the frameFrame plug. In future we intend to allow Dispatcher nodes to exist in the node graph directly, at which point there will be no guarantee of a persistent UI, and the feature would be impossible rather than merely problematic. I had intended to add a simple preset to the frameRange plug to copy in the current playback range as an alternative, but that is not possible because presets have access only to the plug, not a context. I've also removed the frame range preview feature because it was relying on access to the DispatcherWindow too. Both these should be reintroducable at the expense of further complexity, but personally I don't think it's worth it.
johnhaddon
force-pushed
the
dispatcherUISimple
branch
from
d8ed5f0
to
654e0dc
Compare
|
I probably won't have time today to build this to see what it looks like now. Can you put up a screenshot of the DispatcherWindow to show what the "no frame range preview" is like? |
|
Sure. So, in the CurrentFrame and FullRange modes, you just see the dropdown menu with its selection, no preview of what the current frame or the full range is :
In CustomRange mode, the field for entering the range is made visible.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a more radical approach to #1970, simply removing the problematic feature. I've provided the reasoning for this in the log for d8ed5f0. Can revisit the preview feature if you feel it's essential (I have a prototype) but my feeling was that with the simpler set of options we now present, it wasn't worth the complexity.