Oh, and tap-to-click disabled persisted into the boot of the new system.  I had to log into GNOME and turn it on.

(In reply to Frank Griffin from comment #1)
> Oh, and tap-to-click disabled persisted into the boot of the new system.  I
> had to log into GNOME and turn it on.

More precisely, it was disabled in GDM.  GNOME has it disabled by default, so I expected it to be disabled there.

for gnome, olav already sayds he don't want to change uostream settings, for installer let see with maintainer

Assignee: bugsquad => thierry.vignaud

If that's the gtk+ default, I don't think we want to diverge from other gtk+ apps/desktop.
Users could be disoriented if installer behaves differently than desktop or other distros.
My 2 cents

Well, they're also going to be disoriented when tap-to-click, which has worked since forever in the installer, suddenly doesn't.  Why anyone would want to disable this is beyond me.

Also, anyone who doesn't use tap-to-click and uses the actual buttons isn't going to see any difference, since they wouldn't try tapping anyway.

Ping ?

(In reply to Frank Griffin from comment #5)
> Well, they're also going to be disoriented when tap-to-click, which has
> worked since forever in the installer, suddenly doesn't.  Why anyone would
> want to disable this is beyond me.


Well, because a lot of users weren't/aren't aware of the feature?

https://wayland.freedesktop.org/libinput/doc/latest/tapping.html

I wasn't aware this was a feature!

For many years, the first thing I tried to remember after doing a fresh install on a laptop with touchpad, was to disable the touchpad. I had accidentally touched it way too often, causing an unwanted "click and drag" that e.g. moved a Thunderbird subfolder into another one. 

Once, when I had forgotten to disable the touchpad, it even caused a directory with sensitive private data from ± 4000 people to be moved into a directory that was published and world readable on the internet, without me noticing it :-( 

After doing a fresh install on a laptop in January this year, and again having forgotten to disable it, when I remembered later I realised that I no longer had such accidents.

And only today do I understand why.

I'm perfectly happy with the new behaviour, and hope we'll keep touch-to-click disabled by default!

(Reassigning to pkg-bugs ml)

Assignee: olav => pkg-bugs
CC: (none) => marja11

I much prefer having it enabled, its faster and you can do middle button emulation which is insanely useful.

For the installer I don't think that matters so much, I would prefer it to be active, but there aren't that many clicks, although it does seem strange it not working when multi-touch scrolling does.
I don't see users being confused about it working there and not in the desktop, especially as it is a simple thing to change.

This applies to Plasma too, its disabled there by default which is where my main annoyance comes from.

CC: (none) => watersnowrock

Keep it disabled !!!!!!! i have always hated whole feature,why it's so hard to click and enable it manually from desktop settings. ?

CC: (none) => ozkyster

(In reply to Otto Leipälä from comment #10)
> Keep it disabled !!!!!!! i have always hated whole feature,why it's so hard
> to click and enable it manually from desktop settings. ?

I don't like the feature at all, either, but now that I became aware that:
* it's disabled for tablets, too
* there are touchpads that come _without_ buttons
do I know that some users may have to go out and buy a mouse to be able to do that "easy click" to enable touch-to-click

I do very much hope someone smart can provide patches to:
* detect whether "mouse" buttons are available
* create a matching default setting

(In reply to Otto Leipälä from comment #10)
> Keep it disabled !!!!!!! i have always hated whole feature,why it's so hard
> to click and enable it manually from desktop settings. ?

By that logic it is a simple click to disable it.

I feel as Marja pointed out that the impact of having it enable with an easy option to disable is far less likely to cause issue than having it disabled.

Well we can discuss all we want, but as long as we haven't identified what component governs this behaviour, we can't patch it.

Once we know what changed the behaviour, I would propose to bring that upstream, hear their reasons for the change, and see if we agree/disagree in the *whole* Mageia community.

There's never One Setting to Please Them All, and if upstream changed the default, they probably had good reasons to think that it would be better for their users as a whole. If we want to decide otherwise, we need very good reasons to do so and not just base it on the complaints of one user. Diverging from upstream is never something that should be done lightly, as it greatly increases the maintenance burden on our side (see e.g. oxygen-gtk and the thousand issues it gave us until we synced with upstream and started using adwaita - or more recently the breakage in libuser due to use tcb that no other distro is using).

(In reply to Otto Leipälä from comment #10)
> Keep it disabled !!!!!!! i have always hated whole feature,why it's so hard
> to click and enable it manually from desktop settings. ?

Because the install has no desktop settings to allow changing it.  If I had the option of turning it on in the install, I wouldn't have bothered to enter the bug.

I've entered the various bugs on this for two reasons, one far more serious than the other.

The serious one is environments which provide no way for the user to enable the feature (installer and the various DMs).  This is unacceptable, because if the GTK+ (or whatever) default changes, the user is screwed.

The less serious one is the default setting for desktops.  I enter the bugs to make people aware that a behavior MGA users have come to expect has changed.  If everyone is OK with that, I'm OK with it too, as there are simple and obvious ways to change it back to what I want.

@Marja

I don't know if anything pays attention to xorg.conf any more, but there are settings in there to affect the sensitivity and response of a touchpad or similar device, and it may well be that they ought to be tweaked to eliminate the behavior to which you object.

@Remi

This is a single setting that hardly approaches the customization done for oxygen.  I agree with your approach for querying upstream and then making our decision, but I'd point out that whoever was involved in implementing this change should have followed your advice way before this point in the release cycle.

(In reply to Frank Griffin from comment #14)
> 
> @Remi
> 
> This is a single setting that hardly approaches the customization done for
> oxygen.  I agree with your approach for querying upstream and then making
> our decision, but I'd point out that whoever was involved in implementing
> this change should have followed your advice way before this point in the
> release cycle.

"Whoever was involved in implementing this change" is, again, upstream. Packagers mainly package new versions of tarballs, which contains thousands of commits, and we don't review those, that's the job of upstream.

So if you want to burn on a stake someone for having bumped a version number, synced the tarball, rediffed important patches and dropped obsolete ones, built the RPM, tested it and pushed to the buildsystem, then go for it, but don't expect us to help you do it.

There's no secret settings database where packagers mischievously toggle options on and off to change the "default behaviour" as they please. This stuff is done *upstream* in 99% of cases.

I'm not looking to burn anyone at the stake, nor have I claimed that someone "down here" toggled a setting.  Please stop putting words in my mouth.

This is a very visible behavior change, and in the case of the installer it's one that will be in every laptop user's face immediately when they pick up the product.  We have had a long slew of GTK+3 misbehaviors that have been fixed after the fact when people noticed them in the installer and entered bug reports, and there's no reason that this one should be treated any differently, whether we eventually choose to fix it or not.  As I said in comment 14, if I'm the only one who cares about it, then I'm out of luck.

And as I pointed out a year ago when I opened this bug, there was (at least) one case in the past where tap-to-click broke in the installer and the behavior was changed back.  What's changed since then ?

Please see https://bugs.mageia.org/show_bug.cgi?id=18972 .  The issue here is that during the release cycle we changed to using libinput, which chooses to disable tap-to-click by default.  It can be reenabled by using the workaround in bug#18972, and the workaround works for SDDM.  However, it doesn't work for GDM, and I don't know whether this is because GDM does something special to avoid using X11 standard configuration or whether this behavior is endemic to GTK+3 and therefore extends to the installer as well.

In any case, it seems worth pursuing to see whether the use of the bug#18972 workaround works for the installer.  As I noted in bug#18972, tap-to-click has been enabled in MGA1-5.  There is no reason to disable it now just because the libinput people have a different preference.

Keywords: UPSTREAM => (none)

*** Bug 28226 has been marked as a duplicate of this bug. ***

CC: (none) => mageia