Thunar 1.8.9-1+b1 When a mounted partition folder is clicked on while in tree view, it should remain in focus, but instead the focus jumps down to wherever the mounted device is shown in the side pane. The jumping behavior is very disorienting and disruptive. I'm using Debian 10 with upgraded Thunar 1.8.9-1+b1 from testing/sid, the upgrade was done to fix an even worse form of the jumping around behavior.
Thanks for reporting. To get the problem right, just let me construct an example: 1. Open "Filesystem" --> /home/<user> in the tree view. 2. Click on some Subfolder, e.g. "Pictures" on the right Expected behavior: In the tree-view the "Filesystem" tree just selects the folder "Pictures" Observed behavior: The "home" tree is opened till /home/<user> and the folder "Pictures" is selected there. We are talking about the same problem ?
I suppose it is similar if not the same issue, see below details. In my case I am talking about mounted drives, for example in my /etc/fstab I mount the following drives as follows mount /dev/sda2/ /home/userme/mydrives/drivefolder0 mount /dev/sda2/ /home/userme/mydrives/drivefolder1 mount /dev/sda2/ /home/userme/mydrives/drivefolder2 mount /dev/sda2/ /home/userme/mydrives/drivefolder3 mount /dev/sda2/ /home/userme/mydrives/drivefolder4 (etc) All of the mounted drives show up in the left side pane tree with no apparent way to hide them userme Desktop Trash Network drivefolder0 drivefolder1 drivefolder2 drivefolder3 (etc) File System Note: The mounted drives may be displayed as the partition label since the folder name I use is the same as the partition label. When I navigate to /home/userme/mydrives and click on drivefolder0 (or 1, 2, 3 ...) the expected behavior is for drivefolder0 to be selected. The actual behavior is the view jumps out from /home/userme/mydrives/drivefolder0 and into the left side pane view with drivefolder0 selected. When I look closer at your example, in my case, when I select /home/userme/Desktop, sure enough it jumps out of /home/userme/Desktop and into the left side pane view with Desktop selected, so it does seem like similar behavior to what I am describing. For the mounted drive folders and also for /home/userme/Desktop, when I try to navigate through the subfolders, it will always jump back to the left pane view, and that forces me to always have to browse through the left side pane which is not so great to say the least, especially when I'm trying to do work and organize files across the mounted drives.
As mentioned in the related bug 16474, when a folder has multiple tree path locations, the cursor jump behaviour happens. Examples like 3 paths for Desktop - User > Desktop, Desktop, File System > home > user > Desktop 2 paths for mounted partitions - Windows 7, File System > media > user > Windows 7
I assume that this is caused by thunar_tree_view_get_preferred_toplevel_path(). https://git.xfce.org/xfce/thunar/tree/thunar/thunar-tree-view.c?h=thunar-1.8.12#n2862
Yes, as well would be my assumption. Guess the method should check if there is a cursor, and if yes, return the related toplevel-path.
Created attachment 9614 experimental diff I added a new check which evaluates if a jump should be done based on the path returned by gtk_tree_view_get_cursor().
Created attachment 9616 patch Works fine here, very nice ! > // check if path valid? I think it is save to rely on the tree-nature here / To assume that each node below root has a parent. Not sure if there is a method to validate a path at all ? I moved the logic to free path directly into the innermost "if", so that "keep_path" isnot required. Fine for you like that ?
> // check if path valid? I guess I wanted to check for a NULL pointer afterwards. > I moved the logic to free path directly into the innermost "if", so that "keep_path" isnot required. If the previous checks fail, path should be freed also. Other than that, I thought about making this new block a new function (like thunar_tree_view_get_preferred_toplevel_path() does). Bad idea?
(In reply to Theo Linkspfeifer from comment #8) > > // check if path valid? > I guess I wanted to check for a NULL pointer afterwards. ok .. think not needed here, since according to the doc, "gtk_tree_path_up" only does something if there is a parent. > > I moved the logic to free path directly into the innermost "if", so that "keep_path" isnot required. > If the previous checks fail, path should be freed also. Ok, I missed that one .. so lets rather use your diff as a base than my patch > Other than that, I thought about making this new block a new function (like > thunar_tree_view_get_preferred_toplevel_path() does). Bad idea? Good point ! Think I would just move the code-block to "thunar_tree_view_get_preferred_toplevel_path" .. that function-name already fits the purpose of the code-block.
Created attachment 9620 diff I moved the block there.
.. and you even found a nice way to prevent the extra variable. Well done ! Works fine for me. Lets push it ?
Theo Linkspfeifer referenced this bugreport in commit b0332a19af79da580afebeef537dcb417bf773a8 Use tre-view toplevel path of the cursor, if available, in order to prevent jumping (Bug #16024) https://git.xfce.org/xfce/thunar/commit?id=b0332a19af79da580afebeef537dcb417bf773a8
Theo Linkspfeifer referenced this bugreport in commit 13a09f1ea3de33fc24ca17aecb39fd5b43caa8dd Use tre-view toplevel path of the cursor, if available, in order to prevent jumping (Bug #16024) https://git.xfce.org/xfce/thunar/commit?id=13a09f1ea3de33fc24ca17aecb39fd5b43caa8dd
Pushed to master and 4.14 branch, to be released in 1.8.13 in the next days Thanks alot for the fix Theo !
Theo Linkspfeifer referenced this bugreport in commit 51c499433965217dfa0e36561ff0bf2ea24be703 Move iter initialization (Bug #16024) - Fixes 100%CPU on tree-view in some rare cases https://git.xfce.org/xfce/thunar/commit?id=51c499433965217dfa0e36561ff0bf2ea24be703
Theo Linkspfeifer referenced this bugreport in commit fd30af9b647ad74dafd2f19095858963cb5f9329 Move iter initialization (Bug #16024) - Fixes 100%CPU on tree-view in some rare cases https://git.xfce.org/xfce/thunar/commit?id=fd30af9b647ad74dafd2f19095858963cb5f9329
^^ fix for regression introduced by the first fix ... see details on https://bugzilla.xfce.org/show_bug.cgi?id=15762#c14 and https://bugzilla.xfce.org/show_bug.cgi?id=15762#c15