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 756795 - File chooser: Revert to the gtk-3.16 double clicking behavior
File chooser: Revert to the gtk-3.16 double clicking behavior
Status: RESOLVED DUPLICATE of bug 758065
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2015-10-19 02:45 UTC by micove
Modified: 2017-08-14 23:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description micove 2015-10-19 02:45:16 UTC
Reading bug #121113 I noticed that commit fb0a13b7f070a14312dafa1e4df6ba03cf33be01 was introduced to take out the 'sting' of double clicking. The problem is that for the people that want single click behavior this does not solve their request and for the people that want double-click behavior this hybrid approach ruins their workflow when using gtk3 applications that use filechooser.

Taking Gedit as an example when I try to open a file this happens:
- The 1st item on the list file or folder is selected by default. With this new behavior this already counts as 1 click. Therefore if I click the 1st item on the list it will either open the file or go down the directory. Any other item in the list requires 2 clicks to open or go down the directory. This hybrid approach makes no sense since now people have to think and act 1 way if the item was pre-selected and act another way if the item was not pre-selected. After 10+ years with the old behavior I end up double clicking the 1st item and either going 2 folders down (quadruple click!) or opening the 1st file that was inside the folder I just clicked. So I either have to close the file that I never wanted to open and start over or go 1 directory back (which made me notice that hitting backspace does not do it like in gtk2).
- If I try to select multiple I used just to click the first file and then use shift+<up/down arrow> or ctrl+click the rest of the files. Now I have to make sure to hold ctrl when clicking the 1st file or I risk opening it.

Luckily I don't use a gtk3 program that shreds file or something similar that would ruin my data by this behavior but I think it should be reverted to the old one since now single-click/double-click are affected. The users that want double-click would be happy this way and until a single-click option or a consensus is reached for #121113 the single-click users could use gtk-double-click-time = 100000 or something if they wanted the new infinite timeout behavior. Unlike single-click, there is no option for double click users to bypass this new behavior since the closest one would be by enabling GTK_DEBUG=interactive and using Simulate Touchsreen but the performance penalty is rather big and filechooser segfaults when closing at least on Gedit (could be related to #742676 and it segfaults every single time). This is not a realistic solution so I end up recompiling the library with that commit reverted so I can keep double clicking at max speed as usual.

Cheers!
Comment 1 Daniel Boles 2017-08-14 23:33:01 UTC

*** This bug has been marked as a duplicate of bug 758065 ***