! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Copying address bar text: unintuitive behaviour
Status:
RESOLVED: DUPLICATE

Comments

Description Simon Dedman 2017-06-23 23:39:05 CEST
I find Thunar regularly pastes the full address including a filename when I've deliberately copied a chunk of the address:

Nothing selected in main window, select all address bar;
/media/SamsungA/Documents and Settings/
pastes correctly

picture selected in main window, select all address bar:
/media/SamsungA/Documents and Settings/IMG_6738.JPG
= arguably correct. I copied the address which doesn't include the file but since it's selected in the main window it's appended to the address. Potentially useful. But also means when files are selected unwittingly they get copied by default. (subject of bugrepts: 7298 7242 9797 4537)

picture DEselected, ditto:
/media/SamsungA/Documents and Settings/
= correct, reverts to normal behaviour, doesn't hang onto file address

nothing selected main window, MOST of address selected:
/media/SamsungA/
= correct

picture selected main window, most of address selected:
/media/SamsungA/Documents and Settings/IMG_6738.JPG
= arguably incorrect. The user action of selecting a subsection of the address means they clearly wanted exactly that bit. No ambiguity regarding wanting the address with or without selected files. But this is over-ridden by the occasionally-useful script that appends any selected file. One can manually work around this by first deselecting all files (probably unaware whether one was already selected or not) but then the user would have to take an extra step to make a simple action behave as it intuitively should, so that they DON'T have to take an extra step to do something less common (copy the full address including the file address).

Is there any chance of a tweak to this behaviour? I don't know enough about coding to know whether it's possible to have it copy selected text if said text isn't the full address? Nick said (https://bugzilla.xfce.org/show_bug.cgi?id=7298) changing the default behaviour would affect other focused widgets, but would this be the same if only a chunk of the text was selected?
Comment 1 Ralph W. 2018-03-18 10:19:27 CET
I can confirm this behaviour with Thunar 1.6.14:

Copying the path from the address bar does not work if one or more files are selected.

This works:
-Open thunar, go to address bar (Ctrl+L), select full path (Ctlr+A), copy it with hotkey Ctrl+C to the clipboard
=> path of the folder is copied to clipboard 

However this does not work:
-Open thunar, select on or more files, go to address bar (Ctrl+L), select full path (Ctlr+A), copy it with hotkey Ctrl+C to the clipboard.
=> path of the folder ist not copied. Instead the paths of all selected files are copied.
Comment 2 Ralph W. 2018-03-18 11:36:37 CET
BTW, this happens on in any path and does not require any special device or path.
Comment 3 DarkTrick 2019-01-19 12:36:15 CET
Confirmed Thunar 1.6.15

Workaround with the mouse: rightclick on the selected area, select "copy". This should only copy the selected path.

I think the problem is, that Ctrl+C is does not care about the "actual focus". I think this problem is related to the fact, that even, if the path is getting marked, a previously selected file/folder is still selected (seems like on focus).
Comment 4 alexxcons editbugs 2019-01-19 22:02:28 CET
Bug as well confirmed for 1.8.x
Comment 5 Theo Linkspfeifer editbugs 2019-06-23 23:00:39 CEST
Created attachment 8672 
workaround

This workaround disables the cut/copy/paste accelerators when the main view loses focus.
Comment 6 joestone 2020-03-23 09:47:00 CET
This behaviour is still in 1.8.12
For me it's pretty annoying. Leads sometimes to overwriting of files. (paste of a path - which contains an unexpected filename - into a save dialog e.g. /media/SamsungA/Documents and Settings/IMG_6738.JPG/letter.txt will overwrite the jpg)

