Its the original screenshot from BETA5 im still running with @next
Just to add my two-penny worth, mine looks the same as Marcus's
I found a bug not sure if it was reported already. When a node with many output ports is first rendered its icon stays at the top. Then when I click on it, the icon is centered.
Before clicking
After clicking
Inspector image for both icons
A no go for placing the scrollbars on top of the buttons at the bottom
I can't move the node out of there after dragging it all the way down past the scrollbars
All these nodes are stuck
During drag or drop events, locking the max y/x to be inside the boundaries of the scrollbar could be a solution
Besides that, the scrollbar on top of the buttons is really weird. I would move the action buttons that are currently on the bottom right, to top left and top right on the canvas, and make them opaque when not hovered. Dividing the buttons into right and left will help us finding them faster since we now have to search them into 2 groups (like in binary search). You can also add collpase/folding (folds into a tooling button) buttons when the top left and top right button sections become too wide.
Thanks for reporting. I've raised UX: pointer-event deadzone in the tab bar · Issue #5674 · node-red/node-red · GitHub to resolve it. We had a similar issue in an earlier beta that was fixed, but the last rework of the sidebar button bar regressed it.
1 Like
When hiding both sidebars we can see the canvas does not start drawing from the outtermost border of the viewport on the left
the right side
That is an intentional design detail. There is a panel outside the workspace on the left, but the right panel is overlayed.
I haven't been able to reproduce this. Testing with the exec node (which has multiple outputs) and an svg icon.
Do you see this behaviour with that node as well? If not, can you share specific of the node and the icon you have set for it? Maybe some new edge case.
- The scrollbars in left and right sidebars seem to follow whatever style the browser is using.
In the editor workspace though the appearance seems to be proprietary, being narrower with differently shaped ends and worse, lower contrast.
Since you have chosen not to show the scrollbar track (which the button can slide in, is that the right name?) it seems particularly confusing that the button itself has a different style.
It's not immediately obvious that these are scrollbar buttons rather than just a spurious vertical or horizontal smudge, as I think others have reported.
I'm sure it's a complex issue since there are OS and sometimes browser level overrides which might be applied or ignored.
Here is Firefox on Mint, with the width specified in OS theme settings.
And this is Brave, which does not seem to follow the OS theme settings
- We are used to browser scrollbar buttons changing size according to what proportion of the page/document is visible on screen. In Node-red sidebars the buttons do this.
Is it possible for the workspace scrollbar to reflect the proportion of the populated workspace is on screen, so something like viewport height / max(yvalue) - min(yvalue) for this flow tab?
The main workspace scrollbars are indeed custom as we need them to appear where they wouldn't naturally do so with the native bars. The styling can be iterated on; but as you say, there are a number of overlapping factors.
In terms of making the scrollbar sizes 'smarter' - that is something I'd like to look at, but unlikely for the final 5.0 release. It would be fairly simply to resize it to be proportional to the populated content - but then you have to deal with how the user gets to scroll beyond those limits. I spent some time playing with other apps that have that sort of behaviour; some non-trivial logic involved to ensure its intuitive. Something for another day.
Is your choice of the shade of grey a compromise for dark/light themes, or can you (or we) tweek it for higher contrast?
Edit - To answer my own question, yes we can tweek it with an editor.css file
.red-ui-workspace-scrollbar-handle {
background-color: darkslategrey;
}
#red-ui-workspace-scroll-v .red-ui-workspace-scrollbar-handle {
width: 15px;
}
#red-ui-workspace-scroll-h .red-ui-workspace-scrollbar-handle {
height: 15px;
}
Edit 2 - Indeed we can simulate a "standard" scrollbar too, still needs work!
.red-ui-workspace-scrollbar-handle {
background-color: darkslategrey;
}
#red-ui-workspace-scroll-v {
background-color: white;
width: 19px;
border: 1px solid #999999;
}
#red-ui-workspace-scroll-h {
background-color: white;
height: 19px;
border: 1px solid #999999;
}
#red-ui-workspace-scroll-v .red-ui-workspace-scrollbar-handle {
width: 15px;
}
#red-ui-workspace-scroll-h .red-ui-workspace-scrollbar-handle {
height: 15px;
}
IMHO the occasional glimpse of a node underneath the right hand sidebar is not valuable enough to justify this scrollbar jiggery-pokery.
Better, for me, to have the workspace fill the width between sidebars as in v4. 
1 Like
The icon is a .png maybe it happens for png icons only
Here is the repo: GitHub - AllanOricil/node-red-vue-template: Write Node-RED nodes using Vue and Typescript · GitHub
pnpm install
pnpm dev => to launch node-red
Can you reproduce your issue in the standard NodeRED 5.0.0-beta.5?
It is running in the standard node-red beta 5
Can you post a simple flow with the issue then?
@cymplecy it's an issue with a node, not a flow. I'll see if I can reproduce with a png icon.
1 Like
@AllanOricil can confirm its the png icon - can recreate with a local custom node. Will get it fixed.
2 Likes
Can we have a SCSS variable for the accent-color?
And is this really necessary in the dark theme CSS? I thought using the --red-ui-scrollbar-handle-background variable would be enough.
@mbonani can I invite you to bring that over to the core-dev channel in slack where we can discuss more directly?
1 Like
