Hello.
I’ve decided to test the Beta for the first time in a very long time and immediately ran into some strange mouse wheel scrolling behavior, Scrolling with a mouse wheel is inconsistent and sometimes works and sometimes doesn’t. Most of the issues seem to involve what pane is currently selected. Often after selecting a document in the binder it scrolls fine, but if I mouse click on a different pane such as notes or bookmarks the editor window will not longer scroll with the mouse wheel even if I left click on the editor pane. Often, If I go back to the binder and click the document there then the editor window will start scrolling again. I’ve never seen this behavior in any other apps I have on this computer. Is this a known issue that will be addressed in a future update?
I’m using beta 36 and it’s not doing that for me; all scrolling is OK and seems to switch as expected. Not saying you aren’t having the problem but so far I can’t replicate it. Any chance you have another program “stealing” the mouse focus?
In Beta 42, if you position the mouse in the text area, the scroll wheel works. If it is positioned in the margins, the mouse wheel does not scroll the document.
I think this is the same problem as was also reported earlier in beta 27 and 29, but without isolating the issue as being the position of the mouse in the margin. See here:
And here:
[url]https://forum.literatureandlatte.com/t/lh4413-mouse-scrolling-problems-2-9-0-36/48772/1]
Note: I am not an L&L employee, this is my opinion. I don’t think this is a bug.
This is in the Fixed Width editor. Essentially, those margins are dead screen real estate buffers between the Binder, the Editor, and the Inspector. I wouldn’t expect to have the mouse positioned within either of those margins to scroll any of the three windows mentioned - how would the program know which pane you wanted to scroll? Positioning the mouse in any of the three panes will allow scrolling in that selected pane. I personally don’t used the fixed width editor. I hated having to figure out what width to use for each and every monitor I was testing the beta out on, especially when I was reminded that Scrivener is not WYSIWYG.
We do have a difference of opinion, Jestar. I believe it is a bug. First, it is not the way Windows applications normally work. (I cannot comment on Mac apps, but perhaps someone else can.) It has nothing to do with fixed margins or WYSIWYG. When you want to scroll a pane, you should be able to scroll regardless of where in the pane your mouse is positioned.
Second, it is disconcerting. The way it currently is, there are two live and two dead areas as far as the mouse wheel is concerned. The margins are dead. The text and the scroll bar (which are separated by a margin) are live. This requires an unnecessary degree of precision from the user, and breaks the user’s train of thought, which is the opposite of what Scrivener is about.
Actually, it is a bit worse than that, because there is a skinny space, visually indistinguishable from the margin (unless you change the colors) on either side of the text area that does scroll. So, from left to right, your scroll wheel encounters: 1) a wide, dead left margin, 2) a skinny, live left margin, 3) the text, 4) a skinny, live right margin, 5) a wide, dead right margin, and 6) the live scroll bar.
Edit: The good news is that there is a work-around as your post led me to discover: turn off the default fixed width, and if, like me, you can’t stand to work with narrow margins, you can increase the margins in File/Options/Appearance/Main Editor. Thank you!
Maybe different ways of looking at it. Somebody thought it was a bug and, even though it was not annotated in the subject of this thread, it has been fixed in beta 43:
Mouse wheel scrolling does not work in the editor left/right spacers in fixed width mode [4413]
I always looked at those “spacers” as border frames and hated the look, so switched to the old style of the non-fixed width editor (way back in beta 3). That was why I never considered the “spacers” as anything more than extra-wide vertical borders.
True, and why I switched to the non-fixed width editor.
As noted above, the fixed width editor “spacers” should allow scrolling now. Still hate the look of the fixed width editor, so I haven’t tested it out. But glad that you were able configure a workaround that works for you! I still have fairly narrow margin spaces right and left - just enough to display line numbers if needed and provide a bit of padding between the binder-editor-inspector panes. I rarely use the page view and worry more about what I am writing rather than what it is going to look like since I can change that come compile time.
This has been filed. Thanks.