"Scrollbar Speed"/"Canvas Size" Issue Never Resolved

Software
1

Since April 2019, and a post by user “hreba”, in the Schematic Editor, there has been no resolution to gigantic leaps away from the current viewport when sliding either of the scrollbars. All discussion of this problem is either distracted by 1) irrelevant factors (scrollwheels, touchpad, etc.), or 2) various coping strategies avoiding use of scrollbars (like zoom out & re-center).

There has also been a lack of understanding of terminology relating to elements of this problem:

  1. Canvas
    The total 2-dimensional space used for the creation of the schematic. Zooming out to the max shows the entire “canvas”.

  2. Viewport
    How close the user zooms in or out results in a smaller or larger scale of the schematic. The size or scale of the schematic seen on your computer display, and the amount of schematic elements visible is defined by the “viewport”.

  3. Scrollbar
    The horizontal and vertical user interface tools, typically located at the bottom and right of the viewport, consisting of a thin rectangular space, occupied by fixed arrow buttons at the ends, and a scrollpad between them.

  4. Scrollpad
    The Scrollpad is one of 3 elements in the scrollbar that can move the viewport. The other 2 are the arrows.

Issue Description:

Without using the scrollwheel or touchpad, when only using the mouse, using the scollbars (vertical or horizontal) result in moving the viewport so far and so quickly that the user has no idea of which part of the schematic he’s looking at, or where the current view is with respect to the previous view, before sliding the scrollbar.

This problem is the same when clicking “in the scrollbar” area, but off of the “scrollpad”. This should result in moving 1 page up or down, depending on whether the vertical or horizontal scrollbar is used.

The only other way to move the viewport is to click the arrows at the ends of the scrollbar, which takes forever.

Issue Example:

There are pins on 2 components the user wants to connect by drawing a wire. The first component is visible, but the second is just out of view to the right. Since KiCad lacks the sophisticated user interface of graphics software like Adobe Illustrator, there is no interface tool that changes the mouse cursor to a “hand”. So moving the viewport with the mouse is not possible. So, instead, the user clicks and very slightly drags the pad of the horizontal scrollbar to the right. Instantly the viewport is moved a drastic distance. Not just a fourth, third, or half of the width of the viewport, but multiples of the viewport width.

Addressing this sensitivity of the scrollbars may not require changes to the Preferences section of KiCad code. I believe this is simply an oversight of the User Interface design. The left/right and up/down “paging” factor was never programmatically calculated as a percentage of the “canvas” width or height. Writing code to do this 1) is not extremely difficult, 2) should have been done before releasing version 1.0, and 3) should require no changes other than the canvas dimension calculations for the scrollbars.

The scope and cost of effort to fix this is so small, I can’t imagine its priority not being for the next release.

1 Like
2

It’s hard to know what you are specifically talking about as you don’t give the version of KiCad you are referring to . . .

So my reference is V8.0.9 as thats what I currently have open in front of me . . . I don’t see any scroll bars . . . so I went looking and have turned them on.

Moving the scrollpad using the mouse gives me a smooth movement.

So I’m finding it hard to replicate your issue . . . I did try.

Application: KiCad Schematic Editor x64 on x64

---- Version Info ----

Version: 8.0.9, release build

Libraries:
	wxWidgets 3.2.6
	FreeType 2.13.3
	HarfBuzz 10.0.1
	FontConfig 2.15.0
	libcurl/8.10.1-DEV Schannel zlib/1.3.1

Platform: Windows 11 (build 22631), 64-bit edition, 64 bit, Little endian, wxMSW
OpenGL: Intel, Intel(R) UHD Graphics, 4.6.0 - Build 32.0.101.6647

Build Info:
	Date: Feb 19 2025 02:28:49
	wxWidgets: 3.2.6 (wchar_t,wx containers)
	Boost: 1.86.0
	OCC: 7.8.1
	Curl: 8.10.1-DEV
	ngspice: 44
	Compiler: Visual C++ 1942 without C++ ABI

Build settings:
3

You can pan the canvas by moving the mouse while holding down the mouse wheel (by default).

