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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Daniel Boles
On 5 October 2017 at 10:46, Jean Delvare <[hidden email]> wrote:

* 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.

Right. It doesn't help to enable single-clicking inconsistently, only if the item is already selected, thus being confusing and irritating when you open something you didn't want to, or find you can't single-click to open anything except the 1st item in the list. I find it perplexing how this was considered to improve anything.



_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Matthias Clasen
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.

There is no winning here, and I will not support any simple reversal
unless it comes along with a person who is willing to maintain the
filechooser long-term, and field all the complaints from the 'its still
not the same as nautilus' crowd.

IMO the way forward for the file chooser in GTK+ is
GtkFileChooserNative, making this entire mess somebody elses problem.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Daniel Boles
I apologise if there is, if I just blocked most of that thread out of my mind... but is there really a significant number of users out there who had these complaints about double-click and genuinely think what we have now is an unambiguous improvement? rather than just an apparent, superficial fix in one scenario (single-clicking on the pre-selected top item) compensated by regression everywhere else.



_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Tomasz Gąsior
In reply to this post by Matthias Clasen
> 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.
>
> There is no winning here, and I will not support any simple reversal
> unless it comes along with a person who is willing to maintain the
> filechooser long-term, and field all the complaints from the 'its still
> not the same as nautilus' crowd.
>
> IMO the way forward for the file chooser in GTK+ is
> GtkFileChooserNative, making this entire mess somebody elses problem.

Can't you just add ability to change single- or double-click behavior in
dconf?

For example you can create setting
"/org/gtk/settings/file-chooser/click-mode" with two possible values
"double" or "single".
If "click-mode" is set to "double", do nothing because this is default
behavior of GtkTreeView. If "click-mode" is set to "single", set
"activate-on-single-click" property of GtkTreeView class to "true".

It's all. It seems to me it would be simple to maintain in the future.
And this way is more consistent — you always have to double-click or
single-click. Also you don't have to write a lot of code — all it's
needed is in GtkTreeView now.

---
Tomasz Gąsior
https://tomaszgasior.pl
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Charles Lindsey
In reply to this post by Matthias Clasen
On Thu, 05 Oct 2017 18:02:34 +0100, Matthias Clasen <[hidden email]>  
wrote:

> You are just bringing back the complaints about double-click.
>
> There is no winning here, and I will not support any simple reversal
> unless it comes along with a person who is willing to maintain the
> filechooser long-term, and field all the complaints from the 'its still
> not the same as nautilus' crowd.

The fact that the "Look and Feel" of the filechooser agrees with that of  
Nautilus is a Feature, not a Bug. It is utterly nonsensical to even thing  
of changing it, and if Ubuntu and Suse are reversing the change on their  
platforms, then I applaud that.

It seems to me that those who are developing GTK are answerable to no-one,  
and it they continue to behave in this way, we shall simply all be forced  
to switch to QT. It is ridiculous that they are pressing ahead with GTK4  
at a time when several exceeding important applications had not even  
switched to GTK3 (and I am beginning to see why). The file changer in  
these applications will remain as it is, so that everyone will find  
different windows which look the same behaving entirely differently.

--
Charles H. Lindsey ---------At my New Home, still doing my own  
thing-----------
Tel: +44 161 488 1845                         Web:  
http://www.cs.man.ac.uk/~chl
Email: [hidden email]      Snail: 40 SK8 5BF, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4  
AB A5
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Matthias Clasen
In reply to this post by Matthias Clasen
On Fri, 2017-10-06 at 09:52 +0200, Tomasz Gąsior wrote:

> W dniu 2017-10-05 19:02, Matthias Clasen napisał(a):
> > 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.
> >
> > There is no winning here, and I will not support any simple
> > reversal
> > unless it comes along with a person who is willing to maintain the
> > filechooser long-term, and field all the complaints from the 'its
> > still
> > not the same as nautilus' crowd.
> >
> > IMO the way forward for the file chooser in GTK+ is
> > GtkFileChooserNative, making this entire mess somebody elses
> > problem.
>
> Can't you just add ability to change single- or double-click behavior
> in
> dconf?
>
> For example you can create setting
> "/org/gtk/settings/file-chooser/click-mode" with two possible values
> "double" or "single".
> If "click-mode" is set to "double", do nothing because this is
> default
> behavior of GtkTreeView. If "click-mode" is set to "single", set
> "activate-on-single-click" property of GtkTreeView class to "true".
>
> It's all. It seems to me it would be simple to maintain in the
> future.
> And this way is more consistent — you always have to double-click or
> single-click. Also you don't have to write a lot of code — all it's
> needed is in GtkTreeView now.

Adding an option is not a solution at all, thats just a way to avoid
finding a solution.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Tomasz Gąsior
W dniu 2017-10-06 16:41, Matthias Clasen napisał(a):

> On Fri, 2017-10-06 at 09:52 +0200, Tomasz Gąsior wrote:
>> W dniu 2017-10-05 19:02, Matthias Clasen napisał(a):
>> > 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.
>> >
>> > There is no winning here, and I will not support any simple
>> > reversal
>> > unless it comes along with a person who is willing to maintain the
>> > filechooser long-term, and field all the complaints from the 'its
>> > still
>> > not the same as nautilus' crowd.
>> >
>> > IMO the way forward for the file chooser in GTK+ is
>> > GtkFileChooserNative, making this entire mess somebody elses
>> > problem.
>>
>> Can't you just add ability to change single- or double-click behavior
>> in
>> dconf?
>>
>> For example you can create setting
>> "/org/gtk/settings/file-chooser/click-mode" with two possible values
>> "double" or "single".
>> If "click-mode" is set to "double", do nothing because this is
>> default
>> behavior of GtkTreeView. If "click-mode" is set to "single", set
>> "activate-on-single-click" property of GtkTreeView class to "true".
>>
>> It's all. It seems to me it would be simple to maintain in the
>> future.
>> And this way is more consistent — you always have to double-click or
>> single-click. Also you don't have to write a lot of code — all it's
>> needed is in GtkTreeView now.
>
> Adding an option is not a solution at all, thats just a way to avoid
> finding a solution.

Putting ability to control behavior of this thing to the user is the
best and the simplest solution that we can find.

---
Tomasz Gąsior
https://tomaszgasior.pl
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Daniel Boles
In reply to this post by Daniel Boles
From: "Charles Lindsey" <[hidden email]>
To: [hidden email]Subject: Re: [PATCH] file chooser: Restore consistent click behavior
        (for gtk        3.20) 

It seems to me that those who are developing GTK are answerable to no-one,
and it they continue to behave in this way, we shall simply all be forced
to switch to QT. It is ridiculous that they are pressing ahead with GTK4
at a time when several exceeding important applications had not even
switched to GTK3 (and I am beginning to see why). The file changer in
these applications will remain as it is, so that everyone will find
different windows which look the same behaving entirely differently.

 
It is a non sequitur to say that developing a new major version should not be allowed because some users are still on the previous stable version.

It is equally irrelevant to completely omit the fact that the current stable version is now LTS and seeing more and more applications, DEs, etc moving across to it.

Having a separate bleeding-edge development branch is a precondition for having a really stable one, and now that exists. So, that problem was solved. Yet apparently, somehow there are those who want to construe the solution as a problem in itself...

And as always, just complaining about the development means very little when so few of the complainers ever contribute any resources to improve the state of things. If you want to change the focus of "those who are developing GTK", become one.


That's all kinda separate from the original topic, which I still think should just be reverted until it's done properly, but anyway.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Jean Delvare
In reply to this post by Matthias Clasen
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
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list