Repository navigation
feat[canvas]: Patch the orange-canvas to add an export and import menus as ewoks json workflow - #503
Conversation
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
2b3d227 to
a803fef
Compare
|
|
||
|
|
||
| def main(argv=None): | ||
| patch_canvas_menu() |
There was a problem hiding this comment.
Maibe there is a better solution but as the main function is managed by orangecanvas, not sure there is a better way
There was a problem hiding this comment.
For Orange, main calls Main().run(argv)
You could override Main in this case to tune the canvas main window.
However, it won't work with oasys
There was a problem hiding this comment.
i think i look at the code of oasys and OASYSMainWindow inhirits from orangecanvas.application.canvasmai.CanvasMainWindow.
https://github.com/oasys-kit/OASYS2/blob/main/oasys2/canvas/application/canvasmain.py
But yes maybe cleaner anyway to override main i will look at that
There was a problem hiding this comment.
Oh ok I misunderstand your comment. You said the method you propose will not work with Oasys right?
So I would say we have to keep the patch like now ?
There was a problem hiding this comment.
You said the method you propose will not work with Oasys right?
Yes, I fear so.
So I would say we have to keep the patch like now ?
Yes, I don't see another way.
There was a problem hiding this comment.
Rather than patch_canvas_menu, the function name could be clearer.
Like add_ewoks_import_export_actions
| if _patched: | ||
| return | ||
| _patched = True | ||
| original_init = CanvasMainWindow.__init__ |
There was a problem hiding this comment.
I have verified in the code and Oasys / Orange looks to both use orangecanvas.application.canvasmaiCanvasMainWindow so it should works
|
TODO add unit tests and changelog |
|
|
||
| def __init__(self, *args, **kwargs): | ||
| original_init(self, *args, **kwargs) | ||
| _add_actions(self) |
There was a problem hiding this comment.
Adding actions is a good idea. Perhaps there are other ways to do this without patching? Not sure.
There was a problem hiding this comment.
Yes. One question is: how much different is it from the already existing Save / Save As / Open function that already exists ?
At the end this is only the file format that changes right ?
There was a problem hiding this comment.
yes we save as a json ewoks workflow
equivalent to an ewoks convert .ows <-> .json
There was a problem hiding this comment.
Sorry, I wasn’t clear. My question is whether we should add new actions or, if possible, reuse the existing one and adapt the current code (QDialog, save/load functions).
There was a problem hiding this comment.
I can investigate first if this is possible (Without going to deep into monkey patching / changing orange canvas api)
But in my opinion. It looks normal for me to have an "export import" pattern. --> The native way to save load orange workflow is ows.
For me this is the same as word. You save / load as docx but you can export import as open office format
There was a problem hiding this comment.
I agree with you on the technical side. That said, I keep wondering: what is the user actually expecting here? Could it be confusing for them to have to choose between saving and exporting? And are we at risk of ending up with too many actions?
I’m not pushing for one option over the other, but I think we should at least ask ourselves these questions first. The technical side can come second.
There was a problem hiding this comment.
See #504
As expected, four things need patching: CanvasMainWindow._open_workflow_dialog, CanvasMainWindow.open_scheme_file, CanvasMainWindow.save_scheme_as and the QFileDialog for saving.
Also, the opening for OASYS needs to be patched separately since the implementation is slightly different.
What do you think @payno ?
There was a problem hiding this comment.
Hard to say. Modifying _open_workflow_dialog and QFileDialog is playing with fire.
But save_scheme_as could be fully rewrite or we could ask the orange team to do some modifications.
_open_workflow_dialog is used at three places where there is public API:
def open_scheme():
dlg = self._open_workflow_dialog()
dlg.setParent(dialog, Qt.Dialog)
dlg.fileSelected.connect(self.open_scheme_file)
dlg.accepted.connect(dialog.accept)
dlg.exec()
...
def open_scheme(self):
# type: () -> None
"""
Open a user selected workflow in a new window.
"""
dlg = self._open_workflow_dialog()
dlg.fileSelected.connect(self.open_scheme_file)
dlg.exec()
def open_and_freeze_scheme(self):
# type: () -> None
"""
Open a user selected workflow file in a new window and freeze
signal propagation.
"""
dlg = self._open_workflow_dialog()
dlg.fileSelected.connect(partial(self.open_scheme_file, freeze=True))
dlg.exec()So I agree this is more code to maintain. But at a first glance it could be 'clean' enough.
There was a problem hiding this comment.
Let's discuss this in the next workflow meeting to reach a collective agreement then.
In the mean time, I think we can merge this PR
013ed22 to
9860deb
Compare
| # Here i import to the canvas then re export it and verify the exported json. | ||
|
|
||
| with OrangeCanvasHandler() as handler: | ||
| monkeypatch.setattr( |
There was a problem hiding this comment.
Not a fan of monkeypatch but there seem to be no other way
There was a problem hiding this comment.
yep me too but that's the better way to bypass the dialog
|
|
||
|
|
||
| def main(argv=None): | ||
| patch_canvas_menu() |
There was a problem hiding this comment.
Rather than patch_canvas_menu, the function name could be clearer.
Like add_ewoks_import_export_actions
| if _patched: | ||
| return | ||
| _patched = True | ||
| original_init = CanvasMainWindow.__init__ |
| import_action = QAction( | ||
| "Import Ewoks workflow...", window, objectName="action-import-ewoks" | ||
| ) | ||
| import_action.triggered.connect(lambda: _import_ewoks(window)) |
There was a problem hiding this comment.
Not sure if this raises issues from the Qt lifecycle.
@t20100 ?
There was a problem hiding this comment.
It's likely to keep some reference to keep access to window and thus may create a reference cycle.
Basically except for module-level functions and methods, connecting anything else (lambda, closure function, partials) may create a reference cycle that may delay destruction some widgets.
There was a problem hiding this comment.
yes that's maybe bad as if user click on new window and close the first one, so the RAM will not be freed right now.
For software like darfix this is an issue
So I need to change this but the problem is as this is patching I cannot use class method... I have to think about this...
There was a problem hiding this comment.
@maxenceprog Don't think too hard until we made a decision on whether we make new actions or patch the existing ones 😉
…us as ewoks json workflow
loichuder
left a comment
There was a problem hiding this comment.
As mentioned, let's merge this as a temporary solution
Co-authored-by: Loïc Huder <42204205+loichuder@users.noreply.github.com>

closes #79
PR summary
Done with Claude... I made the review and looks ok but maybe i miss something. It patches
orangecanvas.application.canvasmaiCanvasMainWindow.__init__. This is maybe a beit creepy but not sure there is a more conventional solution as the main canvas init is done in main managed by oasys or orange.This add two menus
Export Ewoks workflow...andImport Ewoks workflow.... This usesows_to_ewoksapi to convert ows file as a json workflow for Export and the reverse principle for Import.Screencast.from.2026-10-14.17-25-40.mp4
AI Disclosure