You can change it to right mouse button in settings.

4

Also: was this reported on GitLab?

5

This post is a bit longer then my attention span, but I am missing a reference link to that other post / thread.

And about:

If many people had this problem, or if it could be easily reproduced by a developer, then the bug would have been fixed quite quickly. I assume the cause is some specific hardware, maybe a gaming mouse with a very high resolution that does not get scaled properly somewhere between the hardware and KiCad. I.e. the issue may be entirely outside of KiCad, or between KiCad and some specific mouse driver (Which mostly should be handled by the OS).

I could not live without my scroll wheel. After a bit of searching, I could enable the scroll bars via: … / Preferences / Common / User Interface / [ ] Show scrollbars in editors
After enabling the scrollbars, I had to restart the schematic editor to make them visible. Then I zoomed in a lot, and the scrollbars behaved nicely proportional to how far I dragged them.

No. That is not how scrollbars generally behave. Clicking on a scrollbar moves the “grab point” of the scroll bar to the mouse cursor. So my PDF viewer scrolls to page 50 I I click on the middle of the scrollbar in a 100 page document. That is how all my Linux programs behave. Maybe some other OS behaves differently, It may even be configurable in your OS. Yet another reason why (probably) few people see your problem, and why it’s not so “simple” as you assume.

6

I have to admit, I didn’t know Scrollbars were available either.
I found them in Preferences > Common, tried them and also found them to be rubbish. The slightest movement of the scrollpad and the Schematic seemed lost forever. Closing and then reopening the Schematic seemed the easiest way to find the drawing again.

No.
For a single wire, I’ll scroll out, move mouse (with wire attached), scroll back in and place the end of the wire.

OR

When a number of wires are to be placed, or a graphic line needs to be accurately placed, I use the RH Shift key in conjunction with the Direction arrows (with my left hand). This allows me to still retain the wire or line attached to the Mouse (with my right hand), while panning the Canvas.

7

I don’t understand this.
I have also didn’t know scrollbars exists. I have switched them on.
At schematic using scrollbars I can see about 1.5 sheet height empty paper over and under sheet.
It is when zoom is set to have whole sheet at screen.
If sheet is very, very small than much more free space is there, but schematic can’t be shift off the visible area.
KiCad 8.0.9 at Windows.

8

Hi @Piotr

I’m using 9.0.3 and I was using the Scrollbars when zoomed in to the schematic at the (normal for me) magnification.
The top of the drawing page is divided into 8 segments. I usually draw with only 2.5 to 3 segments filling the screen.

9

I’m correcting my post. Please see the Wikipedia article on “Scrollbar”:
[Scrollbar - Wikipedia]
My corrections:
“thumb”, not “scrollpad”
failed to use the correct term “trough”

RaptorUK

I’m using KiCad version 9.0.2
“Moving the scrollpad using the mouse gives me a smooth movement.”
If, by “Moving the scrollpad”, you mean clicking and dragging the scrollbar thumb, then I can’t duplicate your activity. For me, and anyone attempting to duplicate my problem, clicking and dragging the scrollbar thumb will result in a new viewport of the KiCad canvas that’s an undefined distance away from your origin.

dsa-t

“pan the canvas by moving the mouse while holding down the mouse wheel”
My problem does not reference mouse wheels or any other advanced features of pointing devices. It can be duplicated by using the left mouse button with the cursor over the scrollbar thumb.
“was this reported on GitLab?”
GitLab is a wonderful resource. But I don’t consider it to be the best forum for communicating problems with KiCad.

paulvdh

“I assume the cause is some specific hardware”
Regardless of your OS (Windows/Mac/Linux), scrollbar interaction by a primitive mouse is controlled by the client window and its software, not the host operating system. To be sure, extended hardware features of gaming mice and trackballs in fact can be limited by the OS.
‘clicking “in the scrollbar” area, but off of the “scrollpad”’
See my above correction about failure to use the correct term “trough”.
“Clicking on a scrollbar moves the “grab point” of the scroll bar”
Clicking in the scrollbar “trough” should move the viewport 1 page away, either vertically or horizontally. In KiCad, it doesn’t. It moves the viewport some large, undefined multiple of pages away.

