GNOME Bugzilla – Bug 707679
GtkPlacesSidebar: also open locations when hovered by XDS and text drag targets
Last modified: 2018-04-15 00:37:39 UTC
Hi, filing this bug in 'gtk' as currently there is no 'gtkplacessidebar' bugzilla component. This is about a series of three patches for gtkplacessidebar: - The first adds support to open locations when hovered by XDS drag targets (i.e. when dragging a file from file-roller). - The second adds support to open locations when hovered by text drag targets (i.e. when dragging text from gedit). - The third is a minor patch to more correctly add the uri drag target (by using a gtk function instead of hardcoding it). With these patches nautilus can now change locations in the sidebar when hovered by XDS and text targets, a functionality that was also added recently to its pathbar.
Created attachment 254339 [details] [review] Patch 1/3 GtkPlacesSidebar: support switching locations for XDS drag types
Created attachment 254340 [details] [review] 2/3 GtkPlacesSidebar: support open locations when dragging text
Created attachment 254341 [details] [review] 3/3 GtkPlacesSidebar: use gtk api to add dnd uri targets gtk_target_list_add_uri_target() uses the same atom string as the harcoded one, so it's ok, as seen here: https://git.gnome.org/browse/gtk+/tree/gtk/gtkselection.c#n339
Created attachment 254342 [details] Screencast of nautilus sidebar working with patches applied Shows the patched behaviour, nautilus sidebar switching locations when hovered by a file dragged from file-roller and by some text dragged from gedit.
The patches look ok to me, but I wonder what this does to the file chooser. We probably have no use for xds there.
Ok will commit them then when getting home this afternoon. Yes for the filechooser there's no usefulness right now (if filchooser got more filesystem capabilities it would), anyway I just checked dragging to the filechooser sidebar and indeed switches location but then the drop is no accepted so anything harmful happens. Thanks!
They are now pushed as: commit 588ffa8c3241eff2f8e2d99b911a6bcb539347bd commit 1b839d4b72a2cedb2bb633b5acd57239860693f4 commit 7fa27dff259ad79d5a4364d7eaa6b63150082af3 thanks!
I didn't say 'accepted-commit-now' for a reason. I wanted the filechooser question solved first.
reverted for now
Sorry, I interpreted "The patches look ok to me" as commit.. so.. what exactly is the problem with the filechooser not using XDS? it does not affect it in any way.. and nautilus does use it.. what are you concerned about?
I'm concerned about behavior regressions - we have a bad history of breaking the file chooser, I want to make sure that this works as we want it before we land it. It could be that we just need a boolean ::enable-xds construct property, and have nautilus set that to TRUE.
I've tried all possible usecases and I can't think of a possible regression this could create, in my opinion this is innofensive enough that should go as is, but if you prefer a '::enable-xds' property for this to go in, I can do it without problem.
Review of attachment 254341 [details] [review]: pushed this one
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new