Touch Screen behaviour

MusicBrainz Picard
1

so this might just be an odd “me” thing, if so, please ignore.

my lazy arse likes sitting on the sofa and using ipad/iphone to do stuff via RDP session on my servers and windows machines in other rooms and floors.

i’m highly efficient and productive like that by now.

every now and then I encounter an app that does not behave - touch screen wise - as expected. usually though it’s older apps.

mb picard is one of those for me. I cannot scroll through listings in picard like I expect.
for example, I need to touch something in the tag pannel and then while still touching it, drag down or up to scroll. which basicall marks everything I scroll through. if I try to flick to scroll (like one does on touch screens), picard tries to move the object i touched for the flick starting point.

I dont know what this is (a library, an intended behaviour, an oversight…) but it’s not proper touch screen behaviour and irritating and less productive.

mp3tag is a good working example, touch screen wise, jfyi.

1 Like
2

Picard uses Qt5, and I’d expect there to be some touch support, but I don’t know really how much is default and how much must be programmed specifically. Looks like your finger behaves like a mouse pointer.

Picard definitely was developed as a desktop application with mouse in mind, I don’t think anybody ever looked at how this behaves on a touch screen. I don’t even have a laptop or PC with a touch screen to test this with. I think that could be improved, but low priority really and needs someone interested in doing this work.

I think your finger is just used as the mouse pointer. So you are kind of abusung the drag and drop and selection behavior: If you drag an item over the edge of a widget that can scroll scrolling will happen, so you can reach elements not yet visible to drop onto. Same happens for selection, where when start a selection and reach the edge of the widget it starts scrolling, so you can continue to select items not yet visible.

But why don’t you use the scrollbar? You are basically using a mouse without scroll wheel, and the scrollbar is the UI element that allows you to scroll using the mouse pointer.

3 Likes
3

I am not sure whether behaviour using RDP from an iPad would be the same as behaviour on a Windows-based touch-screen either.

However from previous experience (on Javascript) there tend to be different events presented by the O/S and so I suspect that there would need to be some additional code added to make Qt5 respond as expected.

However, I do have a couple of touch screen Windows machines, and can do some quick testing.

As soon as I get the time, I will try this and raise a Jira ticket describing any issues I find.

6 Likes
4

@Sophist According to the docs at QTouchEvent Class | Qt GUI 5.15.16 we would need to set Qt::WA_AcceptTouchEvents on each QAbstractScrollArea viewport. That means all places where a QScrollArea is used directly, but also each QListView or QListWidget (which also inherit from QAbstractScrollArea). The code would look something like this:

scroll_area.viewport().setAttribute(QtCore.Qt.WA_AcceptTouchEvents)

A quick test would be to set this on one of those widgets and see how this behaves on a touchpad. If it enables scrolling with touch swiping, and normal interaction with both mouse and touches works, then we could enable this for all the scrolling widgets.

I wonder this as well. If RDP just passes the touches around as mouse event the above won’t make any difference for this use case.

4 Likes
5

I won’t have time to set up a development / run from source environment on the touch screen systems, so not able to try this out. But if someone wants to start a PR and pass me the executable that gets created I am happy to test old vs. new and see what happens.

Once we have worked out what needs to be done, I imagine that it might be possible to create a sub-class of QAbstractScrollArea which sets touch events and thus limit the code changes to something generic.

As for RDP, if it works native that is probably the best we can achieve. If RDP doesn’t work - and that may be dependent on the client implementation on various devices - there is probably not much more we can do.

2 Likes
6

Using the scrollbars is most of the times at least on small screen estate really cumbersome.

And in dark mode, who can see them anyway lol.

It is a QT5 thing, qbittorrent behaves the same as picard. only there I dont have to scroll much so it’s less bothersome.

In the RDP session I can chose if I want the touch screen emulation or the mouse pointer.

I dont think I’m abusing anything, just working around a qt limitation. All other than qt apps work fine and as expected.

I just wanted to mention it, it’s not like it makes picard any less cool or useful to me :slight_smile:

1 Like
7

I used a Surface for a few days. Felt the same as the iOS tools when using the RDP session.

8

Let me know if I can test something on my end.

9

I was trying the attribute thing here, but it works without it. It requires two fingers to scroll, just like with the trackpad.

Trying to catch the GestureEvents and stop dragging/selecting things, but sometimes the drag/selection starts before the gesture =x

3 Likes
10

Is there anything I need to do here? Or is this left like it is? Using 2 fingers does nothing for me.

Maybe I should post this with the Qt people? After all, it’s only apps built using their stuff that arent working properly when using touch input.

11

Maybe. I really don’t know. Gabriel above indicated touch behavior works without changes. But two finger gestures probably don’t work via RDP?

To be honest I would like to have Picard work properly via touchscreen, but trying to work around RDP limitations I’d I think out if scope. If things behave nicely on a touch display I work say there is no todo. But as I don’t have access to a device that has a touch display and can run Picard I can’t really test this.

Unfortunately Gabriel seems to have removed his MB account. I hope he is not completely gone, as he also was a Picard contributor.

I am currently traveling, but once I’m back I could create a test build with some changes and ask Sophist to test it. But apart from that I think any more substantial changes would require someone who has the skill and time to do the coding and has access to the required hardware

1 Like
12

I’ve asked. Let’s see what the QT folks have to say. So far no one seems to give a flying fling.

My experience with these kinds of annoyances is, sooner or later they iron themselves out and it suddenly works.

Here’s to hoping it’s rather sooner than later lol.

13

I’ve been asked by the QT people what version of QT Picard uses? Do you know?

Also, this: “there is something like QScroller::grabGesture( m_tableWidget, QScroller::TouchGesture ) missing in the code for touch screen”

Not that I know what that means but seems a QT code thing.

1 Like
14

The current 2.6.3 for Windows uses Qt 5.15.3.

But the QScroller comment is interesting. Looks like this QScroller thing can be used to enable kinetic scrolling on any scrollable widget. We would need to go through many places of Picard to set this, and I don’t know if there is a negative impact if this gets set without a touch device available, but that’s definitely something that should be tried. I’ll look into this once I’m back from travelling.

3 Likes
15

Apparently this:

“5.15.3 means a commercial LTS release, they should leverage that and check with the Qt Company.”.

I think that’s all I’m getting out of the QT forum and since it’s not really a high priority for me as well, I’ll gladly wait until you’re back and had time to look into it.

Thanks so far!

2 Likes