jmk

“retain the wire or line attached to the Mouse (with my right hand), while panning the Canvas.”
That may be possible, but the broken scrollbar still remains.

10

I admit, the scrollbars don’t work (well) in all situations. But the problem isn’t just in the scrollbars, it’s also in the canvas size and zooming.

First, the whole usable drawing area (canvas) is way too large. Even zooming as far as possible doesn’t show the whole canvas. Zooming with the mouse wheel gives this situation:

image
image590×617 10.1 KB

Note how the scrollbar “thumbs” are still very narrow.

Zooming in with keyboard in this situation zooms out, so the wheel zoom and keyboard zoom behave differently.

I can grab the scrollbar thumbs, move them and see the (assumed) whole usable drawing canvas. But I wonder if anyone ever needs that.

In the previous situation, with that window size, if I zoom in as much as possible, the scrollbar thumb keeps it size all the time. Then, if I use the scroll arrow buttons, the thumbs don’t move at all and are useless in locating where I’m going, although the arrows themselves work (they always seem to scroll the amount of some percentage of the current view area).

With normal zoom levels the thumbs are useless because a tiny bit of thumb movement after grabbing moves the view way too much, for example using “Zoom to Fit” and moving a thumb moves the whole drawing page almost off the view, and when zoomed a bit closer, everything disappears from the view with the smallest thumb movement. I think this is what was described in the first post.

I don’t think the real problem is in the scrollbars, but in the way too large canvas which is useless for most use cases. I guess large enough width or height of the canvas would be something like 3 to 4 times the used drawing page width or height. Then the area outside the drawing page could be used for larger schematic or temporary or extra drawings or notes, as some of us use it. But I can’t imagine how larger canvas would be needed for any normal schematic. This is the maximum zoom distance in my screen with A0 page:

image
image2174×1942 151 KB

What would be the solution? I don’t really believe at all that the hard coded canvas size would or even could be changed, it has to be compatible with any old design. But maybe the used canvas area could be a user setting. For example:

  • Percentage of the maximum canvas, or
  • Percentage of the used Drawing page.

The user could choose to show and use much smaller area than currently, and the potential viewport could be zoomed to that at farthest. The scrollbar thumbs could reserve the full width or height when the mimimum zoom level number would be reached, either the width or the height being the limit.

By the way, the Issue Description isn’t accurate in all respects.

That’s not the only other way. Keyboard can be used. Shift + Arrow moves the viewport. Also, there are these settings:

image
image1029×232 7.41 KB

Middle button drag was already mentioned, but the right button drag also works in case of missing wheel. It works well, is easy to use and is efficient.

All discussion of this problem is either distracted by 1) irrelevant factors (scrollwheels, touchpad, etc.), or 2) various coping strategies avoiding use of scrollbars (like zoom out & re-center).

It’s demeaning to call them irrelevant factors or “coping strategies”. Using scrollwheel or a touchpad gesture to zoom and re-center is so good invention that I think most of the users use them without further thinking and never need the scrollbars or keyboard panning. That’s probably why the scrollbar system hasn’t been fixed. If a relevant bug report get thumbs up from users, the developers see it’s needed.

11

eelik, you make some very good points. Especially about better use of the canvas by KiCad. Most popular softwares make use of the OS API. Your app can numerically and with high precision capture the screen resolution of the user’s display. The KiCad app could define the canvas dimensions accordingly at launch. If they wanted to, they could even allow the user to assert different values through Preferences.

My main beef is that all users don’t use the same hardware. Apps should of course enable use of the latest and greatest hardware products. But, at a bare minimum, any broadly published app should at least support the most primitive hardware. By that, I mean a simple 2-button mouse and basic keyboard.

That logic is my reason for the derogatory terms of “irrelevant” and “coping”. A KiCad user shouldn’t be penalized for not using a gaming mouse or a sophisticated touchpad, For that reason, to me, recommendations of alternate U.I. techniques are irrelevant. Also, I consider being forced to use them as coping.

