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?
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.
BTW, this happens on in any path and does not require any special device or path.
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).
Bug as well confirmed for 1.8.x
Created attachment 8672 workaround This workaround disables the cut/copy/paste accelerators when the main view loses focus.
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.
(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 !
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.
Created attachment 9638 diff Different approach.
This report is actually a duplicate of Bug 4537.
(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)
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!)
(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.
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
(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 !
FYI: second patch misses GTK_IS_WINDOW, because get_toplevel() does not guarantee to return a window.
Will there be a patch for maintenance-versions of Thunar or will there only be one for the latest version?
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
(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,
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 ***
*** Bug 16861 has been marked as a duplicate of this bug. ***