GNOME Bugzilla – Bug 754743
Middle click on "Other Locations" doesn't open a new tab
Last modified: 2017-10-01 21:22:09 UTC
A middle click on all sidebar entries opens a new tab except "Other Locations" which opens in the current tab.
I can confirm this bug with Nautilus 3.18.0 on Debian Sid 64 bits
The same happens when selecting "Open in new tab" or "Open in new window" in the context menu. In both cases the current view gets replaced instead of a new tab/window opened.
this is a faulty API from the GtkPlacesSidebar. Will need to pass the GTK_PLACES_OPEN flag on the signal as well...
Created attachment 321837 [details] [review] gtkplacessidebar: add open flags to other locations We weren't using the open flags on the other locations signal, which makes impossible for applications like nautilus to act in the same way that for any other location where the user can choose between opening in the current view, in a new window or in a new tab. Add the signal missing parameter in order to allow it.
Created attachment 321838 [details] [review] window: use open flags for other locations view We weren't checking the open flags from the sidebar when the other locations was clicked. This was due to the sidebar not adding those flags to the signal. In a recent commit gtk+ added the missing flags, so now we can check for those in nautilus and open in the current view, in a tab or in a window accordingly.
Created attachment 321841 [details] [review] gtkplacessidebar: add open flags to other locations We weren't using the open flags on the other locations signal, which makes impossible for applications like nautilus to act in the same way that for any other location where the user can choose between opening in the current view, in a new window or in a new tab. Add the signal missing parameter in order to allow it.
Created attachment 321843 [details] [review] gtkplacessidebar: add open flags to other locations We weren't using the open flags on the other locations signal, which makes impossible for applications like nautilus to act in the same way that for any other location where the user can choose between opening in the current view, in a new window or in a new tab. Add the signal missing parameter in order to allow it.
Review of attachment 321837 [details] [review]: What I am missing in this patch is documentation updates. There should be a note in the signal docs explaining the change ("Since 3.20,...") and there should be a paragraph in the 3.20 section of README.in mentioning the API change as well.
Created attachment 321856 [details] [review] gtkplacessidebar: add open flags to other locations We weren't using the open flags on the other locations signal, which makes impossible for applications like nautilus to act in the same way that for any other location where the user can choose between opening in the current view, in a new window or in a new tab. Add the signal missing parameter in order to allow it.
Applied your comments Mathias. Hope the wording is fine.
Attachment 321856 [details] pushed as 63a204e - gtkplacessidebar: add open flags to other locations
Comment on attachment 321838 [details] [review] window: use open flags for other locations view Attachment 321838 [details] pushed as 5abce34 - window: use open flags for other locations view
What value will this new parameter have now if the signal parameter, or the default signal handler (the vfunc), is called by apps that have been built against the older version of GTK+?
Depends on what the app passes as user data, I'd say. But really, the only reason I allowed this change is because no application other than nautilus is using this API. If an app is found that is broken by this, we'll have to reconsider.
*** Bug 759258 has been marked as a duplicate of this bug. ***
Mathias, I think the problem is that some distributions (afaik Ubuntu will for 16.04) use nautilus 3.14 with gtk+ 3.18, which makes this a problem. I'm not sure what is a good solution for this.
(In reply to Carlos Soriano from comment #16) > Mathias, I think the problem is that some distributions (afaik Ubuntu will > for 16.04) use nautilus 3.14 with gtk+ 3.18, which makes this a problem. Since 3.18 does not have the ABI change, I think you mean "use Nautilus 3.14 with GTK+ 3.20"? > I'm not sure what is a good solution for this. What we do for all these issues: we add a new signal and deprecate the old one.
Alternatively, you can use an "out of band" function that returns the open flags while inside the signal emission chain.
(In reply to Emmanuele Bassi (:ebassi) from comment #17) > (In reply to Carlos Soriano from comment #16) > > Mathias, I think the problem is that some distributions (afaik Ubuntu will > > for 16.04) use nautilus 3.14 with gtk+ 3.18, which makes this a problem. > > Since 3.18 does not have the ABI change, I think you mean "use Nautilus 3.14 > with GTK+ 3.20"? > > > I'm not sure what is a good solution for this. > > What we do for all these issues: we add a new signal and deprecate the old > one. Oh, I was not clear. We broke ABI as well in gtk+ 3.18 with the populate-popup signal. I'm all to create a new signal for the one discussed in this bug report, show-other-locations.
(In reply to Carlos Soriano from comment #16) > Mathias, I think the problem is that some distributions (afaik Ubuntu will > for 16.04) use nautilus 3.14 with gtk+ 3.18, which makes this a problem. > > I'm not sure what is a good solution for this. They have the source, they know how to cherry pick or revert a patch
> What we do for all these issues: we add a new signal and deprecate the old one. Yes, please. Revert the change in GtkPlacesSidebar::show-other-locations, deprecate it, and add a new signal with the required signature. That would simplify for gtkmm, and probably for other language bindings.
Created attachment 322709 [details] [review] Revert "gtkplacessidebar: add open flags to other locations" This reverts commit 63a204e1c5b6c since it broke the API. We will add a new signal instead in an upcomming patch.
Created attachment 322710 [details] [review] gtkplacessidebar: add open flags to other locations We weren't using the open flags on the other locations signal, which makes impossible for applications like nautilus to act in the same way that for any other location where the user can choose between opening in the current view, in a new window or in a new tab. Add a new signal with an open flags parameter and deprecate the other-location signal.
Created attachment 322712 [details] [review] gtkplacessidebar: add new other locations with flags signal We weren't using the open flags on the other locations signal, which makes impossible for applications like nautilus to act in the same way that for any other location where the user can choose between opening in the current view, in a new window or in a new tab. Add a new signal with an open flags parameter and deprecate the other-location signal.
Review of attachment 322709 [details] [review]: ok
Review of attachment 322712 [details] [review]: ok
please also remove the release note about this api break in README.in
(In reply to Matthias Clasen from comment #27) > please also remove the release note about this api break in README.in The first patch that reverts the original one removes this already. Am I missing something?
Attachment 322709 [details] pushed as fec0c4c - Revert "gtkplacessidebar: add open flags to other locations" Attachment 322712 [details] pushed as fdde27e - gtkplacessidebar: add new other locations with flags signal
On my Debian Sid with GNOME 3.26, middle clicking on a an item displayed within the "Other locations" window doesn't open a new tab $ dpkg -s nautilus | grep ^Version Version: 3.26.0-1 Thanks