This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | [65cat] Last directory not remembered in any directory or file selection dialog | ||
---|---|---|---|
Product: | utilities | Reporter: | wobster <wobster> |
Component: | Open File | Assignee: | Victor Vasilyev <vvg> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jglick, olangr, pchytil |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 197063 | ||
Bug Blocks: |
Description
wobster
2008-09-05 15:02:11 UTC
lowering priority, reassigning to utilities/openfile, please feel free to reassign further, I'm unsure about the correct component, thanks There are many uses of the file chooser in the IDE and each use may define a different behaviour as regards the initial directory in the file chooser. For example, action File > Open File... uses the parent directory of the currently selected file as the initial directory for the file chooser, or "My Documents", if there is no file selected. Other actions may use a different algorithm. So there no unified behaviour. What action or step of actions lead to the file chooser that always starts in "My Documents"? I'll start listing examples where the directory chooser algorithm is starting in a non-helpful location. It is my contention that starting in the last directory chosen will be the most optimum 95% of the time. While on Linux this morning, I decided to try out Grails. I had to choose "Grails Home" and the "Groovy Documentation". I've put grails in /mnt/c/java/grails and the groovy docs in /mnt/c/java/groovy/docs. In both instances, the directory chooser put me in my /home/myhome directory forcing me to navigate twice to the /mnt/c/java directory. Remembering my last directory would have allowed a quick selection up and over one directory. I have also noticed on Windows that sometimes it remembers my last chosen directory, but you have to use the "up directory" button to navigate. Trying to navigate from the directory list pull down leads to the Desktop where you have to navigate to My Computer and then to the drives. The Windows directory dialog is quite non-intuitive and non-optimal from a navigation standpoint. From my point of view this is not a bug, openfile dialog works, issue type should be set to ENHANCEMENT. I found old closed enhancement about "last dir" problem so we can continue discussion there. Feel free to reopen that enhancement. You can also fire a new bug on Groovy module. Maybe developers will add some "smart" code to guess initial directory for Groovy Doc or something like that. But, you know, you have to set these paths only once. *** This issue has been marked as a duplicate of 58448 *** This is still a problem in NetBeans 6.8. For instance, every time I add a new source to the project, it puts me back in the original project directory. Just make the default the last directory chosen rather than some notion of a home directory which is probably not where the user wants to be most of the time or add an option to do this if there is a 50/50 split on desires. Such behavior was intentionally implemented http://hg.netbeans.org/main/rev/68a879c9855f#l1.67 (In reply to comment #6) > Such behavior was intentionally implemented > http://hg.netbeans.org/main/rev/68a879c9855f#l1.67 Come on guys, do you really truly believe that looking in the home directory is better than looking at the last directory chosen? I dare you to survey the netbeans user list to determine what behavior most developers would like. I submit that this code should be restored and the other reverted. - /** Generated serial version UID. */ 1.33 - static final long serialVersionUID = -3424129228987962529L; 1.34 - 1.35 - /** stores the last current directory of the file chooser */ 1.36 - private static File currDir; 1.37 - 1.38 - wobster, thanks for your inflexible opinion against this issue. I agree that the requested behavior most near to the users expectation, and it is more understandable than implemented heuristic algorithm. So, I've implemented a behavior that is more close to the default behavior of the Swing's file chooser. See http://hg.netbeans.org/main/file/1891f784fd2e/utilities/src/org/netbeans/modules/openfile/OpenFileAction.java#l140 Fixed in the main trunk http://hg.netbeans.org/main/rev/1891f784fd2e Sorry for the grumpy response, but I've grown tired of arguing with the NetBeans developers about issues of consistency and expected behavior - the two rules of programming and GUI design. Thanks for acknowledging the problem and even fixing it! I do think that there should be a forum for usability issues and perhaps a user survey sent out when there is contention about behavior. (It still annoys me that I can't commit a file or a compile a file that I'm editing using right click for instance. I've had a long (years) battle about that capability as well with no solution in sight. There is an outstanding bug on that issue.) Another approach that I've used during my GUI development when there is an evenly divided opinion on behavior is to just add a preference so that the user can decide which behavior they'd like. You end up with lots of preferences, but at least everybody is happy! Thanks again! IMHO this is a regression in usability. With 68a879c9855f, if I am working on some source file, I can quickly open any nearby file (such as Bundle.properties) using File > Open, since the containing directory is preselected. Now (1891f784fd2e) I am dumped in some irrelevant directory far away from where I was working. C-S-1 is an awkward substitute. Anyway the default Swing filechooser is not suited to productive work. The Quick File Chooser module (available on AU), among other things, lets you just use the Up key to cycle through recent locations (without any special cooperation from the IDE). I strongly agree with Jesse's latest comment. Now I'm extracting the OpenFileAction.class for 6.8 and re-jaring it into 6.9's module file. Open from the current editing file directory is very useful for me. The 6.9+ behavior is a constant source of irritation for me and apparently others, so I am opening a fresh issue to be able to return to the 6.8 behavior. (In reply to comment #12) > The 6.9+ behavior is a constant source of irritation for me and apparently > others, so I am opening a fresh issue to be able to return to the 6.8 behavior. Why not make this an option? It is a user preference really. Or possibly use the currently selected directory, but if there is not directory selected (which was the case I had), use the last used directory. Nobody is surprised by using the last used directory, but being dumped in "My Documents" is truly irritating especially if you have a deep directory structure to re-navigate to. (In reply to comment #13) Never mind. I missed the new bug you opened. Looks like that is exactly what you did! > (In reply to comment #12) > > The 6.9+ behavior is a constant source of irritation for me and apparently > > others, so I am opening a fresh issue to be able to return to the 6.8 behavior. > > Why not make this an option? It is a user preference really. > > Or possibly use the currently selected directory, but if there is not directory > selected (which was the case I had), use the last used directory. Nobody is > surprised by using the last used directory, but being dumped in "My Documents" > is truly irritating especially if you have a deep directory structure to > re-navigate to. |