I’m trying the beta on my laptop and In the current version, dragging my finger up or down the page (inside The Editor) highlights the text rather than scrolling the screen. (In Scrivener 1, the screen scrolls.)
Am I not seeing a setting for this, or is this how it’s intended to function? (I hope it’s not the latter.)
cheers
I would like to bring this same question/concern from late 2017 back on the radar… Surface PCs and other touch-screen enabled Windows machines are one of the main reasons to be a Windows 10 user, but touch scrolling is still not present in beta. Loss of this feature in 3.0 would be very unfortunate and makes upgrading a concern for me. I don’t see any options to touch-enable document scrolling (not using the scroll bar, which is a difficult target for a finger, but using the page itself). Is this an oversight, and is retaining/restoring touch scrolling planned for this release?
I just started using the beta and noticed an issue that is probably unrelated but important. On Microsoft Surface Go, using the mouse to select text on a PDF selects text several lines ABOVE the cursor position rather than the text AT the cursor position.
This really bugs me. I like Scrivener but it works differently than every other text editing program on my computer. It’s a problem. Consistent user interface is important. Touch-screen drag should scroll, not select.
In the document list, It should scroll, not move documents. This gets me all the time – I want to scroll the document list and I end up accidentally moving a document instead. It’s even worse in that moving a document doesn’t add an entry to the undo stack, so I have to figure out where I dragged it from and move it back manually.
Can any developers comment on this? Is it a purposeful decision? I suspect it is, since it’s the same functionality as in Scriv 1. If so, what’s the rationale? Is there any chance of getting it fixed for the final release of 3?
David
I would guess that this has to do with the fact that Scrivener for Windows is not a native Windows framework application but is being developed in the Qt5 framework. This gives the team a starting point closer to the Mac OS APIs so they have to do less re-inventing of the wheel, but it does mean that some native functionality in Windows that we just take for granted is imperfectly surfaced in Qt or not present at all at this time.
I would also guess this is something they’ve not yet made any effort to address, as tweaking for touch systems on a platform that includes both touch and touchless hardware configurations (e.g. the entire Windows PC ecosystem) is likely a much lower priority than finishing getting all of the 3.x functionality in place working with keyboard and mouse as the lowest common denominator.
We have not tested all platforms and devices guys. We will definitely address this in the future, but the compiler, key functionality and bug fixes are our priority now. Have in mind that we are using the latest Qt 5.12.0, which was also released about two weeks ago, which might also contribute to a new set of bugs. Please, try also Ctrl+Scroll and check, if this makes any difference.
This is a big issue for anyone using a windows tablet (I’m using a Surface 3).
Its irritating when you’re writing as you have to use keybard or mouse to scroll but if you’re trying to use the tablet as a pure tablet just to read back a document its a disaster (and unlike any other windows product I use) as the only way to move through the document is by touching the very narrow “side bar” and using this to move the screen.
I’m just a customer, but have a small correction to your post: It’s not a Windows product. It’s beta software. It’s free, and you’re testing it.
For what it’s worth, I can’t even use the scrollbar in the folder pane, and it’s fairly dodgy in the text itself. Ctrl+touchpad scroll works, clicking on the scrollbar works, but all touchscreen functionality is limited to moving folders into other folders (where you didn’t want to move them) and the scrollbar just resizes the folders pane.
Re no way to scroll: you can scroll with a two-finger drag.
Re maybe this is a new bug: Nope. The functionality was the same in Scriv 1. If it’s really something that might be addressed eventually, great! Honestly, I’m not holding my breath.
Re not a product: Yes, it’s a product. It just happens to be a product that’s in open beta. Eventually, it will cost money. I will almost certainly buy a license. It’s not unreasonable to ask for certain functionality, particularly when the product is so clearly out of step with touch interface standards. I had hoped that version 3 would fix the touch issues, but it seems less and less likely as we get closer to the release date.
Not all programs are a good fit for a touch interface.
As another surface user I would love this as well. Feel like I can only use half the creative power of my device.
Rationalization - Noun
The action of attempting to explain or justify behavior or an attitude with logical reasons, even if these are not appropriate.
Often seen with Mac users trying to devalue touch as Apple has shown no interest it for OSX.
Note: My virtual Mac on Windows 10 uses my touch screen and it works pretty well.
Nice try, Wordjoy, but I’m a happy Surface Pro user.
Not all programs are a good fit for touch UI.
Yet the simple act of scrolling text on the screen, as is possible with virtually every other text editing application in Windows, is indeed a good fit for touch UI. We scroll text all the time, in almost every application that involves reading text on the screen: web browsers, ebooks, spreadsheets, word processors and text editors. Using touch to accomplish this is intuitive, and MIcrosoft has built it into the Windows API. Linux, and applications based on frameworks that originated on Linux such as QT, haven’t caught up to that yet.
’
For what it’s worth, LibreOffice Writer on Windows has the same problem as Scrivener in this case. Since it originated as a Linux application, I’d guess that its codebase is also based on a framework that doesn’t contain very good touch support yet.
I’m more than willing to give the devs time to work on this.
And yet, you rationalize.
It’s a reasonable request.
They are asking for something that I guess is in the current release version of Windows Scrivner.
I posted on this myself a few weeks back.
Its not like asking for some odd touch interface to edit with etc. It’s JUST SCROLLING.
I write with my HP on my lap. I often reach up and in other tools use my finger or thumb to scroll my pages.
That said, for now parity with Mac and getting the Compiler working enough for release is clearly more important…
But Windows is a touch-enabled OS, With most of its devices touch-enabled now. Some basic features like touch scrolling are not asking much and not something that is out of place as your statement suggests.
Yes, Touch screen scrolling is quite important for Windows 10 users, especially those with a tablet or touch screen hardware device.
I would expect touch screen scrolling support should be added soon.
It may be in the native Windows APIs, but Scrivener isn’t a native Windows app – it’s based on the Qt framework. If Qt isn’t passing that behavior through, that’s something the Qt devs will need to fix. That’s like getting superfreighter to change course. You can do it, it just takes more time and space than you would think.
I just have to revive this. I know it comes up every once in a while, but I don’t think we’ve actually heard anything from devs in terms of whether this behavior is purposeful. I frequently move a file or folder mistakenly when I’m trying to scroll the binder. The non-standard touch behavior is especially bad, since there’s no undo capability in the binder and it’s often difficult to figure out what change I just made, and it’s difficult to cancel the move even if I realize what’s happening mid-swipe. It’s perhaps my biggest frustration with the program. I was very disappointed when I started using the 3.0 beta and it hadn’t been addressed. Even more disappointed when it looked like the devs didn’t have any plans to fix it. My only conclusion has to be that no in-house testers or developers are regularly using touch-screen computers. If they were, I have to believe that this problem would be given a high priority.
agreed, I’ve done the same a few times on my surface device
From what I understood of what Tiho said, they do not plan on fixing it until they’ve got all the functionality of the standard desktop version working. I expect they’ll get to it at some point. Because it involves QT libraries, it may not be a trivial fix.