The patch from Theo #c5 is only working if Location selector is in Toolbar style. The same is valid for the mouse workaround of #c3. Not working in Patchbar style.
Comment 7 alexxcons editbugs 2020-03-23 10:48:49 CET
(In reply to joestone from comment #6)
> The patch from Theo #c5 is only working if Location selector is in Toolbar
> style. The same is valid for the mouse workaround of #c3. Not working in
> Patchbar style.

I dont have time to work on it currently. A more complete patch would be very welcome !
Comment 8 Theo Linkspfeifer editbugs 2020-03-23 12:20:06 CET
I tested the patch again with git master. It does work for both toolbar styles, but it can fail sometimes due to the hacky nature of the fix.
Comment 9 Theo Linkspfeifer editbugs 2020-03-24 22:11:28 CET
Created attachment 9638 
diff

Different approach.
Comment 10 Theo Linkspfeifer editbugs 2020-03-26 13:57:18 CET
This report is actually a duplicate of Bug 4537.
Comment 11 alexxcons editbugs 2020-04-06 10:58:33 CEST
(In reply to Theo Linkspfeifer from comment #9)
> Created attachment 9638 
> diff
> 
> Different approach.
Nice! The general approach is fine for me, though for thunar master I will first finish merging of https://github.com/alexxcons/thunar/tree/ReplaceGtkAction2 in order to keep rebase simple .... the related methods all got moved to thunar-launcher.c and the code inside is slightly different. However we already can fix thunar-1.8.x

(In reply to joestone from comment #6)
> This behaviour is still in 1.8.12
> For me it's pretty annoying. Leads sometimes to overwriting of files. (paste
> of a path - which contains an unexpected filename - into a save dialog e.g.
> /media/SamsungA/Documents and Settings/IMG_6738.JPG/letter.txt will
> overwrite the jpg)
I dont get that use-case ... I create 2 files, "test1" and "test2", they contain the strings "test2" and "test2". Than I paste  /path/to/test1/test2 into the pathbar ?  For me nothing happens .. both files still contain the correct strings. I guess I just dont get that usecase.
( Related to the modifications in thunar_standard_view_action_paste)
Comment 12 Simon Dedman 2020-04-06 18:29:58 CEST
I think Joe means he's trying to save letter.txt into /media/SamsungA/Documents and Settings/ but selecting the address bar also selected the jpg file. When he pasted the clipboard into the txt file save dialog box, it included the jpg extension, and I presume saved the txt as jpb, ignoring /letter.txt since .jpg is the first legitimate extension the save dialog found in the string?

(I might be completely wrong here!)
Comment 13 alexxcons editbugs 2020-04-06 22:42:22 CEST
(In reply to Simon Dedman from comment #12)
> I think Joe means he's trying to save letter.txt into
> /media/SamsungA/Documents and Settings/ but selecting the address bar also
> selected the jpg file. When he pasted the clipboard into the txt file save
> dialog box, it included the jpg extension, and I presume saved the txt as
> jpb, ignoring /letter.txt since .jpg is the first legitimate extension the
> save dialog found in the string?
> 
> (I might be completely wrong here!)
Now I got it  :D , thanks  alot !

Ok, now I as well understood the purpose of Theo's changes in "thunar_standard_view_action_paste" ..pasting whole files into the address bar will only paste the path now, as it should be.
Comment 14 DarkTrick 2020-04-08 22:45:33 CEST
Summary so far
- First Patch disables the Shortcut on demand
- Second Patch asks within the copy-action: "are you an input field?"

Question here:
The Shortcuts are apparently defined to work within the whole application. I would limit the shortcuts to work only as long as the respective view (view of the files) is selected. Are there any cons about this idea (spec?)?

Analysis result:
GtkActionEntry defines the "<Control>C"-Command to trigger a function. Whenever "<Control>C" is triggered (within 'range'), the function is triggered. 
- If Thunar is freshly fired up, that function will not be triggered.
- After the first selection made within the show-files widget (ThunarStandardView), the function is triggerable
- If a file was selected && focus moves outside the widget => the function is triggered
- If another folder is clicked on the side pane && the openning folder does not contain a file selection => the function is not triggered
Comment 15 alexxcons editbugs 2020-04-09 21:43:45 CEST
(In reply to DarkTrick from comment #14)
> Question here:
> The Shortcuts are apparently defined to work within the whole application. I
> would limit the shortcuts to work only as long as the respective view (view
> of the files) is selected. Are there any cons about this idea (spec?)?

IMO the second patch can be considered ok for patching 1.8.x branch (see comment #11) .. and I think the concept is as well fine for master ( though I would strongly prefer having a fix for the mentioned WIP branch to prevent rebasing trouble) .. see reasoning below.

> Analysis result:
> GtkActionEntry defines the "<Control>C"-Command to trigger a function ...
Check my WIP branch ..  GtkActionEntry will be gone .. here the related bug, if you want to track the process: Bug #16654

XfceGtkActionEntries for copy/paste/cut  are registered in thunar-launcher.c, 
xfce_gtk_accel_group_append is used in order to register the accel_pathes and the related default accelerators:
https://git.xfce.org/xfce/libxfce4ui/tree/libxfce4ui/xfce-gtk-extensions.c#n415

Currently thunar-window registers all the accelerators of the launcher, using window->accel_group (thunar_launcher_append_accelerators) .. that seems to be required in order to display the accelerators on the window-menu.

Theorectially it might be possible to define a different accel_group for the view and for the address bar, and register them for the same accelerator (Note that this would result in two different entries in "~/.config/Thunar/accels.scm")
Afaik splitting the window accel group for that reason would add alot of complexity . I guess it would be beneficial to keep things simple and just do like Theo suggested. Though feel free to prove me wrong ;)

If you like to implement Theo's patch for the WIP branch, that would be very welcome !
Comment 16 DarkTrick 2020-04-22 13:44:54 CEST
FYI: second patch misses GTK_IS_WINDOW, because get_toplevel() does not guarantee to return a window.
Comment 17 DarkTrick 2020-04-23 03:41:48 CEST
Will there be a patch for maintenance-versions of Thunar or will there only be one for the latest version?
Comment 18 DarkTrick 2020-04-23 04:05:41 CEST
Little summary:

Duplicates:
===========
Bug #7242
Bug #7298
Bug #9797

Technically related:
=====================
Bug #4537

Technically Problem description:
==========================================
(A)
In GTK the setting of ActionEntrys and Accelerators is global to the window. That means using those will overwrite any "local" key-behaviour (this is what happens in #4537). - At least, it's this behaviour if you go by the book.

(B)
However, looking at "native" Gtk Widgets, they all have local shortcuts (cf. Ctrl+C for GtkEntry). 
Regarding my research on this topic, the big question is how this is implemented. Information is very scrace here.

(C)
There is one problem left: Menu->Edit->Copy.
This is one item for (currently) two different behaviors: 
1) copy from GtkEntry
2) copy a file
+) Through plug-ins of thunar or future dev, there might be even more.

These behavioural differences have to be handled by one single function.

Evaluation of patch 2:
======================
Works, as long as there is only (C)1) and (C)2). Breaks as soon as we have any more.

