Bug 85677 - Dragging on a Windows touchscreen highlights instead of scrolling
Summary: Dragging on a Windows touchscreen highlights instead of scrolling
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 99331 121000 125096 (view as bug list)
Depends on:
Blocks: Win-Touch
  Show dependency treegraph
 
Reported: 2014-10-31 03:41 UTC by evaned
Modified: 2020-03-09 10:58 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description evaned 2014-10-31 03:41:52 UTC
I am running LO 4.3.3 (tried upgrading from 4.2.2) on Windows 8 on a Thinkpad Helix.

For almost every program on Windows, trying to pan using the touchscreen scrolls. This is a very useful behavior.

However, on the LO applications (and Apache OOO as well), it acts like a traditional mouse drag, simply changing the selection.
Comment 1 Adolfo Jayme 2014-10-31 15:10:02 UTC
Thank you for your bug report.
Comment 2 Patrick Smits 2015-08-28 10:24:43 UTC
Same problem here under Windows 10. The only way to scroll through an open document is the little scroll bar on the right of the document's window, however this was designed to be accessed by a mouse/trackpad/trackball. It's a real pain to use by fingertip.

Now that Windows 10 on <14" touch screens are the new standard, it would be nice if LibreOffice could distinguish between a swipe gesture to scroll a document up and down and a tap-hold-drag to select text within a document.
Comment 3 FloydWaters67 2015-11-07 22:56:01 UTC
I can verify this behavior on a Windows 8.1 ASUS T100 tablet.  Additionally to swiping highlighting instead of scrolling, it is impossible in a spreadsheet to copy a formula by touch into a series of cells with a click and drag, the way you can do in MS Word.

This is a pretty big quality-of-life issue with using this program.  Please update to include true touchscreen compatibility ASAP.
Comment 4 Volga 2015-11-11 06:55:53 UTC
I can also verify this behavior on a Lenovo Yoga 13 ultrabook (upgraded to Windows 10). In this case touch the page can swiping highlighting texts in LO Writer instead of scrolling, but touch the scrollbar can scroll page, that’s so uncomfortable for touch screen devices.
Comment 5 Adolfo Jayme 2016-04-16 04:59:22 UTC
*** Bug 99331 has been marked as a duplicate of this bug. ***
Comment 6 Volga 2017-07-23 15:15:23 UTC Comment hidden (obsolete)
Comment 7 Volga 2017-07-23 15:16:25 UTC
A file previewing utility QuickLook, which uses macOS like quick preview feature to view the file on Windows, have already made an implementation for this, so let’s see how does it get the solution:

https://github.com/xupefei/QuickLook/commit/b0e8a29f856cf6b9d3c8da52754240e7875b64e3
Comment 8 Michael Goss 2017-10-25 22:41:43 UTC Comment hidden (me-too)
Comment 9 m.a.riosv 2018-10-29 17:02:46 UTC
*** Bug 121000 has been marked as a duplicate of this bug. ***
Comment 10 Martin Plamondon 2019-01-29 23:23:38 UTC Comment hidden (me-too)
Comment 11 V Stuart Foote 2019-05-04 13:21:17 UTC
*** Bug 125096 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2019-05-04 15:45:50 UTC
As noted, the touch screen behavior on Windows now selects under touch pointer, rather than panning x/y (to ranges of scrollbars).

So while two finger swipe vertical scroll, and <shift> two finger swipe horizontal scroll behaviors are correct with track pad--single finger swipe is not with touch screen panels. Guess that should probably be expected, they are different hw driver and os/DE integration.

@Tomaž, Mike K. -- with some generic support for gestures in VCL now for bug 124146, could we possibly support the screen touch scrolling here without the dev overhead of a full implementation of Windows Touch API (WM_TOUCH, WM_GESTURE messaging)[1]? 

MSDN suggests it is possible [2], and we seem to use some elements already in the gdi/salnativewidgets-luna for Windows builds.


