GNOME Bugzilla – Bug 774821
Cannot 'touch to open' folder or file in 'Double click' mode
Last modified: 2021-06-18 15:52:25 UTC
Hello all, I prefer the 'double click to open items' approach. My laptop includes a touchscreen (Asus Zenbook 305ca) and I would also like to navigate using my touch screen from time to time. Unfortunately, when the double click mode is enabled, single tap events no longer server to open the file/folder in question. Tapping twice in quick succession has no effect either. I think it might be beneficial to handle touch events separately in these cases. Thanks
As a start, my guess is that The case structure in item_event_callback (line 6045 in nautilus-directory.h) needs to be updated to handle the GdkEventTypes GDK_TOUCH_BEGIN and GDK_TOUCH_END
Upon further investigation, it appears that this happens only in list mode. button_press_callback and button_release_callback in nautilus-list-view.c appear to rely upon GDK_2BUTTON_PRESS events to trigger double click. I can't find any equivalent for touchscreen taps. The quick and dirty solutions to this would be: * Simulate a doubleclick on doubletap with timing (the good news is that it looks like all the infrastructure for this is already there to reject double clicks in single click mode) * Ignore the double click option for tap events Any thoughts on this would be appreciated.
Hey Harshad, Thanks for the report! Definitely we want a better touch experience. I think the right step would be to port the views to widgets, but if we can improve what we have now... that would be nice. You are in the right track, but it needs further investigation. I'm not sure we have double tap events for touch, as you pointed seems to not be the case. Maybe we want that in gtk? So far I think we should not use double tap at all in touch mode, and rather single touch. For that we are trying to merge non-touch and touch paths into a single one that is convenient for both, with the action bar, selection mode, etc. But it needs more though.
Thank you for the feedback Carlos! Upon yet further investigation, I think the event handling differences between the canvas and list views need to be cleaned up. For example, it appears that the canvas view triggers an event on RELEASE while the list view triggers the event on PRESS. PRESS #1 RELEASE #1 PRESS #2 <-- Where the list view triggers the action RELEASE #2 <-- Where the canvas view triggers the action Windows 10 behaves like the list view when double clicking is required, i.e. the trigger event is the second PRESS. However, when a single click (or press) is appropriate, Windows will trigger the event upon RELEASE. I am also in agreement with you regarding not requiring double taps. The guidelines also appear to state this "Double click should not be used, since it is undiscoverable, and translates poorly to touch input." I am going to investigate if there is a simple way to fix this and make it all consistent.
thanks for digging into it! Sounds like a great idea.
So what exactly is our desired behavior here? We need to account for: 1. Opening folder / file 2. (Multi) Selecting folder / file 3. Dragging folder / file 4. Cancelling a drag once it is in progress 5. Opening 'right click' menu for single icon 6. Opening 'right click' menu for multiple selected items Based on what touchscreen-primary platforms seem to do we need: 1. Single tap to open 2. A toolbar checkbox changes behavior of single tap => multiple select 3. A toolbar item equivalent to 'right click' menu that is enabled with the checkbox from #2. 4. Long press opens context menu on single item 5. Drag works as always 6. A well defined location where drags can end for nothing to happen. i.e. a toolbar item or similar named 'cancel' that appears when a drag is initiated. Drags to cancel do nothing. I am in the process of getting 1, 4, and 5 to work properly in both views. It will take significant effort to enable the rest (effort and skill/time that is beyond me). Any thoughts?
Carlos, Here is a minimum patch to enable one touch to activate in canvas mode. It seems to work ok. Could you take a look and let me know if I am on the correct track. This is *not* a formal patch. Just something I threw together to get some feedback. Harshad
Created attachment 340780 [details] [review] Patch to add one touch select in canvas mode Forgot to attach
Hey Harshad, thanks a lot for the patch! I didn't think deeply of what we want, I was trying now touch experience of Nautilus and realized the double click on touch actually work. So if I understood correctly, what you want is double click for mouse and single click for touch? However, how would you select in that case? I though the problem was that double click was not working at all in Nautilus for touch. Still we probably want to move to single tap for opening and a selection mode for selection (with rubberband support of course), but that is a general change, not only for touch. So let's wait for more discussion about this with designers and we can decide what to do.
Hi Carlos, Yes, double touch to select already works in Nautilus in the canvas mode. This appears to be because the canvas does not register to intercept touch events and so it receives each touch as a click. The _list_ mode on the other hand *is* registerd to receive touch events. Unfortunately, it does not process them correctly and so in the _list_ mode, double tap to select does not work. Writing a patch to fix (just) this should be easy enough. I'll probably crank one out this evening. I completely agree with you on needing to sit down (the designers) and come up with a proper design for nautilus/touch. What would be the best way to communicate my thoughts on this to the design team? Harshad
Created attachment 340867 [details] [review] Patch to enable touch -> click in list mode Here is my patch to enable touch in double click + list mode. This is a (in my opinion, ugly) hack. It works by making a touch event look like a click event. Shift-touch to multi select also works. Ctrl-touch does not yet. If I were your target audience, I would be satisfied with this for now :)
Actually, it appears ctrl-touch works fine too :).
Review of attachment 340867 [details] [review]: Hey, thanks for the patch. I'm looking into it, where do you see that we are connected to touch events in list view? I cannot see that code in current master. Also, I think gtktreeview should interpret double touch tap as double click automatically no?
Apologies for the delay in getting back... > where do you see that we are connected to touch events in list view? > I cannot see that code in current master. > Also, I think gtktreeview should interpret double touch tap as double click automatically no Based on what I have been able to determine (guess, actually) the difference between the canvas arises because the eel-canvas (which canvas is based on) explicitly calls gdk_window_set_events. See line 2501 in eel-canvas.c. The GDK_TOUCH_MASK (https://developer.gnome.org/gdk3/stable/gdk3-Events.html#GdkEventMask) is *not* requested. My understanding (guess) is that because of this, touch events are not reported to the canvas as touch events and are instead reported as click events, and everything works properly. The list view (based on GtkGrid iirc) does not call gdk_window_set_events explicitly at all (afaik). My understanding (guess) is that because of this, all valid possible events are passed to it in their native form and touch events are not reported as click events. My patch is a hack that 1. registers a handler for touch events 2. Emits fake click events in the proper manner (with the proper sequence as explained in the struct GdkEventButton section in https://developer.gnome.org/gdk3/stable/gdk3-Event-Structures.html) I hope I made sense :)
Good points, I will look into it, thanks for digging
Review of attachment 340867 [details] [review]: Hey, sorry it took so long, it slipped my eyes. The patch actually does more or less what it should, however can you refactor out the part of the press-callback that are going to be shared between touch and click and call that instead? You shouldn't emulate a gtk+ callback yourself. Also there are some g_message etc around, just details, mostly done!
*** Bug 781457 has been marked as a duplicate of this bug. ***
maybe duplicate https://bugzilla.gnome.org/show_bug.cgi?id=778415
(In reply to Strangiato from comment #18) > maybe duplicate > https://bugzilla.gnome.org/show_bug.cgi?id=778415 Honest question, cannot you mark as duplicate bugs? Feel free to do so if you are kinda confident, we will correct if it's wrong.
(In reply to Carlos Soriano from comment #19) > (In reply to Strangiato from comment #18) > > maybe duplicate > > https://bugzilla.gnome.org/show_bug.cgi?id=778415 > > Honest question, cannot you mark as duplicate bugs? No. "Mark as duplicate" is not available to me.
(In reply to Strangiato from comment #18) > maybe duplicate > https://bugzilla.gnome.org/show_bug.cgi?id=778415 Looks like so. The description is not clear, but the reporter did not answer my questions, so, let's assume it is a duplicate. (In reply to Strangiato from comment #20) > No. "Mark as duplicate" is not available to me. You earned the edit rights now (thanks afranke!). Go ahead and close that duplicate. :)
*** Bug 778415 has been marked as a duplicate of this bug. ***
Reported again on GitLab: https://gitlab.gnome.org/GNOME/nautilus/issues/307
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.