Possible Implementation 1:
==========================
The global onCopy/onCut/onPaste-Functions emit a `copy-clipboard` (and vv) signal to the currently focussed widget.

That way implementation of the copy function would be cleanly separated between widgets

Problem: there might be widgets, that don't support this signal. So we have "complex" special cases. 

Possible Implementation 2:
==========================
The global onCopy/onCut/onPaste-Functions send a `Ctrl+C`-Shortcut (and vv) to the currently focussed widget.

Problem: I don't think this is actually possible

Under investigation
===================
Implementation in Nautilus & co
Comment 19 alexxcons editbugs 2020-04-23 10:08:36 CEST
(In reply to DarkTrick from comment #16)
> FYI: second patch misses GTK_IS_WINDOW, because get_toplevel() does not
> guarantee to return a window.

Please feel free to upload an updated patch. Please build it with "git format-patch" if it is considered to be used (a diff is considered to be incomplete)

(In reply to DarkTrick from comment #17)
> Will there be a patch for maintenance-versions of Thunar or will there only
> be one for the latest version?

For the 1.8.x branch and for master.  The one for master should rely on the WIP branch .. e.g. https://github.com/alexxcons/thunar/tree/ReplaceGtkAction41


(In reply to DarkTrick from comment #18)

> Possible Implementation 1:
> ==========================
> The global onCopy/onCut/onPaste-Functions emit a `copy-clipboard` (and vv)
> signal to the currently focussed widget.
> 
> That way implementation of the copy function would be cleanly separated
> between widgets
> 
> Problem: there might be widgets, that don't support this signal. So we have
> "complex" special cases. 
> 
> Possible Implementation 2:
> ==========================
> The global onCopy/onCut/onPaste-Functions send a `Ctrl+C`-Shortcut (and vv)
> to the currently focussed widget.
> 
> Problem: I don't think this is actually possible

Possibly you can register multiple widgets for the same shortcut/accel, and than decide if the concrete widget should be executed by checking its focus state. Did you check what happens when you connect additional widgets to the same accel path ?
Probably thats the method you need:
> gtk_accel_group_connect_by_path

Currently it is used from here:
https://gitlab.xfce.org/xfce/libxfce4ui/-/blob/master/libxfce4ui/xfce-gtk-extensions.c#L439

If that works, you should be able to create XfceGtkActionEntrys for the relevant sub-widgets and call xfce_gtk_accel_group_append with them.

> Under investigation
> ===================
> Implementation in Nautilus & co

Good idea to check how others solve that !
In parallel it may help to ask others .. e.g post a question in a Gtk Forum, on the Gtk IRC channel or on Stack Overflow,
Comment 20 alexxcons editbugs 2020-05-14 10:36:04 CEST
fixed in duplicate, will be released in thunar 1.8.15 and thunar 1.9.0

*** This bug has been marked as a duplicate of bug 4537 ***
Comment 21 e.kleinmentink 2020-05-17 22:45:45 CEST
*** Bug 16861 has been marked as a duplicate of this bug. ***

Bug #13680

Reported by:
Simon Dedman
Reported on: 2017-06-23
Last modified on: 2020-05-17
Duplicates (1):
  • 16861 Thunar does not honor selection for copy to clipboard

People

Assignee:
Xfce Bug Triage
CC List:
10 users

Version

Version:
1.6.11

Attachments

workaround (3.07 KB, patch)
2019-06-23 23:00 CEST , Theo Linkspfeifer
no flags
diff (3.63 KB, patch)
2020-03-24 22:11 CET , Theo Linkspfeifer
no flags

Additional information