> The real problem then surfaces: instead of just entering that folder, it enters the folder *and then enters whatever subfolder is under the mouse pointer* with the 2nd click. So instead of going 1 level deeper, it goes 2 levels deeper because it did not reset the click count quick enough.

This behavior is exactly I would like to see it. There are plenty of directories, containing single directory. Good example, is /home/user on laptop. Having possibility to passtrough this kind of directories is precious. This is the exactly the case, when double click could be somehow useful. 

Don't "fix" that!

I'm sorry but that's just broken and not what 9/10 of people would need the filechooser for. Besides, it never worked like this until this particular release (3.18).

If your goal is to traverse 20 levels of nested folders with a single folder in each without looking (very very very unlikely for a normal usecase), it would make more sense (and be more efficient) for you to use the keyboard's Enter key rather than the mouse.

Please try 3.18.5. It has a fix related to 'slow double click' in the file chooser.

I'll assume that was good, then.

The update finally landed in F23 and I can confirm it worked, thanks!

> I'm sorry but that's just broken and not what 9/10 of people would need the filechooser for,

"Not like in MacOS" is now know as "that's just broken and not what 9/10 of people would need".

BTW, who the hell are you to speak for 9/10 people?

Looks like gnome developers add good new features only by coincidence.

Matthias wrote:
> Please try 3.18.5.
> It has a fix related to 'slow double click' in the file chooser.

Ah, sorry to reopen, turns out it was only partially fixed after all. Let's say you have this folder hierarchy:

~/Pictures
   /A
     /A1
     /A2
   /B
     /B1
     /B2

With 3.18.5, if "B" is selected and you double-click it, it will correctly enter B without going into B2.

However, if you have A selected and double-click, it will enter A1 instead of just entering A. This seems to be related to the fact that it's the first item on the listview.

---------------
Lous1935 wrote:
> who the hell are you to speak for 9/10 people?

Oh, I'm a designer who has been involved in this community for over ten years and has made multiple deployments with the ability to study everyday users' behavior and the struggles they encounter. Anyway, as I pointed out, your usecase is covered by keyboard navigation, *and* the filechooser already defaults to your home directory.

Please refrain from further angry comments, it does not help your cause.