Your comments appear to me as the most informed and articulate so far.

I couldn’t find a way to DM anyone from KiCad about this, so I replied to johnbeard (one of the developers) on his post on another topic. Hopefully, he’ll weigh in. If he doesn’t, if anyone here can get the attention of any KiCad folks, we all would appreciate it.

12

The first statement in my comment was I didn’t even know scrollbars existed or could be activated. I found them, activated them and used them.
I didn’t like them and couldn’t see the point of them using your example because panning using the scrollbars means finishing drawing to move the scrollbar, then re-starting drawing to continue.
Both the methods I use will move the canvas without having to stop and re-start the function attached to the mouse.

Yes the scrollbar is too sensitive or the canvas too large or whatever, but I don’t, and won’t, use that method because it is too cumbersome.

13

Every standard office mouse nowadays has a wheel. Even Apple gave up a long time ago and added scroll wheel functionality. You don’t need a “gaming mouse”. Touchpads are sometimes difficult, there are different button/finger/gesture combinations, but most of them can be used with KiCad zoom/pan system. In any case, for productive CAD work you should have a proper mouse, and I don’t think KiCad has any exceptional requirements.

KiCad development process doesn’t work that way, some developers read this forum and may sometimes answer here, but the gitlab issue database is the way to file bug reports and wishes.

I don’t think we are talking about the same thing. KiCad canvas is limited by the coordinate system which has nanometer accuracy and some maximum values, the visible representation is a different matter. My idea was that the user could limit the usable coordinate system area in the settings. The graphic system of KiCad and the used technologies take care of scaling etc., they aren’t the problem.

14

Closing and then reopening the Schematic seemed the easiest way to find the drawing again.

The Home or Ctrl+Home key may be easier for that. AKA these: image

Double middle click is equivalent to Ctrl+Home too (that’s a bit of a secret shortcut, to be fair), and F4 is 'centre view on cursor".

In the PCB editor, pre-set viewports are also good way to hop about the place in a defined way using Shift+Tab.

I, for one, have DMs turned off quite deliberately exactly to avoid people randomly DMing me about their personal bugbears du jour that are nothing to do with me personally. If you wish to report a bug, Gitlab is the only correct place. If you wish to talk with other users about whether the agree if something is a bug at all, or you have missed an existing tool or method, or asking for other user’s opinions, this unofficial forum is a good, but not the only, place for that.

I suspect you could file a bug on Gitlab and it would get looked at, because the scrollbars do seem a bit twitchy due to the massive canvas (this has changed from 8 to 9, by the way, which explains why some people in this thread don’t see it). I also suspect it would get a “low” priority because most (I guess: I certainly don’t, but we don’t have tracking of this kind of thing) people don’t use or even enable the scrollbars to move around, as it’s generally much faster to use all the other methods, because KiCad documents are much more 2D and zoom-focused than a web page or PDF document. At most to me scrollbars are more useful as a “you are here in x and y” indicator (which, yes, they’re not doing a great job of now I turned them on).

15

Thanks for the comment, but the scrollbars are already turned off again. As I mentioned above, having to interrupt drawing to adjust scrollbars is just an unnecessary nuisance for me.

16

You can penalize me for using AI, but I asked chatgpt and deepseek, and they told that

So by 1998–2000, scroll wheels were standard on most mice, especially for PCs used in office and home settings.

By the mid-2000s, it was rare to find a mouse without a scroll wheel, making it a standard feature in modern mice.

So we are talking about standard >20 years old home/office technology, not about gaming. Of course it’s not the “most primitive”, but logically we could continue and go back to DOS or old unix command line and plain keyboard. Or do it without computers. I agree that in the current state of KiCad the scrollbars aren’t very useful, they would benefit from some love (and the canvas is uselessly large!), but otherwise I don’t find your arguments very persuasive.

17

So, you can assign Pan to right mouse button in Preferences, what’s the problem with that?

18

My guess is that KiCad’s scroll bars are mainly meant for “emergencies” and "unusual workflows, such as mobile working with only a scratchpad, or on a tablet.