Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global Edit Target #6144

Merged
merged 20 commits into from
Nov 19, 2024

Conversation

murraystevenson
Copy link
Contributor

This adds a new script-level Global Edit Target, which provides a centralised way of specifying the Edit Scope that should be the target for interactive edits via a new "Edit Target" menu in the menu bar. This menu displays the EditScopes upstream of the focus node. Editors default to following this choice by default, but can still be overridden to a specific edit scope where necessary. An overridden editor can resume following the Global Edit Target by choosing "Follow Global Edit Target" from its Edit Scope menu.

globalEditTargetScreenshot

The Edit Scope menu has also received an update, simplifying its UI by removing much of the additional chrome surrounding the menu. The intent here is twofold: make better use of the available space and remove some of the visual weight of the growing number of edit scope menus displayed across all the editors that now support them. To that end, we simplify the menu further when an editor is following the Global Edit Target, it shrinks to a condensed form that only displays an icon. This further reduces its visual importance, nudging users towards interacting with the global "Edit Target" menu instead, and distinguishes editors that have been overridden to target a specific edit scope as they display the wider menu button with the target name visible.

Lastly, we rename the existing "None" mode to "Source" (and give it an icon!). We feel "Source" more clearly conveys that this mode edits the first available upstream plug outside of an Edit Scope, rather than does nothing.

@murraystevenson murraystevenson self-assigned this Nov 13, 2024
Copy link
Member

@johnhaddon johnhaddon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Murray! This is feeling like a nice improvement. Would you like to canvas for any wider testing/opinion before we release it, or shall we just go for it?

python/GafferUI/EditScopeUI.py Show resolved Hide resolved
python/GafferSceneUI/SceneViewUI.py Outdated Show resolved Hide resolved
python/GafferUI/EditScopeUI.py Outdated Show resolved Hide resolved

if editScope is not None :
self.__menuButton.setImage(
self.__editScopeSwatch( editScope ) if not self.__unusableReason( editScope ) else "warningSmall.png"
)
else :
self.__menuButton.setImage( None )
self.__menuButton.setImage( "menuSource.png" )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to trim a pixel or two off this icon vertically. When switching from source to editscope, there is a slight jump in height of the button, which throws the label alignment off slightly and loses the margin above the button :

image
image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oddly, I don't see this on my Linux workstation but I can reproduce it on Windows. We were intending on increasing the swatch sizes to the same size as the current "menuSource" icon to give them more space to be occupied by status icons such as a 🔒, so I've brought those commits over here to see if they improve things for you? 83008e9, 1687d68

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely an improvement in that the height matches between "Source" and "Swatch" now. But now in both cases there is a single pixel margin at the top and a two pixel margin at the bottom (as in the first of my screenshots above). I don't know how much appetite you have for further fine tuning, but I think the lower screenshot with the 2 pixel margin above and below is more balanced visually.

python/GafferUI/EditScopeUI.py Outdated Show resolved Hide resolved
python/GafferUI/ScriptWindow.py Outdated Show resolved Hide resolved
python/GafferUI/EditScopeUI.py Show resolved Hide resolved
python/GafferSceneUI/SceneViewUI.py Show resolved Hide resolved
python/GafferUI/EditScopeUI.py Outdated Show resolved Hide resolved
python/GafferSceneUI/SceneEditor.py Outdated Show resolved Hide resolved
@murraystevenson
Copy link
Contributor Author

Thanks for the input! Feedback addressed inline.

Would you like to canvas for any wider testing/opinion before we release it, or shall we just go for it?

Now that my post-PR navel-gazing has subsided, I'm feeling pretty happy to just go for it.

@johnhaddon
Copy link
Member

Thanks for the input! Feedback addressed inline.

Thanks! I've resolved all discussions except one remaining nitpick about a single pixel in height. So I think we're close (or there, if we ignore the pixel).

I wonder if this new layout gives us the confidence to do #6018? It seems that it would be really unusual to have a per-editor selection, so maybe we can allow ourselves the screen real-estate needed for displaying the full path in the menu bar?

Remove the outer frame and always colour the menu button blue.
In so doing, we change the "Edit Scope" label to "Edit Target" to clarify that "Source" mode doesn't target an Edit Scope.
Add "Targets" divider, and "No EditScopes Available" menu item when no
edit scopes are available.
Such as the one newly added to the CompoundEditor.
We're about to add support for editors following the global edit target,
which results in the Edit Scope node not being directly connected to
the "editScope" plug on the Editor's Settings node. This centralises the
behaviour so each editor doesn't need to implement its own search, though
may be a little odd as not every SceneEditor has an "editScope" plug on its
Settings node...
The introduction of Editors following the global edit target will mean
that the EditScope node may be indirectly connected via the CompoundEditor's
Settings node, so we need to traverse to find it.
Add a balancing spacer to the right side of the toolbar, this is necessary now that the "editScope" plug's widget is narrower than the combined widgets on the left hand side.

Make the balancing spacers respond better to changes in width of the "editScope" plug's widget, as this may be varied by studios...
This makes the change in state more distinct when following the global edit
target, as well as reducing the prominence of the widget to guide users to
interact with the more visible global edit target.
This keeps the language consistent with the "Follow Global Edit Target"
menu item introduced on EditScopePlugValueWidget, and better fits with
the idea that this is a persistent behaviour rather than a one-time action
to reset to the default display and view for the current config.
This keeps the breadcrumbs aligned with the larger 14 pixel swatches created by `Image.createSwatch()`
This margin is necessary to balance the widget vertically when it is used
in the MenuBar.
@johnhaddon johnhaddon merged commit 49dfaa6 into GafferHQ:1.5_maintenance Nov 19, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants