After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 775756 - Add tap and drag
Add tap and drag
Status: RESOLVED FIXED
Product: gsettings-desktop-schemas
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gsettings-desktop-schemas-maint
gsettings-desktop-schemas-maint
Depends on:
Blocks: 775324 775755
 
 
Reported: 2016-12-07 13:29 UTC by freeroot
Modified: 2017-01-05 15:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Suggestion of code (1.74 KB, patch)
2016-12-07 13:29 UTC, freeroot
none Details | Review
Suggestion of code 2 (1.75 KB, patch)
2016-12-08 08:56 UTC, freeroot
none Details | Review
Suggestion of code 3 (1.92 KB, patch)
2016-12-09 14:13 UTC, freeroot
none Details | Review
schemas: Add "tap-and-drag" for touchpads (1.35 KB, patch)
2017-01-05 15:28 UTC, Bastien Nocera
committed Details | Review

Description freeroot 2016-12-07 13:29:51 UTC
Created attachment 341552 [details] [review]
Suggestion of code

The problem is that you can't disable dragging when tap-to-click is enabled. For people who have a sensitive touchpad and who like tap-to-click option, dragging is launched even when you don't want it : for example, when you select a folder, most of the time the folder is dragging whereas just selected or when you want to select some lines of a text file, several lines are moved as a cut-paste which is not expected and erase datas.

To fix it, you need to have the possibility to desactivate the drag option when you use tap-to-click and gsetting schema must be modify to have the tap-and-drag option.
Comment 1 freeroot 2016-12-07 13:35:02 UTC
tap-and-drag is already in specification of libinput but not in mutter, gnome-control-center nor gsettings-desktop-deamons. So, 3 commits are necessary to let the possibility to people to choose tap-and-drag or not. That's why I opened 3 bugs for 3 modules of gnome :

mutter: https://bugzilla.gnome.org/show_bug.cgi?id=775755
gsettings-desktop-deamons: https://bugzilla.gnome.org/show_bug.cgi?id=775756
gnome-control-center: https://bugzilla.gnome.org/show_bug.cgi?id=775324
Comment 2 freeroot 2016-12-08 08:56:52 UTC
Created attachment 341597 [details] [review]
Suggestion of code 2

