-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[ui] NodeEditor: Addressed Tab Retention when switching Node selection #2624
Conversation
…ng node selection Updated the event trigger to be onVisibleChanged and the condition to check whether the current selected node is an incomputable node and the current tab index does not exist for it before resetting the index to 0
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2624 +/- ##
===========================================
+ Coverage 69.90% 69.93% +0.02%
===========================================
Files 121 121
Lines 7078 7088 +10
===========================================
+ Hits 4948 4957 +9
- Misses 2130 2131 +1 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR works as intended but there's an unexpected (and unwanted) side effect to it: when the selected tab is the "Statistics" one, moving from one node to another triggers a polish loop:
meshroom/ui/qml/GraphEditor/StatViewer.qml:305:9: QML ColumnLayout: Layout polish loop detected for QQuickColumnLayout(0x2055aed0, parent=0x2044f590, geometry=0,0 438x39). Aborting after two iterations.
(MESHROOM_OUTPUT_QML_WARNINGS
needs to be set to 1 for the warning to appear)
There are likely some minor changes to do on the "Statistics" component so it is loaded correctly when it appears as the first component.
I also think the tab index should be reset when we are changing the active project. Currently, it is only reset if we select a non-computable node or if we go back to the homepage, but it never is if we keep on loading projects from the application and selecting computable nodes. What do you think?
The sub column layouts in the parent column layouts were causing polish loop during show/resize ops
The 'isSaving' flag is a way to identify if the project is currently being saved and serves as a way to correctly distinguish whether the current filepath change is due to a save or a new scene or a load operation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The polish loop issue has been fixed and everything else is working as expected, but I think there are a couple of simplifications that can be done.
We're almost there! 😄
meshroom/core/graph.py
Outdated
|
||
@property | ||
def isSaving(self): | ||
""" Return True if the graph is currently being loaded. """ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
""" Return True if the graph is currently being loaded. """ | |
""" Return True if the graph is currently being saved. """ |
meshroom/ui/qml/Application.qml
Outdated
if (! _reconstruction.graph.isSaving) { | ||
currentProjectChanged(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't we do
if (! _reconstruction.graph.isSaving) { | |
currentProjectChanged(); | |
} | |
if (! _reconstruction.graph.isSaving) { | |
nodeEditor.refresh(); | |
} |
?
That would prevent us from having one more signal/slot for something that can be done in a single operation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
currentProjectChanged
could thus be completely removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention was to have a callback and then use that callback for this and other purposes in the future. I do agree with you since we don't have anything right now, let's use that itself and we can review this later when it will be needed.
meshroom/ui/qml/Application.qml
Outdated
@@ -20,6 +20,23 @@ Page { | |||
property alias unsavedDialog: unsavedDialog | |||
property alias workspaceView: workspaceView | |||
|
|||
property var scenefile: _reconstruction ? _reconstruction.graph.filepath : ""; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
property var scenefile: _reconstruction ? _reconstruction.graph.filepath : ""; | |
readonly property var scenefile: _reconstruction ? _reconstruction.graph.filepath : ""; |
Since there's no reason to ever edit this property from the QML side, we can probably set it as read-only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch !!, Thank you 🙂
477949b
to
a0745e1
Compare
…or to reset the current Tab index
a0745e1
to
3f47c54
Compare
Description
This PR addresses an issue with the Node Editor, where the selected tab was not getting retained when switching between selected nodes.
Features list
- Introduced thecurrentProjectChanged
signal which is meant to trigger update on various components when the scene is changed- Currently theonCurrentProjectChanged
slot is linked to refreshing the NodeEditor tabs.Implementation remarks
Updated the event trigger to be
onVisibleChanged
rather thanonIsComputableChanged
as the latter does not get triggered when there is no node selected and then an incomputable node gets selected but the value of isComputable remains the same.Visibility acts as a better trigger in my view, getting triggered when a node gets selected or deselected.
The condition is also updated to check if the current tab is not valid for the incomputable node before resetting it to 0.
This ensures that when documentation or such tab is selected, we don't end up resetting it back to 0 as it can exist in both the node types.
The available indices can be updated as we progress further with different types of nodes in the future.