Created attachment 106739 [details] The thin scrollbar that I can't use with a stylus Debian sid/Thinkpad Helix 2 tablet: I cannot use the "half width" Kickoff scrollbar with a stylus. I neither can use the similar looking scrollbar used to scroll the widgets when one want to add a widget to the panel. Generally speaking I cannot use the "thin" scrollbar (I have no keyboard, no mouse, and were I to use the touch screen, those scrollbars would be too thin anyway). Note that I can scroll desktop effects (in system settings). Thanks, Chris
With a touch screen, they should scroll on drag. Stylus support in Qt is a bit hit-and-miss, see https://bugreports.qt.io/browse/QTBUG-57485 Which Qt version are you using? There are some fixes in Qt 5.9.0.
I think scroll on drag is not yet possible in places that have a drag area like Kickoff or Widget Explorer, when you start flicking you actually start dragging instead.
(In reply to Christoph Feck from comment #1) > With a touch screen, they should scroll on drag. Stylus support in Qt is a > bit hit-and-miss, see https://bugreports.qt.io/browse/QTBUG-57485 > > Which Qt version are you using? There are some fixes in Qt 5.9.0. "scroll on drag": left click is touching the screen, so, yes, I do a drag action, which is exactly what I would do with a mouse too. "Qt version": is 5.7.1. Qt 5.9 arrived like a week ago in Debian/experimental; it's not supposed to be actually used, so I'll have to wait a couple of days before I can answer you about 5.9 "Hovering you spoke of in QTBUG-57485": When I stylus hover over panel's digital clock I get a bubble/tooltip showing me the date.
Hovering using the stylus does not work for QWidget. Try e.g. to get tooltips for toolbar icons...
(In reply to Christoph Feck from comment #4) > Hovering using the stylus does not work for QWidget. Try e.g. to get > tooltips for toolbar icons... Correct: With a Dolphin's window, if I hover toolbar's "Split" with a mouse I get a tooltip, but doing the same with a stylus, different computer but similar installation, I indeed get nothing. So I guess mouse and stylus are treated through completely different channels. Just for the purpose of illustrating the different behaviors (but actually quite useless): In the Plasma panel, click on "add widget". There you have a scrollbar, the thin type, but it is not reacting to stylus drag or hover (actually it changes color with stylus "click" which is "touching"). But if you manage to put the stylus in the very narrow gap between the scrollbar and the widget's icons, then you can drag the "canvas". You even have a "flicking" effect (inertia). But if you touch the widget's icons, it is not recognized as a drag action but as a click action and so it is not practical.
What is this bug tracking now? It's not totally clear.
(In reply to Nate Graham from comment #6) > What is this bug tracking now? It's not totally clear. After a Debian/sid upgrade minutes ago, I believe the bug is fixed: thin scrollbar, like the one for "plasma panel/add widgets", can now be moved with a stylus, on a Thinkpad Helix 2 tablet.
Fantastic, happy to hear it.
(In reply to Nate Graham from comment #8) > Fantastic, happy to hear it. However, not everything is fine: With the weather forecast widget: If I go in settings, and then in weather station; There there is a search field were you can type the name of your town; then there is a list of possibly relevant stations. If the list is too long or the window too small, then there is a scrollbar. It seems there is nothing I can do to slide that scrollbar (with a stylus): neither drag, nor even "click" on the up or down arrows. So it would seems the support for the stylus is not hard wired in the scrollbar, but is surprisingly, application dependent. However the bug should not be filed against "component - application launcher". Since it is the scrollbar itself that should have a predictable behavior: the scrollbar itself should implement stylus support. But I have no idea what component I should file the bug against. I will open a new bug when I know against what.
What you are seeing is a difference between QWidgets (that still don't see hovering events from Wacom tablets) and QML items (that do). The referenced Qt bug is still open, please add your concerns there.