(In reply to Jean-François Fortin Tam from comment #8)
> Matthias wrote:
> However, if you have A selected and double-click, it will enter A1 instead
> of just entering A. This seems to be related to the fact that it's the first
> item on the listview.

Yes, the first item is already selected, so it's as if the first click was already done.

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

I can confirm this bug. Really surprising the first time you encounter it and can lead to error (wrong file selected). Especially when you choose "double click" in Nautilus. File chooser should follow what have been selected in Nautilus (single click or double click).

By the way this one is a duplicate I think:
https://bugzilla.gnome.org/show_bug.cgi?id=768628

Thanks !

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

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

I would love to be able to turn this behavior off (and I don't think it should be on by default).  It frequently leads to unintended attaching/opening of the first file in a directory.  This style of click-response is contrary to the last 30 years of my mouse-use habits.

(In reply to Nathanial Hendler from comment #14)
> I would love to be able to turn this behavior off (and I don't think it
> should be on by default).  It frequently leads to unintended
> attaching/opening of the first file in a directory.  This style of
> click-response is contrary to the last 30 years of my mouse-use habits.

Totally, and it's contradictory to _itself_.

Clicking on, or otherwise interacting with, a particular UI item should always do the same thing. It shouldn't matter whether said item is already selected or not. That's not intuitive and just annoying.

And while this problem affects all GTK+ users, it's especially inconsistent in GNOME - where you tell Nautilus to do single- or double-click  open, and then GtkFileChooser - which often tries to mirror Nautilus - does EITHER depending on how it feels at the given moment.

It should pick one click method and stick to it, not try to be clever like this. If the motivation behind this was to make things easier for tablet users with tapping - then default to double-clicking (or maybe even a GNOME setting) if a desktop machine is detected, and single-click if a tablet.

Anything would be preferable to the current behaviour, which might be trying to be 'one size fits all', but is really 'one size fits none'.

It's really unintuitive and lead to error or when you know the behaviour force you to be really careful about where you click. I really hope that will be fixed soon, ideally by following what have been selected in Nautilus (single click or double click).

Thanks !

@jeremy9856: Please refrain from adding comments to a bug report when your comment does not offer any additional information (or is just the same as in bug 121113). Every comment creates notifications that someone has to read (who cannot write or fix code in that time), and advocacy is not welcome.

Created attachment 341274 [details] [review]
[PATCH] FileChooserWidget: Activate by click consistently

Fwiw, this is how I would handle it. Simple and effective... almost too simple, making me wonder what I'm missing. So, please let me know if there's some pitfall I haven't thought of.

This made me wonder: Why is activation disallowed if the device is (or emulating) a touchscreen? How does activation occur on such input devices?

Comment on attachment 341274 [details] [review]
[PATCH] FileChooserWidget: Activate by click consistently

In fact it's simpler: double-click events are handled somewhere else. To me the solution is simply to revert commit fb0a13b7f070a14312dafa1e4df6ba03cf33be01.

Daniel, it seem that you have found the culprit ! Can this commit be reverted please ? It will fix the problem.

Later it will be great to follow what have been selected in Nautilus (single click or double click).

Thanks !

It's not up to me whether it can be reverted, but rather the maintainers and designers.

As you pointed out, it adds yet another inconsistency with Nautilus, and there have been efforts recently to reduce those in other areas, including by sharing GSettings and composite widgets.

However, see this reopened, 14-year-old bug about people not wanting to have to double-click, where Matthias stated that they do not want to provide/honour a fixed single/double click setting:
        https://bugzilla.gnome.org/show_bug.cgi?id=121113#c98

So, is that still a current opinion? Can we get some direction on what kind of patch people should submit, at least? The current behaviour doesn't work and has resulted in both tickets being reopened and spammed (including by me).

At the very least, when this change was made, it should have been accompanied by clearing the selection on changing directory (like e.g. Windows Explorer), so avoiding the problem shown in Comment 9, which seems the crux of the issue here.

2 things are needed:
 * a decision on, and _full_ rationale for, what to do
 * a patch that does it
The former seems considerably more elusive.

Can someone please tell me if this bug report addresses the following problem captured in this video screencast?

https://www.useloom.com/share/cd0cdc0a74534fe5b9c0568c385e8c9b

For further reference:

https://github.com/budgie-desktop/budgie-desktop/issues/986

I'm not going to watch that whole thing, but yes, it will be the same problem.

If we're not going to get a proper rationale for this choice from any designer or dev, can we please revert it? It is clear that many, many people dislike this and find it baffling/inconvenient, and no one even seems to be trying to defend it.

Daniel, thank you for your prompt feedback. I completely agree with you.

There is only one person on this entire bug report who has said this is a "feature" and not a bug (Lous1935@teleworm.us), they were last on this bug in 2015, and they are listed as "account disabled".

If there is actually any designer or dev behind the scenes who is opposing fixing this, can you say so, or otherwise can someone from the Nautilus dev. team state that is definitely a bug and there is an intention to fix it at some point? André/Mattias maybe?

And can someone address Daniel's efforts above as well since he's gone to the effort of finding the issue and proposing a fix?

I'd also like to point out that this is a privacy/security issue, as opening a file in the GTK file chooser can result in the immediate sending of that file to a second party (e.g. in an instant messaging/collaboration web app or app, cloud file exchange site etc.), so with this bug the user can end up sending the wrong and potentially sensitive file to someone else.

Additionally this can cause in-application problems for example unintentionally opening a large binary file (e.g. video file) in a text editor, causing it to hang.

Just the non-selection of the first item when opening a folder would be enough to fix this, as Daniel has said.

(In reply to Stephen from comment #25)
> Just the non-selection of the first item when opening a folder would be
> enough to fix this, as Daniel has said.

Having said that, to me this presupposes a rationale for why it's good to have a single click on a selected item open it, rather than just making users double-click as everywhere else. Without such a rationale, this would mitigate the worst facet of the problem but not explain the inconsistent design. Currently, the only benefit would be that one could 'double-click' slower, i.e. easier - but this introduced an inconsistency where the apparent double-click response of the FileChooser would have different settings/behaviour than real double-clicks everywhere else.

My preference still goes to just restoring normal click handling, and my finger is always poised on a big green 'git push' button, if only someone gave the OK...

> There is only one person on this entire bug report who has said this is
> a "feature" and not a bug (Lous1935@teleworm.us)

...and that person is neither a designer or a developer. I assume his bugzilla account later got suspended by bugzilla admins who must have considered his flaming counterproductive too ;)


> [...] any designer or dev behind the scenes who is opposing fixing this [...]

I don't think anybody is opposed to fixing this, I just suppose that Matthias hasn't had time to tackle this one, or maybe it's somehow harder to fix than it sounds.

I suspect that just reverting the commit wouldn't be his preferred solution, I think he might rather be interested in a patch that solves the new bug while preserving the intent of the original commit.

I would like also ask you to fix this annoying bug. This is a blocker for me to upgrade to Debian Stretch (I am using Xfce).

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

Note that the new duplicate above represents a distinct loss of functionality, not just an inconvenient and unexpected behaviour. I guess the workaround is to select another item first, but isn't that rubbish?

I don't know whether they build with the commit reverted, but Ubuntu (up to 17.10 daily builds till now) doesn't have this problem. The file chooser on Ubuntu/Ubuntu GNOME has consistent double-click behaviour.

A quick look at their package shows that Ubuntu patch this away with the patch named ubuntu_fileselector_behaviour.patch


# Description: revert "single click to browser selected items" behaviour
# which was introduced in 3.18, it's confusing to users and was added without
# rational. The issue has been reported upstream but didn't get traction
#
# Ubuntu: https://launchpad.net/bugs/1519778
# Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=758649
Index: gtk+3.0-3.18.7/gtk/gtkfilechooserwidget.c
===================================================================
--- gtk+3.0-3.18.7.orig/gtk/gtkfilechooserwidget.c
+++ gtk+3.0-3.18.7/gtk/gtkfilechooserwidget.c
@@ -2401,7 +2401,10 @@ list_button_press_event_cb (GtkWidget
                    gdk_device_get_source (device) == GDK_SOURCE_TOUCHSCREEN;
 
   get_selection_modifiers (widget, event, &modify, &extend);
-  if (!is_touchscreen &&
+  /* Ubuntu, disable the new behaviour of opening sometime on single click
+     it's confusing for users and the change had no rational
+     https://launchpad.net/bugs/1519778 */
+  if (FALSE && !is_touchscreen &&
       !modify && !extend &&
       event->type == GDK_BUTTON_PRESS &&
       event->button == GDK_BUTTON_PRIMARY &&


So more evidence, as if any were needed, that no one actually likes this.

Couldn't that patched itself be adopted for master, or is there still a rationale required for this?

Those are two distinct questions, not an either-or.

Applying that patch would be a bad way to do it, since it just hacks an if condition to always be FALSE. That's convenient for distro packagers but obviously not something that should go into the upstream codebase; it's messy and would leave dead code lying around with no purpose.

You already talked about reverting a commit, and the responsible commit has already been identified, so that would be the proper way to fix this... save for enhancing the current behaviour to work better, but IMHO there's no real point, at least not without a design rationale.

Well, there are your own reports in comment #18 and comment #19 but those suggestions have still not been incorporated, whereas https://bugzilla.gnome.org/show_bug.cgi?id=121113#c98 seems to abandon Nautilus's preferences altogether. In any case, I think there is a small but important difference between what is chosen in Nautilus and what happens in the file chooser - Nautilus is the default GNOME file manager, but the GTK file chooser is not (so closely) tied to GNOME. It is used in, e.g., Xfce, and even GTK apps on non-GTK platforms. For example, it behaves inconsistently (compared to the standard Qt chooser) on Firefox on a Fedora KDE Plasma desktop. To that end, it's effectively an independent or a semi-independent application in its own right, not tied to Nautilus.

Also, isn't long-pressing an item the traditionally expected method of "selecting" items in touchscreen environments? That, I think, should not be forcefully hammered into a non-touchscreen set-up, since the methods of interaction with the GUI are different (you usually have a secondary input source - the pointer/keyboard - on the latter, whereas you usually use your primary input source - your finger(s) - on the former). What you say - that a downstream patch (and a hack at that) is hardly optimal for upstream - is true, but then wouldn't it be better to choose the default "click" behaviour based on whether the input device is a touch screen (revert to traditional non-touchscreen behaviour if not)?

On KDE, this whole business is handled in a separate section altogether - System Settings, Input Devices, Mouse, Icons. That may be worth considering as a source of ideas for an alternative option.

(In reply to Saurav Sengupta from comment #35)
> What you say - that
> a downstream patch (and a hack at that) is hardly optimal for upstream - is
> true, but then wouldn't it be better to choose the default "click" behaviour
> based on whether the input device is a touch screen (revert to traditional
> non-touchscreen behaviour if not)?

I did once wonder whether the !is_touchscreen condition in the offending section is inverted from what it should be, i.e. whether the 'lazy double click' behaviour under discussion was only intended to manifest on touch screens as a way of avoiding the requirement to double-tap in case that's difficult on some screens.

I presume that is of course not the case, and it is intended only to work on NON-touchscreen devices, but it's harder to imagine a rationale for this directionality, and imagining is about all we can do since it wasn't explained why is_touchscreen is checked one way or the other.

(In reply to Daniel Boles from comment #36)

> ... imagining is about all we can do since it wasn't
> explained why is_touchscreen is checked one way or the other.

That's just it. Why check it if the aim is to have the same behaviour for both? (The fact that this "same behaviour" breaks conventional interaction is indeed what led to this rigmarole, but then I'm just assuming that "same behaviour" was what was intended, and maybe it wasn't.) Is there any explanatory comment anywhere stating why this change was made in the first place (GTK 3.18?) so that we may at least have an idea of the reason(s) behind it?

Here is a possibility (merely; I'm not much of an artist to come up with beautiful mock-ups): -

0. Create a separate section to handle click-and-choose behaviour (as in KDE).

1. A touch screen is detected
  1a. You seem to be using a touch screen device. How would you like to interact with files, folders, and other similar objects?
    1a1. Single-tap to open files and folders. Long-press (press and hold) to select (highlight)/de-select files and folders.
    1a2. Double-tap to open files and folders. Single-tap (or use Ctrl/Shift) to select (highlight)/de-select files and folders.

2. A traditional (non-touchscreen) device is detected
  2a. You seem to be using a traditional, non-touchscreen device. How would you like to interact with files, folders, and other similar objects?
    2a1. Double-click to open files and folders. Single-click (or use Ctrl/Shift) to select (highlight)/de-select files and folders.
    2a2. Single-click to open files and folders. Long-press (press and hold) to select (highlight)/de-select files and folders, or (like KDE), click a special selection/de-selection icon to select/de-select items, or use the traditional Ctrl/Shift keys to do so.

3. Provide a place to test your settings.

Some variations on this could doubtless be thought of by the developers here. Of course, this would need to be invoked every time a secondary input device is connected/disconnected, and/or it could remember the previous settings and make them easily accessible to be altered. This is just my two cents, and I appreciate the difficulty of implementing all this in a framework that may not yet have the optimal facilities for implementing something such as this. There is also the added burden of making Qt, etc., behave in a way consistent with this scheme. I personally feel that consistency across cross-desktop technologies is not as close to the horizon as we may wish it to be.

It is more difficult than that: I have a ThinkPad X220 Tablet where I can switch between the input devices at will. So either one makes this consistent for mouse behavior and then I know that the touch screen will not work as on Android. Or one has two different behaviors parallel to each other and applications handle clicks from different input devices differently (like Xournal can do this).

Any such setting should be implemented at the DE/OS level, not in GTK+ itself, so I think that's out of scope here, and it's not going to be easy anyway as you said

For as long as GTK+ implements its own behaviour, I would say that the aim of this bug is to have it implement a behaviour that does not frustrate nearly all users.

Being consistent with other toolkits/OSs/etc is even further out of scope, I think, despite being a nice idea... That's something that again needs a higher-level framework than GTK+ to manage, and it's also something the GNOME designers may not be overly concerned about. For instance, some other shared settings are maintained at the Nautilus level, which is not much use for people using GTK+ and its FileChooser widgets on any DE/OS lacking that app. Shared conventions are nice but I imagine will always take a backseat to the GNOME design plan.

That said, I agree that ultimately GTK+ would probe some higher-level settings mechanism to achieve the desired behaviour per user/device, but until we reach that utopia, I think the focus here should be to get an agreeable local default.

> 
That said, I agree that ultimately GTK+ would probe some higher-level settings mechanism to achieve the desired behaviour per user/device, but until we reach that utopia, I think the focus here should be to get an agreeable local default.

I completely agree that it's important to discuss and think about a proper long-term solution to this. However, thinking short-term for the next minor release, can't we just revert the comment to provide current users with a better experience?

Most users have no idea about the under-the-hood problem and needed discussion but just seek for something that can be as easy as reverting the commit. 

So, please, don't make it more complicated than it is for the normal user...

Thanks!

I just expressed my frustration with the lifetime of this bug to a colleague. He had experienced this behavior on Arch Linux as well and was irritated by it, but not enough to consider it a bug. I presume that there are many users who are irritated by the current behavior.

Can we please stop with the pointless "+1" comments that add nothing? This is not a popularity contest. This is the last warning before we start locking down this bug.

Bugzilla is not a forum.

The change was intentional and added in response to the fact that people wanted single click to be the default, instead of double clicking everywhere.

We may consider reverting this if an only if we have an alternative that doesn't make people who *want* single clicking to be the default. And, before you say that: settings are not a solution.

I did not understand the file chooser behavior until read this bug report.
Single click to selected items and double click to not selected items is confuse to me as end user.
I think double click to both selected and not selected items is a better behavior.
Single click is used to just select some item, like on nautilus.

Emmanuele, you are the first developer in the history of this entire bug to say anything in support of the current behaviour, and only the second overall (the other user disappeared/was banned 2 years ago).

I am not surprised *at all" at the "pointless +1 comments", since there has been total silence on this from any devs in support of existing, extremely frustrating behaviour until today.

This is *not* "single click by default" - opening *anything* other than the *first* item in a folder is double-click. If you want to accurately describe current behaviour, it is "click to select, click again to open", compounded horribly by auto-selection of the first item in any opened folder (as described more than once above).

Does this happen on *any* other operating system?? An *actual* default "single-click to open" would be far, far less confusing.

If you are indeed defending this described behaviour, can you explain how it and other described behaviours resulting from this "feature" are not utterly, utterly confusing for the average user?

And to answer your "if and only if" stance - just detect the user's default file manager, and at the *very* least follow the (already existent) Nautilus setting if that's what the user is using. Optional additional behaviour mimicry could be implemented for e.g. whatever Dolphin file manager is set to do (for KDE users) etc. But *even* for those users, just following Nautilus in that case would allow other DE/file manager users to alter the GTK chooser's behaviour via the existing Nautilus dconf/gsettings key.

And to re-iterate, meanwhile, the GTK chooser should do *one or the other* - single-click everywhere, or double-click everywhere, not "single-click + infinite delay + single-click".

(In reply to Emmanuele Bassi (:ebassi) from comment #43)
> We may consider reverting this if an only if we have an alternative that
> doesn't make people who *want* single clicking to be the default.

*Who* does want single-clicking to be the default (apart from the person who said as much here long ago)? (Just asking for citing, not trying to prove a point :) )

> The change was intentional and added in response to the fact that people
> wanted single click to be the default, instead of double clicking everywhere.

As I asked in comment #37, can you please provide a reference for this?

I noticed today that, for whatever reason, GTK+ 4 has broken this single-click-activates-selected-item 'functionality', meaning that GTK+ 4 has accidentally unbroken the FileChooser...


At the risk of annoying someone, I would echo the above queries. I don't get the impression that more users were asking for single click ability, than those who are lamenting it now that it's a forced default.

If your stance is that you don't want to turn it back until you find a proper way to do so, then surely that same standard should've been applied to what we have now? It does not seem proper and blocks existing functionality, requiring ugly workarounds like e.g. moving the selection to something else before we can drag a desired item to the bookmark list.

I don't want to turn this into a forum, but a link to the previous discussions where everyone expressed their desire for that behaviour would do a lot to quieten down this thread. Evidently, we're all just bad at search and can't find it! So, please, help us out.

> *Who* does want single-clicking to be the default
> (apart from the person who said as much here long ago)?

I do, among other less involved users (like, every single very non-technical person I've encountered in my tech support experience throughout the years... who will not be commenting on Bugzilla). I am the original reporter, and although bugzilla makes me appear as "developer" I am not a *GTK* developer, just a GTK user, and I do think that double-click is unnecessarily complicated and error-prone for non-computer-savvy people (and those with motor problems), and I do agree that single click is a good approach... *if* it is implemented correctly.

So, as I hinted at in the very first comment/description of this bug report, the point here is to fix the unintentional implementation bug and make single click "perfect" and we can all go home happy.

Reverting the whole implementation of everything just because there is _one_ bug is not the proper way to move things forwards, it is just hiding the problem under the rug. The proper way is to fix the damned bug, not throw everything else out of the window and go back in time. If folks here (and downstream) would redirect the energy spent asking for "commit reversal" into providing a patch to fix the resulting bug, I think this bug report would be solved already. So please, channel your energy in this direction instead.

Any solution that tries to make the file chooser act like normal single-click or double-click is going to alienate people who prefer the other method of selection. Nautilus has an option to choose single- or double-click, but I don't know of any way to do that for GTK itself.

So, right now, the bug is that the current behavior acts like neither double-click nor single-click, and instead does a weird hybrid, where it's single-click if the item is already selected. However, unless there's a commit that lets you choose your preferred click style, we're very quickly going to get another bug report about the file chooser.

> If folks here (and downstream) would redirect the energy spent asking for "commit reversal" into providing a patch to fix the resulting bug, I think this bug report would be solved already. So please, channel your energy in this direction instead.

Reverting the commit would also fix this bug. Yes, this will remove the single-click hack, but since I don't care about that, I don't see why I should care? If YOU want single-click behaviour, why don't you spend YOUR energy and provide a proper patch?

General request: Please do follow https://wiki.gnome.org/Foundation/CodeOfConduct (criticize ideas, not people) and keep the discussion civil.

(In reply to Jan Niklas Hasse from comment #50)
> Reverting the commit would also fix this bug. Yes, this will remove the
> single-click hack, but since I don't care about that, I don't see why I
> should care? If YOU want single-click behaviour, why don't you spend YOUR
> energy and provide a proper patch?

If you read comment 48 you could see that they are not a GTK developer and that the support for single-click behavior is based on their support experience.
Hence comment 50 does not bring the discussion any closer to resolution.

How about reverting the commit as a short-term fix and then having a mid-term or long-term discussion about the issue of *consistent* single-click or double-click? Reverting the commit could be implemented quickly and would only remove single-click in this one inconsistent situation.

The commit could be re-applied in a feature branch where some single-click behavior is developed in a consistent fashion and only shipped when it is ready. Alternatively this feature could be added into the mainline directly but with a configuration option in order to avoid a long-running feature branch.

(In reply to Andrew Toskin from comment #49)
> However, unless there's a
> commit that lets you choose your preferred click style, we're very quickly
> going to get another bug report about the file chooser.

There are already four duplicates of this bug, so if nothing is done, more reports of this bug will come in.

(In reply to Jean-François Fortin Tam from comment #48)
> If folks here (and
> downstream) would redirect the energy spent asking for "commit reversal"
> into providing a patch to fix the resulting bug, I think this bug report
> would be solved already.

When I develop a feature at work and it breaks something, it will not be merged into the mainline. And if it has already been merged into mainline, we will try to un-merge it and re-merge it when it is done. There is no need to lose all the work that was put into this change here, it just seems to be too early for it to be in mainline.

So why do we have to keep this feature which is only half-way implemented until something better comes along? Why can't we just go back for the moment, make a decision on a way to go forward and merge it when it is ready to be merged?

Since this bug is open for almost two years, I'd assume that it will still take quite a while until it is resolved for good. Leaving the file chooser in this inconsistent state for years seemed to done nothing for this bug, so I'd claim there would not have been any damage done if two years ago it had been reverted and replaced by something matured.

I think that comment #48 and comment #49 both make valid points. Single-/double-click is really a user's preference, and something that should be applicable across the toolkit (GTK+) or desktop. Perhaps a solution could be to have the click style configurable using gsettings/dconf, and GNOME could have a settings panel for it, just as KDE does. People not using GNOME could still configure it using dconf.

As pointed out in my previous comment this could be picked up from the existing Nautilus pref.

Also +1 for Martin's comment 53 ;)

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

Created attachment 357615 [details] [review]
filechooserwiget: fix corner case on click activation of first row

    In two consecutive clicks (double click) ignore the second click when
    it is over the selected first row, because otherwise that row is
    activated unintentionally (the user was only expecting the activation
    of the previous row, the one he double clicked).
    
    https://bugzilla.gnome.org/show_bug.cgi?id=758065


This patch fixes the unwanted activation of first row without affecting current click policy of filechooser.

Feedback welcome :-).

Instead of DOUBLE_CLICK_TIME you could use:

  GtkSettings* settings = gtk_settings_get_for_screen(gtk_widget_get_screen(GTK_WIDGET(widget)));
  gint double_click_time = 0;
  g_object_get(G_OBJECT(settings),
               "gtk-double-click-time",
               &double_click_time,
               NULL);

The default value is 400.

(In reply to Nelson Benitez from comment #57)

Hi Nelson, first of all, it would definitely be great to have IMO the biggest issue with the current behaviour fixed, and your effort towards that is most definitely appreciated :)

But even if this fix gets applied, unless I'm wrong or there's something very different about my system, won't the overall behaviour introduced by the original change still make very little sense? It will still be neither single-click nor double-click, instead it will be dependent on whether the item is selected (e.g. an item that was selected 10 seconds ago, and then is clicked, will be opened).

The chooser should instead behave in one of two ways:

* single-click *always* opens, OR
* single-click *always* selects; double-click opens; single-click, then a delay then single click again on the same item, results in a select, then a no-op.

In other words, "without affecting current click policy" is actually not a desirable fix attribute - the current click behaviour is just flat-out wrong.

The approach of the fix seems to me a bit like stacking workarounds on top of bugs, instead of getting rid of the bugs themselves.

Emmanuele, as you have commented on this bug in support of the current state of things (in terms of asserting "should not revert the change" at least), can you please respond to my response in this comment, as well as everyone else's comments referring to the fact that the current behaviour is neither consistent nor actually single-click at all?

(In reply to Nelson Benitez from comment #57)
> Created attachment 357615 [details] [review] [review]
> filechooserwiget: fix corner case on click activation of first row
> 
>     In two consecutive clicks (double click) ignore the second click when
>     it is over the selected first row, because otherwise that row is
>     activated unintentionally (the user was only expecting the activation
>     of the previous row, the one he double clicked).
>     
>     https://bugzilla.gnome.org/show_bug.cgi?id=758065
> 
> 
> This patch fixes the unwanted activation of first row without affecting
> current click policy of filechooser.
> 
> Feedback welcome :-).

Thanks, the patch works great for me. Could anybody merge it, please? The current state is unusable - I am consistently sending out / uploading files which I don't want to :) I also opened Fedora downstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1487427

After reviewing the commit which changed this behaviour (fb0a13b7f070a14312dafa1e4df6ba03cf33be01), I've come to the conclusion that line 2408 (shown below) is actually inverted. The functionality added makes sense for a touch input device, but not for a regular pointing device.

I think that:
    if (!is_touchscreen &&
should be
    if (is_touchscreen &&

Can anyone with a touchscreen device verify this?

I can confirm that opening a directory on a touch screen requires double tap on a selected one and that it’s not easy at all to do. I am sure however that it was intentional to have current behaviour on non-touch devices, so it’s not just a matter of inverting conditions.

(In reply to William Brockhus from comment #62)
> I think that:
>     if (!is_touchscreen &&
> should be
>     if (is_touchscreen &&

I wondered about that above, too. It would've been good if the code explained why it was doing what it was doing wrt touchscreens.


> Can anyone with a touchscreen device verify this?

You don't need a touchscreen device; you can just run a program with the Inspector, go to the Visual tab, and switch on the Simulate Touchscreen option.

(In reply to William Brockhus from comment #62)
> After reviewing the commit which changed this behaviour
> (fb0a13b7f070a14312dafa1e4df6ba03cf33be01), I've come to the conclusion that
> line 2408 (shown below) is actually inverted. The functionality added makes
> sense for a touch input device, but not for a regular pointing device.
> 
> I think that:
>     if (!is_touchscreen &&
> should be
>     if (is_touchscreen &&
> 
> Can anyone with a touchscreen device verify this?

I think the flag was intentional and not a typo, I think Matthias just wanted to make sure the new approach introduced by the patch didn't affect touchscreen, as touchscreen was not involved in the bug at all.

Comments 123, 126 and 132 of bug 121113 talk specifically about that commit, and touchscreen is never mentioned.

> You don't need a touchscreen device; you can just run a program with the Inspector, go to the Visual tab, and switch on the Simulate Touchscreen option.

I tried running Chrome with the inspector and enabled the simulate touchscreen option. The open file dialog now works as expected with double-clicks opening files/folders and single clicks only selecting, even if the file/folder is already selected (instead of single-clicks opening an already-selected file/folder).

This further leads me to believe this check is inverted.

or alternatively that

(In reply to Nelson Benitez from comment #65)
> I think the flag was intentional and not a typo, I think Matthias just
> wanted to make sure the new approach introduced by the patch didn't affect
> touchscreen, as touchscreen was not involved in the bug at all.
> 
> Comments 123, 126 and 132 of bug 121113 talk specifically about that commit,
> and touchscreen is never mentioned.

(In reply to Alexandre Franke from comment #63)
> I can confirm that opening a directory on a touch screen requires double tap
> on a selected one and that it’s not easy at all to do. I am sure however
> that it was intentional to have current behaviour on non-touch devices, so
> it’s not just a matter of inverting conditions.

I understand and appreciate that the current behaviour on non-touchscreen devices was intentional. Indeed, from reading through bug 121113 that certainly seems to be the case.

However, as you point out, double-tapping on a touchscreen device is not easy; single-tapping on a selected item on touchscreen makes perfect sense (though it really should be single-tap on any item, not just a selected item). Single-tapping with a mouse to open a selected item doesn't follow the normal double-click-to-open default that's used everywhere else in the system (yes, I know this can be configured for Nautilus, but double-click is the default).

Regardless of the intention, it is my opinion that the user could better be served by inverting the behaviour; enabling single-tapping for touchscreen and returning to double-clicking for mouse/touchpad devices.

(In reply to Emmanuele Bassi (:ebassi) from comment #43)
> Can we please stop with the pointless "+1" comments that add nothing? This
> is not a popularity contest.

It gives you an idea of how many people are affected by this change, and how unhappy they are. With 5 duplicates and 32 users in the Cc list, the answer seems to be "a lot" and "very" in this case.

When a commit raises this level of controversy, including many clear explanations of why the new behavior is not desirable (comments by Daniel Boles throughout this bug are particularly constructive and right to the point), the only sane thing to do from a software engineering perspective is to revert it immediately, and then discuss what should be done instead (if anything.) That would be the best way to stop the flood of +1 comments that makes you so angry.

As you did not revert the problematic commit, Ubuntu did, and as much as I hate diverging from upstream, SUSE is going to do the same now.

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

While this obviously has no contractual bearing on anything, I think it's worth noting that in the master branch for GTK+ 4, commit c8a6a1138b4e1772817be661a435dd16941d6445 reverted this 1.5-click behaviour as a way to ease another change. The comment was:

> It is getting in the way of gesture conversion, and didn't
> really make anybody happy anyway.

What I wonder is whether this might have any implications for whether the same reversion will be reconsidered for GTK+ 3?

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

I just created an account for this bug, because this is the most annoying bug I ever encountered with gtk3. Please revert the change. It makes me furious!

[Please read comment 43 before further activity on GNOME Bugzilla. Thanks.]

> Please read comment 43 before further activity on GNOME Bugzilla. Thanks.

Why should we satisfy your wish, when you ignore ours?

Reverted to the previous behavior via https://gitlab.gnome.org/GNOME/gtk/commit/f0d5b9561b83599538f70df80d7b6c7abf1a4d04.

*Thank you.*

Thank you Timm for stepping up and reverting this mess, much appreciated! One of the other devs on this bug with commit rights should have done that a long time ago.

Although I already got reminded that Bugzilla is not a forum, bumping the topic obviously worked and I really appreciate the revert of this confusing feature! Thanks a lot, Timm!

That's not necessarily the case, as this may have been getting discussed prior to that anyway - and besides, let's not set an expectation that people just saying 'I am angry' is a reliable and good way to get changes made. It's not, and it has led to endless noise in mine and many other people's inboxes.

Please, let's just enjoy the revert and finally, silently move on with our lives.

Thank you very much Timm.
Finally that extremely annoying behavior was gome. \o/