Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)

[Jean Delvare <jdelvare suse de>]

Hi Matthias,

On Thu, 05 Oct 2017 13:02:34 -0400, Matthias Clasen wrote:
> On Thu, 2017-10-05 at 11:46 +0200, Jean Delvare wrote:
> > The change in single-click vs double-click in the GTK 3 file chooser
> > from commit fb0a13b7f070 ("file chooser: Allow activating without
> > double-click") causes more problems than it resolves. There have been
> > a lot of complaints about it:
> >
> > * The first item in a directory is selected by default, so a
> >   double-click on it misbehaves. Specifically, if that item is a
> >   directory, the first click enters the directory, and the second
> >   click will apply to whatever is listed first in that directory
> >   (which is also selected by default, so effect is immediate.) This
> >   is unexpected and quite confusing.
> > * The ability to activate a selected file or directory with a single
> >   click interacts badly with selection of multiple files. If you
> >   start the selection with a file which was already selected, then
> >   that file is immediately opened, before you have a chance to
> >   complete your selection.
> > * This new behavior is inconsistent with Nautilus, GTK 2 applications
> >   (which are sill many) or basically any other existing GUI toolkit.
> >   Having incompatible behavior between applications is confusing for
> >   the user.
> > * While a number of people are advocating the ban of double-click and
> >   the use of single-click for everything to make computers easier to
> >   use by non-tech-savvy people and people with limited abilities,
> >   this change does not even achieve that.
> >
> > If the problem that this change was supposed to address is that
> > double-clicking fast is a challenge for some people, this issue
> > should be addressed at the desktop environment level, by
> > accessibility tools and/or mouse configuration. The GTK 3 file
> > chooser is way too high level and specialized to handle this.
> >
> > So the best thing to do is to revert this change. Ubuntu has already
> > done so, and SUSE is in the process of doing the same.
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=758065
> >   
>
> You are just bringing back the complaints about double-click.

Not really. You still need to click twice in most cases, and I doubt
most people do two slow clicks just for the fun of wasting time. So in
practice it's still double-click, with inconsistency sprinkled.

Do you have any pointer to a bug report or mailing list discussion
where someone asked for the current behavior? As it stands, I am under
the impression that the only person who likes it is you :-(

> There is no winning here,

Did you not read anything I wrote above? The winning is clear and
obvious, to everybody who expressed their views in this thread, except
you.

>                            and I will not support any simple reversal
> unless it comes along with a person who is willing to maintain the
> filechooser long-term,

I would understand the logic if I was adding new code, or changing the
behavior to something uncommon or risky. This is not the case, I'm
removing code, and the behavior is the same as it used to be. I can't
see how it would cause any extra work to the maintainer.

If I were in a playful state of mind, I'd just accept the deal and
agree to maintain the code. After all, the last behavior change was
done by you, and your way to maintain the code is apparently to simply
ignore the massive complaints that was raised by this change. Seems
easy, I'm sure I can do it too ;-)

>                        and field all the complaints from the 'its still
> not the same as nautilus' crowd.

I have no idea why you mention Nautilus here. The current
implementation is not the same as Nautilus either, so this is not a
valid argument.

> IMO the way forward for the file chooser in GTK+ is
> GtkFileChooserNative, making this entire mess somebody elses problem.

Could be. But I don't see such a big change happening in GTK 3 anymore,
so that doesn't help.

Please be reasonable, admit that commit fb0a13b7f070 was not a good
idea, and accept to revert it.

Thanks,
-- 
Jean Delvare
SUSE L3 Support