=-ref-=
[1] https://docs.microsoft.com/en-us/windows/desktop/wintouch/windows-touch-portal
[2] https://docs.microsoft.com/en-us/windows/desktop/wintouch/improving-the-single-finger-panning-experience
Comment 13 Tomaz Vajngerl 2019-05-07 04:48:49 UTC
That "generic" gesture support was only to transport the events around, but responding to the event is only implemented for some widgets (ComboBox). 

Also what is needed is the backend support to recognize the gesture and send the event, so we need to implement Windows Touch API.
Comment 14 russianneuromancer 2019-05-07 06:00:44 UTC
Could you please clarify if this bugreport only about Windows touchscreen support, or about generic solution for supported platforms? Just want to remind that bug 121000 was marked as duplicate of this bug.
Comment 15 Tomaz Vajngerl 2019-05-30 14:02:32 UTC
Well this one is marked for Windows, but I guess it could be all platforms. I don't think it matter much at this time.
Comment 16 Lafricain 2019-08-29 11:11:43 UTC
I have the same problem on Ubuntu 18.04, on a Lenovo Yoga 300 with touch screen. the scroll and zoom don't work.
Comment 17 Lafricain 2019-08-29 11:12:22 UTC
I use the LO PPA with 6.3 version.
Comment 18 Xisco Faulí 2019-11-29 13:28:48 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 19 trowelandmattock 2020-03-02 20:00:16 UTC
An End-user, with Libre6.3 on win10/ubuntu Surface2, 10" touchscreen:



> touch screen will not control vertical scroll without selecting actual scroll-bar (which is thin and not expandable)

> furthermore, use of the main srcoll-bar with a stylus is very jerky.

> comparable issues with Linx7, 7" touchscreen device

> presumably same issues on similar devices also (IDK)



This is a BIG issue for use of LibreBase Forms with handheld devices (something I have been looking into) - making them almost un-useable without a mouse or touchpad.

This is a real shame and something I really hope can be addressed, particularly because android/linx/windows multi-boot cross-over devices have very many uses as advanced field-data collectors ... assuming a viable interface :/



End-user Solutions might look like:

1 - a page-control-scroll-bar to place directly in a LibreBase form !!! :)
2 - customizable width/princedom of the main Libre app-document vertical scrollbar, or at least an 'Extra_Wide' setting to toggle-on for small form factor touch screens...


Thanks Libre - keep it loose, keep it open :)
Comment 20 trowelandmattock 2020-03-02 20:01:48 UTC
(sorry about the rouge horizontal scroll bar up there :O)
Comment 21 trowelandmattock 2020-03-09 09:33:12 UTC
(In reply to trowelandmattock from comment #20)
> (sorry about the rouge horizontal scroll bar up there :O)





SOME VIABLE WORKAROUND NOTES FOR USERS OF SMALL TOUCH SCREEN FORMS:

1) - use virtual touch pad, place in corner of screen so buttons are hidden but just enough visible for 2-finger scroll-gesture 
[a bit of a fiddle for people who dont use touch screens often, or have more limited finger mobility/sensitivity]



2) - use 'finger-mouse' or hand-held roller-ball style thumb-controller with scroll-wheel. Quite functional for outdoors and situations where touch screen is not wanting to be touched ... but requires additional external device.


3)BEST SOLUTION = 
Use the 'jump-to' action of a text/control box when selected to focus that item in center screen : e.g. place long-thin dummy text-boxes alongside real form boxes and have them run as a thin chain down the screen at appropriate sizes> when a dummy box is tapped on that section of the page is focused mid-screen !!!

This method seems to work very well   :) !!!  - but users may need to be instructed as to functionality (ie  the control is now neither an easily recognizable scroll-bar nor directly intuitive touch-control.

Hopefully this may be of use to somebody also exploring interesting possibilities of linux+libre in data-logging for cultural heritage/field-work, but also suggests another possible developer solution - ie a new function for "push_button_control" = "jump_to_section" ....


THANK YOU LIBREOFFICE - I LOVE YOU :) !!!