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.
NB4.0 Beta2: If you create a new project on Windows, the default proposed location is under C:\Document and Settings\LOGINNAME instead of My Documents This is bad, and also totally inconsistent with the NetBeans file chooser that has a shortcut to this 'My Documents' but not to the 'home' directory concept which is way too linux or Unix centric. This is from user feedback from a senior (really senior) person within Sun. Same for other project types (web app, and also J2EE projects) Windows regular users are lost... Look and Feel P2 bug, not RFE, need a fix for NetBeans 4.0 FCS. Btw, Creator has already addressed this bug for a good reason. A project is a document and should be stored in th e correct location by default
My Documents are under C:\Documents and Settings\LOGINNAME\My Documents Modulo localization, of course.
Already been considered, tried, rejected. I think because the JVM does not provide this location. Anyway please look at issue #46884 and issue #48643. I don't use Windows so I don't know the details.
I just realize that "My Documents" are normally localized. It can't be hard coded and I doubt there is a java API to get that piece of info. Also imagine Chinese Windows. The pathname can quite possibly contain non-ASCII characters. Can Ant handle them? Can javac and related tools handle them? Can cvs handle them?
Jano et al., please reopen or comment on this issue as you feel appropriate. I am not inclined to make a possibly dangerous change this late in 4.0, however.
I disagree with the wonfix status. The issue is not resolved. I need much more comments in this bug for a wontfix status.
I find it really wrong if those tools don't work with localized path names. It seems to me quite locale unfriendly then. On Chinese Windows, users would most likely create Chinese user names so the user dir doesn't work either. So, I think the question is more about whether we can get to the "My Documents" folder in Java or not. If we can, we should make it the default. Btw, I don't think the user would ever want to put "My Documents" into CVS. He would want to put the *content* of "My Documents" into CVS, which reminds me that having "My Documents\NetBeansProjects" as a default folder for projects is even better, because a (beginner) user can easily use "NetBeansProjects" as a CVS working dir and it should work better than with "My Documents" or any other user dir which contains bunch of CVS unrelated folders. But this is a different topic.
> I find it really wrong if those tools don't work with localized path > names. It seems to me quite locale unfriendly then. please be pragmatic. That's the world we live in. At the same token I'd argue that the IDE should support the case that a java class can be named in chinese, the same for the source filename. If it does not work then it's the violation of JLS, thus P1 bug. > Btw, I don't think the user would ever want to put "My Documents" > into CVS. He would want to put the *content* of "My Documents" into > CVS no he won't but the cvs external command line utility and others may have to take abs path to the sources as an argument. Such abs pathnames then contain non-ascii chars And as Jesse and others have noted, java don't offer api to get the localized version of "My Documents" When we are at it, the other desktops start using something similar to My Documents. I see it on Mac OS X and GNOME 2.6. If we want to be consistent with the native desktop, we should doing it for all. One more thing and I think this is an important one: why we think source codes are documents. I am a *user* and would never consider my sources as documents. Sources are sources, documents are those created by OpenOffice. Am I so special?
jano, please check how MS Visual Studio works in this regard, including putting some non-ascii chars in the pathnames
> please be pragmatic. That's the world we live in. At the same token > I'd argue that the IDE should support the case that a java class can > be named in chinese, the same for the source filename. If it does not > work then it's the violation of JLS, thus P1 bug. These are two different things. The one thing is whether a tool accepts UI standards of hosting OS (like where to put user's files, etc.), the other thing is how a tool defines its syntax and data structures. We should not mix that together. > no he won't but the cvs external command line utility and others may > have to take abs path to the sources as an argument. Such abs > pathnames then contain non-ascii chars It can contain non-ascii chars no matter what we do. But, if it really doesn't work we should warn the user if he tries to put a project into such folder. As mentioned before, the user dir isn't a good default then. > And as Jesse and others have noted, java don't offer api to get the > localized version of "My Documents" Seems like a fair limitation to me, and a requirement for JDK6.0. > When we are at it, the other desktops start using something similar to > My Documents. I see it on Mac OS X and GNOME 2.6. If we want to be > consistent with the native desktop, we should doing it for all. Mac OS X is different. The user dir contains folders like Documents, Music, Pictures, etc. So the user dir is a parent folder for user created files. And Finder provides the user with a shortcut to the user dir folder. On WinXP, the My Documents folder contains "My Pictures" and "My Music", which indicates that "My Documents" should contain user files (a music certainly is not a document, the same for pictures). So, from this point of view Mac OSX user dir = WinXP My Documents. > One more thing and I think this is an important one: why we think > source codes are documents. I am a *user* and would never consider my > sources as documents. Sources are sources, documents are those > created by OpenOffice. Am I so special? Yes, I think you haven't used Windows for quite a long time ;-). As stated above, My Documents is a folder for user created files of any type (music, pictures, sources, etc.) > jano, please check how MS Visual Studio works in this regard, > including putting some non-ascii chars in the pathnames My Documents is the default. I wasn't able to check non-ascii chars, yet.
Will leave to Jano to make concrete and complete recommendations, that can be reliably implemented using existing JDK APIs such as the user.home property, that are safe on different variants of Windows, and which do not introduce *new* problems for users running on localized Windows machines (esp. those using multibyte encodings) - this must be confirmed by QA.
I am not sure if this is a JDK API, but I was able to get to the My Documents folder on Win2000: javax.swing.filechooser.FileSystemView.getFileSystemView().getDefaultDirectory() http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/filechooser/ FileSystemView.html#getDefaultDirectory() This points to the user home on Mac (not sure about other OSes). When I tried to put a project into a folder that contains non-ascii characters the build failed with an exception from Ant. I will attach the exception. So, it seems that Ant doesn't accept non-ascii chars. I suggest following solution: Make the default project location "My Documents" on Windows. If the default location contains non-ascii chars or the user enters a non-ascii chars in the project location (on any OS), show an inline error message and don't allow to continue. If you agree with this solution, I will work on the inline error text with doc writers.
Created attachment 18249 [details] Ant exception when using non-ascii chars in project location. The file is in UNICODE!
> If the default location contains non-ascii chars or the user enters a > non-ascii chars in the project location (on any OS), show an inline > error message and don't allow to continue. if the users picks a different and bad location, then this is the right thing to do. But it would look dumb if we offer the default and *that* default is already bad. We need a fallback default. What should it be? C:\? :-)
Maybe I didn't make this clear before but: Ant *does* accept non-ASCII characters just fine. I have no problem on Linux creating, building, and running a project involving Czech letters in a folder name. This is using UTF-8 locale universally. However particular buggy operating systems - not to name any names - may be using different encodings in different software components, and get confused. Why this is exactly, I don't know; perhaps Ken Frank does, since he wrote some sort of guide on how to reconfigure Asian Windows to make it work in some cases. No idea whether Mac OS X behaves sanely or not. All I know is that Linux with UTF-8 locale has no issues. We cannot currently predict what file names will cause problems on which platforms, and IMHO we should not make any wizard reject a non-ASCII path unless we have a really bulletproof algorithm for determining this information on every platform, which I think is unlikely given the variety of possible filesystems etc. that different OSs can use.
So, I am not sure how to proceed. It seems that the non-ascii chars issue is a different topic from this issue which is: "Default project location on Windows should be in My Documents" I suggest to fix this issue by making "My Documents" the default location on Windows and file a separate issue that should first request to discover and summarize all the issues with path names in localized environments so that we know what localization problems we need to solve. (I don't know who should drive that effort.) Would that work?
Milan (or somebody), please try FileSystemView.getFileSystemView().getDefaultDirectory() on all major platforms - various Win32 variants, Linux, Solaris, Mac OS X, and JDK 1.4.2 and 1.5 - to make sure it returns something reasonable we would want to use here. If so, I think we can make that change. I agree that the issue of non-ASCII pathnames is probably separate. At worst, someone using a non-English Windows may need to exercise care in which directories they use for their projects; the default might not be suitable. (In any case, I cannot imagine any sane user using the default dir for any real projects beyond the hello-world type. You should already have a place where you keep your sources. Select it.)
Cf. also issue #50548 - using as a default a folder name with spaces in it (on Windows) is not a good idea.
HIE standpoint is clear.
My call: don't do any change for 4.0, we'll revisit the issue post 4.0
post 4.0 is 4.1... So what is the plan for 4.1? Real Windows users need this!!! Same as real linux users can't live without complex command line tools or options ot twick their wireless drivers using octal dump editors.
Jesse, you moved back this issue to TBD, while admitting previoulsy you are not a Windows user. All the native Apps on Windows follow this convetion. I know products written in Java that offer this feature. Creator is one, so it's doable. All the Windows products behave this way. By default files outside My Documents folder (localized or not) are not visible to the Windows Explorer tool, and the shorcuts of the File Dialog are: 1/ My Recent Documents 2/ Desktop 3/ My Documents 4/ My Computer 5/ My Network Places. As you see there is no shortcut to C:\Documents and Settings\LOGINNAME which is what NetBeans is defaulting to, and which is not by default visible from the native windows explorer tool. This gives a bad user experience for windows users. So I propose the TBD to be 4.1. What is the forum to dicuss this?
TBD because Petr (the assignee) has not yet evaluated it and I personally do not know for sure whether or not it will be addressed in 4.1 nor exactly how it should be done. Perhaps there is a suitable API for doing so; needs to be investigated.
The thread is pretty long. Let's try. Please verify that everything works. Checking in projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java,v <-- OpenProjectListSettings.java new revision: 1.13; previous revision: 1.12 done
works after removal of old userdir that would store the previously used directory for creating project. so OK. Thanks,
Well, I'm not sure it works OK. It tries to create project under folder: "C:\Documents and Settings\mk123456\My Documents" But New Project Wizard shows error: "Project Folder is read-only" And I cannot create a project there. For regular file creation the folder is not real-only for me.
Please try to evaluate what's the problem. It seems to work on other computers.
OK We;ve tried and it did not work. I will roll the change back. Sorry Ludo. The trouble is that MyDocuments folder is read-only by default on windows. I.e. java will tell you that you can't write to this folder. Also if you look into properties dialog of the folder in windows it will have the read-only check box checkes. In fact you can write to the folder anyway. So much to Windows file system. It's simply cool.
Rolled back. Checking in src/org/netbeans/modules/project/ui/OpenProjectListSettings.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java,v <-- OpenProjectListSettings.java new revision: 1.14; previous revision: 1.13 done
Reopening. I understand that it cannot be fixed now due to the JDK bug, but this is a serious OOBE problem on windows. The "user home" folder on windows is something user should never look into. It's also very hard to navigate into this folder in windows file chooser. Once the JDK bug is fixed, change the default to My Documents. Ideally, the default foder would be something like "...\My Documents\NetBeans Projects"
Thanks for reopening!!! Yes, a sub dir under my documents is the best thing to do by default. this sub-dir can be rw.
Reassigning to Milan. Please, reevaluate.
Just for the reference, the JDK issue is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4939819 and it's still not fixed.
Can we create a write-able subfolder in My Documents? It would be strange given that we cannot create a project there, but if it works, I suggest to use one of these as the default folder: My Documents\NetBeans Projects My Documents\NetBeansProjects My Documents\NbProjects My Documents\NBProjects This would probably be the best solution anyway. Even if it makes the default path longer. The "NbProjects" folder would be created on all OSes.
I did some tests and it seems that even if the My Documents directory is read only it is possible to create a folder there (as Hrebejk posted) on Windows XP. FileSystemView.getFileSystemView().getDefaultDirectory() returns: C:\Documents and Settings\[username]\My Documents on WinXP and /home/[username] on unixes I will check MacOSX and Czech Windows XP. So the solution might be: If IDE is running on Windows we will try to create NetBeansProjects dir (if doesn't exist) under My Documents (or whatever is returned by the call getDefaultDirectory()). If it doesn't fail and folder is created we will use it as base for creating new projects. Otherwise, fallback to the folder we use now. Don't know about other platforms whether we want to change default location for new projects there too.
Great! I would also create the "NetBeansProjects" folder on other OSes. Definitely on Mac where the user home folder contains folders like "Desktop", "Documents", "EclipseWorkspace", "IdeaProjects", "Library", "Movies", "Music", "Pictures", "Public", "Sites". It just makes sense to create a top level folder for NetBeans projects.
On MacOSX the folder is /Users/[username] and Czech Windows XP uses C:\Documents and Settings\[username]\Dokumenty which is kind of strange that part of the path is localized and part is not. I remember seeing some reports from German WinXP with localized even the first part I think it was - C:\Dokumenten und Einstelungen\...
Fixed. NetBeansProjects folder will be created under ${HOME} when running on unixes and MacOS and under .../Documents and Settings/My Documents/ on Windows. Checking in Bundle.properties; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/Bundle.properties,v <-- Bundle.properties new revision: 1.73; previous revision: 1.72 done Checking in OpenProjectListSettings.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java,v <-- OpenProjectListSettings.java new revision: 1.18; previous revision: 1.17 done
*** Issue 51852 has been marked as a duplicate of this issue. ***
*** Issue 151392 has been marked as a duplicate of this issue. ***