summary and description correction from "suggestion of code 440e8404323eeaf5fc7696ac36d63f137beeeccc"
Comment 3 Bastien Nocera 2016-12-08 15:36:43 UTC
The idea is fine, but can't the hysteresis be fixed in libinput directly, so we don't need the fix (yet)?
Comment 4 freeroot 2016-12-08 22:41:54 UTC
Tap-and-drag is already in libinput (https://wayland.freedesktop.org/libinput/doc/latest/tapping.html)

You can use this option with Xorg by managing the driver xf86-input-libinput but you can't use tap-and-drag in wayland. That's why I want to add it to wayland/mutter and do this dependance.
Comment 5 Peter Hutterer 2016-12-09 00:01:17 UTC
I think what Bastien is referring to is that if you start drag events when you don't intend to, that's a bug in libinput and should be fixed there. Because this option isn't needed if your touchpad would work correctly. So let's see if we can fix this in libinput first.
Comment 6 freeroot 2016-12-09 00:16:28 UTC
OK, I haven't thought about it because I have a macbook and on mac os I disabled drag for the same reason.

So, I will add a libinput bug but, in my opinion, the possibility to enable/disable drag make still sense.
Comment 7 freeroot 2016-12-09 00:33:50 UTC
I go to libinput bugzilla and found this https://bugs.freedesktop.org/show_bug.cgi?id=93502 .

Cyril B. describes exactly my issue and this bug was fixed by adding the option tap-and-drag to libinput by you (Peter Hutterer) and I believe it's still a good way to do.

So, Enable/Disable tap-and-drag seems necessary in wayland.
Comment 8 Peter Hutterer 2016-12-09 06:44:05 UTC
This is a different use-case. In your case it sounds like the result of a bug, in Cyril's case it was a side-effect of the usage pattern. So yes, an option may be necessary down the road but not for your issue, I think.
Comment 9 Bastien Nocera 2016-12-09 13:14:11 UTC
(In reply to Peter Hutterer from comment #8)
> This is a different use-case. In your case it sounds like the result of a
> bug, in Cyril's case it was a side-effect of the usage pattern. So yes, an
> option may be necessary down the road but not for your issue, I think.

freeroot, can you please file a bug against libinput about this then?

I'll leave the patches here in case we want to commit those.
Comment 10 Bastien Nocera 2016-12-09 13:19:39 UTC
Review of attachment 341597 [details] [review]:

Marking as needs-work to get it off the review list. We'll need respin it when we actually have a need for it.

The commit message would also need some work, including adding the bug's URL.

::: schemas/org.gnome.desktop.peripherals.gschema.xml.in
@@ +24,3 @@
       <description>Set this to TRUE to be able to send mouse clicks by tapping on the touchpad.</description>
     </key>
+    <key name="tap-and-drag" type="b">

The key name and the description need work. I'd stick closer to the vocabulary used in libinput.

@@ +27,3 @@
+      <default>true</default>
+      <summary>Enable mouse drags with touchpad</summary>
+      <description>Set this to TRUE to be able to send mouse drags by tapping on and holding the touchpad.</description>

"mouse drags"?
Comment 11 freeroot 2016-12-09 13:35:50 UTC
(In reply to Peter Hutterer from comment #8)
> This is a different use-case. In your case it sounds like the result of a
> bug, in Cyril's case it was a side-effect of the usage pattern. So yes, an
> option may be necessary down the road but not for your issue, I think.

(In reply to Bastien Nocera from comment #9)
> (In reply to Peter Hutterer from comment #8)
> > This is a different use-case. In your case it sounds like the result of a
> > bug, in Cyril's case it was a side-effect of the usage pattern. So yes, an
> > option may be necessary down the road but not for your issue, I think.
> 
> freeroot, can you please file a bug against libinput about this then?
> 
> I'll leave the patches here in case we want to commit those.

I think it's my bad english that makes you feel/believe it's a different use-case of Cyril's case. You know that tap-and-drag in not in Wayland and you tell me to not add it while Cyril's case is not managed now in Wayland. If you prefer, fix the Cyril's case by adding tap-and-drag in Wayland, in all case.

I can add a libinput bug in parallele to alert about it but I believe it were just create a duplicate bug.
Comment 12 freeroot 2016-12-09 13:41:06 UTC
(In reply to Bastien Nocera from comment #10)
> Review of attachment 341597 [details] [review] [review]:
> 
> Marking as needs-work to get it off the review list. We'll need respin it
> when we actually have a need for it.
> 
> The commit message would also need some work, including adding the bug's URL.
> 
> ::: schemas/org.gnome.desktop.peripherals.gschema.xml.in
> @@ +24,3 @@
>        <description>Set this to TRUE to be able to send mouse clicks by
> tapping on the touchpad.</description>
>      </key>
> +    <key name="tap-and-drag" type="b">
> 
> The key name and the description need work. I'd stick closer to the
> vocabulary used in libinput.
> 
> @@ +27,3 @@
> +      <default>true</default>
> +      <summary>Enable mouse drags with touchpad</summary>
> +      <description>Set this to TRUE to be able to send mouse drags by
> tapping on and holding the touchpad.</description>
> 
> "mouse drags"?

The key name tap-and-drag is exactly the name used in libinput, that's why I used it but I will looking for a closer summary and description to libinput vocabulary.

"mouse drags" can't be used because it's only drags done from a tap.
Comment 13 freeroot 2016-12-09 14:13:20 UTC
Created attachment 341678 [details] [review]
Suggestion of code 3

Improve description
Improve commit message
Add bug's url to commit message
Comment 14 freeroot 2016-12-10 12:10:20 UTC
Finally, I added a bug in libinput for my issue. https://bugs.freedesktop.org/show_bug.cgi?id=99044 . I hope I will can use my touchpad soon.

I will report here conclusions of the bug in libinput.
Comment 15 Peter Hutterer 2016-12-21 02:58:54 UTC
update: based on the description in the bug in comment #14 this isn't a bug in libinput, it's simply that the reporter doesn't want to wait until after the tap-drag timeout to move the pointer. So this does indeed require the option be exposed by gnome.
Comment 16 freeroot 2016-12-30 22:19:42 UTC
Bastien Nocera, is my patch good now ?
Comment 17 Bastien Nocera 2017-01-05 15:28:08 UTC
Created attachment 342967 [details] [review]
schemas: Add "tap-and-drag" for touchpads

On some sensitive touchpads, tap-and-drag can be annoying, so we need a
way to disable it.
Comment 18 Bastien Nocera 2017-01-05 15:28:48 UTC
Attachment 342967 [details] pushed as 23f96de - schemas: Add "tap-and-drag" for touchpads