GNOME Bugzilla – Bug 82884
Tree view focus doesn't follow file view pane
Last modified: 2003-09-18 10:01:20 UTC
In nautilus1, navigation in the file view pane was reflected in the tree view. For instance, if I clicked on a folder in the file view pane, that folder would open in the file view pane and focus would move to that folder in the tree view. In nautilus2, the tree view is unaffected by such a change.
This is a dupe, but i think someone marked that bug fixed, even though this still doesn't seem to work for me...
*** This bug has been marked as a duplicate of 73766 ***
bordoley: This is still a problem in the 5/29 Ximian snapshot I have. All that appears to have been fixed with bug 73766 is that the tree remembers its open state. It is not synchronizing with the view pane.
*** Bug 85744 has been marked as a duplicate of this bug. ***
since this is a parity bug, i'm targeting it at the 2.0.x milestone.
No. At this point, only major/'high' issues are going in in 2.0.x.
ok wasn't aware that was plan. :)
*** Bug 90757 has been marked as a duplicate of this bug. ***
*** Bug 87153 has been marked as a duplicate of this bug. ***
*** Bug 90728 has been marked as a duplicate of this bug. ***
I can't understand why this isn't considered high priority? This is critical functionality for tree users. Tree users, yeah... I never did understand how people got by without using the tree either... if you frequently copy files one day from say /home/you/projects/webstuff/site1/pubhtm/foo/bar/baz/ to /mnt/webserver/webroot/site1/pubhtm/foo/bar/baz/ how do you do it quickly without a tree? Click your way to the source dir, select all, copy files, hit back 9 times!?!, then click through another 8 sub dirs!?!, and hit paste? Then maneuver /all/ the way back to where you were working again? gah! I wish I could get the tree tab to display by default too - every time I launch Nautilous, I have to click on the tree tab, and then manually navigate the tree to home/myusername/ - which get's very repetitive after a while. And even if I do store bookmarks for places, the tree doesn't follow me - and since I use the tree for everything, that makes bookmarks useless as well, cuz you just have to renavigate there in the tree. This functionality is to me, the very core of what makes a file manager. So yeah, I guess what I'm saying is, I'd like to see this bug get a little love. And judging by the number of dup's, I'm not the only one :-) Much Thanks for any consideration.
Let me apologize in advance for making a "me too" comment, but I agree with the above. This bug sticks out like a sore thumb, it should be fixed in the 2.0.x series. Note: sidebar forgetting the open tab is bug 48470.
*** Bug 95837 has been marked as a duplicate of this bug. ***
*** Bug 102376 has been marked as a duplicate of this bug. ***
Commenting dup 102376 of this bug: Hope you saw this occurred in gnome/nautilus 2.1.x in bug 102376, because 82884(this one) relates to gnome 1.1.x !
No, it was initially filed against *Nautilus* 1.1.9, which was (GTK2-based) nautilus2. This has never been a *GNOME* 1.x bug.
AFAIK someome is writing a new tree sidebar, so I guess this will wait until we have that.
*** Bug 108182 has been marked as a duplicate of this bug. ***
Getting rid of GNOMEVER2.0 & GNOMEVER2.1 keywords (those are irrelevant since the GNOMEVER2.2 keyword is set), setting version->2.2.x, and leaving target as 2.2.x. According to the priority guidelines, bugs meriting high priority are ones that: "Can include cosmetic bugs of particularly high visibility, regressions from functionality provided in previous releases, and more minor bugs that are frequently reported.". This satisfies all of those criteria, so I'm marking priority as high. That's my best guess--if someone has a reason why it shouldn't be, though, feel free to mark it back down.
*** Bug 110305 has been marked as a duplicate of this bug. ***
I've tried to implement the desired - and really necessary - functionality in the tree view and it works - at least on my machine. I haven't known the source of Nautilus until today, so it's possible that I didn't code it very well but it works not that bad for me. The patch is made for and tested with Nautilus 2.3.3 and it also applies to Nautilus 2.2.4 but untested.
Created attachment 17248 [details] [review] Patch that allows the tree view to follow directory changes
I've just noticed that my patch doesn't work correctly when there is more than one window open. I corrected it, hopefully it works now right in all cases.
Created attachment 17250 [details] [review] Updated patch to correct the behaviour if there are multiple windows open
I saw the recent discussion about this on the mailing list archive (i'm not subscribed), and as someone who really wants this, thought I would comment. I agree with Jurg's use case for this where you have two directories distant from each other in the hierarchy. Usually I launch Nautilus, open some set of working directories in my tree, and then switch between those. I will add that, with this functionality, bookmarks become a (very!!) useful feature for tree users. It will also be /really/ nice for the tree to sync to my home dir on startup! Having used Windows Explorer and it's tree for over 15 years now, I'm really used to it's behavior in this regard, which I always took for granted until using Nautilus. I find the Win behavior quite sane, and would urge that it be used as a model for answering useability questions (eww, did i just say that ;). I do not understand why this patch "can cause problems if you're using the tree as drop target, and have to change the directory of the main view"? Is this for people who view files in the tree? (I just use folders) Can't I use the tree or main view (with tree following) to find the folder with my files, select the ones I want in the main panel, then just drag them to any folder in the tree, possibly requiring me to scroll the target folder into view? Anyhow, MUCH thanks for your work on this, it's the last major thing the transition from Windows has left me wanting on a daily basis.
This bug should be closed.