this is an experimental zoom affect in combination with mouse scroll :
This utilities the Opt/Alt-Scroll feature to zoom in/out out and what is happening is that when I zoom out far enough, the workspace tab is changed automatically. Or when I zoom in, the workspace is also changed. Either going left or right up the workspace tab bar.
So the idea is to have endless canvases, to have endless zoom. Imagine zooming in on a subflow-node and then automatically switching to the subflow definition when the zoom is close enough.
The other idea behind this scrolling is that workspace/flow layers can be represented, i.e., imagine having data not only flowing from left to right but also from below to up or top to down. It is this latter data flow that could be represented by this zoom effect.
The code for this is this change in the RED.workspace function space:
function zoomIn() {
if (scaleFactor < 2.5) {
zoomView(scaleFactor+0.05);
} else {
let idx = RED.nodes.getWorkspaceOrder().indexOf(RED.workspaces.active()) + 1;
if ( idx < RED.nodes.getWorkspaceOrder().length ) {
RED.workspaces.show(RED.nodes.getWorkspaceOrder()[idx],false,false,true);
zoomView(0.1);
}
}
}
function zoomOut() {
if (scaleFactor >= 0.1) {
zoomView(scaleFactor-0.05);
} else {
let idx = RED.nodes.getWorkspaceOrder().indexOf(RED.workspaces.active()) - 1;
if ( idx > -1 ) {
RED.workspaces.show(RED.nodes.getWorkspaceOrder()[idx],false,false,true);
zoomView(2.5);
}
}
}
It would be if the zoom in would be centred on the mouse cursor Noticed that zooming in does not use the mouse cursor as point to zoom in to, I think that was one of the features of the presentation tool (having used it briefly and then leaving in a could of confusion!)
This is interesting. In my opinion, the Node-RED editor could do with the following two upgrades:
Opt/Alt-Scroll feature currently zooms in using the centre of the canvas as the zoom point. This is incredibly annoying. When you zoom out very far, then zoom back in, it always takes you to the centre of the canvas (which in most cases is empty) then you have to use the sideways scroll bars to see your nodes again. Is there a way to change this behaviour, so the zoom point uses the current mouse position? I really think that should be the default behaviour.
If anyone has ever used CAD software (for example Sketchup / PCB design programs like Eagle / Fusion etc.) then this will be familiar.
Yes the "infinite scroll" idea is excellent. I didn't know until experimenting just now that you can Ctrl-Double-Click on a subflow and it opens it. That's a time saver, but I find it takes a tiny bit too much cognitive energy for me to recall Ctrl or Alt or Shift click shortcuts. So infinite zoom is a better idea for me. As long as it's intuitive - and as long as you can customise it in some small way* - then I really think it could be included in a core Node-RED update
*e.g.
a) Ability to enable / disable (disabled by default)
b) Ability to set threshold when zooming in (how far do you zoom in to subflow before it opens the subflow)
Exactly that. Zooming to points in and out, can be so much more helpful than a general zoom. But to be fair, it's only something that works using the mouse - with a keyboard Ctrl-+/- (or equivalent) isn't the same effect.
I suspect though it's a non-trivial change to use the mouse point as focus of the zoom but I'm no expert. It might turn out to be a simple fix - which would be great
I really want to have workspaces that you zoom to. A bit like my demo above but as nodes. So that a node would represent a workspace, so that when you zoom in on the node, the entire workspace becomes visible.
Something like those Mandelbrot chaos theory images where you have an infinite zoom and keep getting the same image e.g. --> https://mandelbrot.site/ --> now imagine that when zooming in on a Node-RED flow!
on my Mac I can use Zoom with the Cmd key held down to zoom at the mouse pointer. I guess it may be Ctrl on other platforms.... Of course it zooms the whole page not just the edit workspace.
Just to note, it's only by chance I've just read through this thread to find complaints/ideas about the current zoom interactions in the editor that would otherwise have gone missed. Just saying, if there's feedback you'd like to see something done about, put the feedback somewhere it'll be seen.
@knolleary all good, this is a share your project not a feature request, so no, I didn't intend for you to get involved. It's more of an idea to have a continuous scroll but it's not something that I seriously think could be useful.
Unfortunately doesn't like my Safari and in Firefox it stalls (loading webcontainer) even if I do turn off my uBlock ...
Can you tell me what the branch name @ github is for the 5beta3 version? Then I'd have a look and see whether I can backport the zoom changes to NR 4 - again just for informational purposes not for inclusion!
dev branch. The changes were substantial as they modified lots of micro-behaviours around zoom and navigation. Check the closed PR list for one from @dimitrieh
Ok so the new zoom functionality takes a focalPoint - I assume that is passed the mouse pointer at the appropriate times, i.e., cmd-scroll as opposed the +/- at the bottom of the workspace
@knolleary Please may I ask: are you happy for user suggestions / ideas to be posted on Github Issue 5291? I wasn't clear if that is a request for feedback.
Noticed that zooming in does not use the mouse cursor as point to zoom in to, I think that was one of the features of the presentation tool (having used it briefly and then leaving in a could of confusion!)
