opening a modal dialog for editing of nodes is exhausting and time consuming, and for me becoming way too much for my eyes and annoying for even small projects.
So I am wondering (just gauging a view from the community) before I dig anywhere at all how big of a change will it be to enable editing the properties of a node using the sidebar properties panel directly? What are your thoughts about this ?
I have a high level itchy thought of creating those 3 buttons ..
Personally, I am against putting more into the sidebars until they become more flexible. Ideally, I would like to be able to tear off and rejoin sidebars from the main editor window so that I could make better use of my multiple monitors for extra space.
In addition, for me, the biggest annoyance is not being able to open more than a single node at a time. This is massively restrictive. But as things stand right now, allowing >1 would cover most of the Editor so I don't think everyone would be happy about that either.
Having a unified "window" would be an immense boost to usability in my opinion. Windows could be docked to sidebars, Editor sides (even top/bottom maybe) and torn out to separate browser windows. No programming required in nodes. And for compatibility, the default would be to open as now. But perhaps there could be something that remembers where you last opened a window which would work per browser/nr-instance.
This has been discussed a few times. The main problem we have is the existing node edit lifecycle doesn't easily lend itself to this style of interaction - as desirable as it may be.
Every node gets to define a custom piece of code that is called when the edit dialog is opened, and another piece of code that is called when the edit dialog is closed. This allows the node to prepare its custom edit form contents, as well as then turning that form back into the node properties that should be saved. This gives the richness of the edit dialog, rather than them being restricted to simple text/checkbox type forms.
It also means those custom bits of code can be relatively expensive to run - they only need triggering when the dialog is being opened or closed.
Moving away from a modal edit dialog means we don't have quite the same lifecycle; there isn't the same 'save changes' trigger. The oneditsave function runs in the expectation that the form is being destroyed. This could have unexpected side-effects if the form was being kept open in the sidebar.
To summarise; there are a number of technical problems to changing the edit lifecycle of the nodes. There may be solutions to some of them, but that isn't for certain.
Yes totally get it. In fact, I think this what gives each node its powers and I think I used (and sometimes even misused ! those custom code, libs, etc. in building of custom nodes.
My humble opinion at this point is initially we do not have to worry about performance for those heavy custom nodes but I tend to think simplicity is sometimes the better approach, and for me the core nodes are very slim and snappy to run easily on a sidebar.
I think a small step towards an improvement for me could be first to simply load the full editor window itself into a sidebar, on a special Edit button/Right Click action or something similar for the node.. so my head is starting by a simple plugin that adds a sidebar (or even extending existing Info sidebar) and magically load the dialog as an 'ugly' iframe in that window for a beginning - are the hurdles too many to follow this possible solution ?
in other words changing where editor is hosted, not how it works.
would you agree this could be a path?
