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.

Bug 50143 - Default project location should be in one NBProjects directory
Summary: Default project location should be in one NBProjects directory
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Milan Kubec
URL:
Keywords:
: 51852 151392 (view as bug list)
Depends on:
Blocks: 41535
  Show dependency tree
 
Reported: 2004-10-08 05:06 UTC by _ ludo
Modified: 2008-10-27 09:55 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Ant exception when using non-ascii chars in project location. The file is in UNICODE! (9.77 KB, text/plain)
2004-10-13 09:58 UTC, jrojcek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ ludo 2004-10-08 05:06:49 UTC
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
Comment 1 _ ludo 2004-10-08 05:12:44 UTC
My Documents are under

C:\Documents and Settings\LOGINNAME\My Documents

Modulo localization, of course.
Comment 2 Jesse Glick 2004-10-08 16:21:42 UTC
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.
Comment 3 _ ttran 2004-10-11 21:11:20 UTC
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?
Comment 4 Jesse Glick 2004-10-11 21:17:24 UTC
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.
Comment 5 _ ludo 2004-10-12 03:48:49 UTC
I disagree with the wonfix status.

The issue is not resolved.
I need much more comments in this bug for a wontfix status.
Comment 6 jrojcek 2004-10-12 09:33:12 UTC
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.
Comment 7 _ ttran 2004-10-12 09:52:32 UTC
> 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?
Comment 8 _ ttran 2004-10-12 09:56:41 UTC
jano, please check how MS Visual Studio works in this regard,
including putting some non-ascii chars in the pathnames
Comment 9 jrojcek 2004-10-12 18:18:08 UTC
> 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.
Comment 10 Jesse Glick 2004-10-12 19:53:43 UTC
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.
Comment 11 jrojcek 2004-10-13 09:38:28 UTC
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.
Comment 12 jrojcek 2004-10-13 09:58:30 UTC
Created attachment 18249 [details]
Ant exception when using non-ascii chars in project location. The file is in UNICODE!
Comment 13 _ ttran 2004-10-13 10:53:21 UTC
> 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:\? :-)

Comment 14 Jesse Glick 2004-10-13 18:40:03 UTC
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.
Comment 15 jrojcek 2004-10-14 08:57:28 UTC
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?
Comment 16 Jesse Glick 2004-10-14 18:50:14 UTC
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.)
Comment 17 Jesse Glick 2004-10-19 16:46:32 UTC
Cf. also issue #50548 - using as a default a folder name with spaces
in it (on Windows) is not a good idea.
Comment 18 jrojcek 2004-10-21 12:23:10 UTC
HIE standpoint is clear.
Comment 19 _ ttran 2004-10-21 12:39:03 UTC
My call: don't do any change for 4.0, we'll revisit the issue post 4.0
Comment 20 _ ludo 2005-01-08 00:38:07 UTC
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.
Comment 21 _ ludo 2005-01-14 20:19:22 UTC
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?



Comment 22 Jesse Glick 2005-01-14 20:27:49 UTC
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.
Comment 23 Petr Hrebejk 2005-02-02 16:46:30 UTC
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
Comment 24 _ ludo 2005-02-03 04:23:07 UTC
works after removal of old userdir that would store the previously
used directory  for creating project.
so OK.
Thanks,
Comment 25 Milan Kubec 2005-02-03 09:41:58 UTC
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.
Comment 26 Petr Hrebejk 2005-02-03 12:26:26 UTC
Please try to evaluate what's the problem. It seems to work on other
computers.
Comment 27 Petr Hrebejk 2005-02-03 14:09:55 UTC
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.
Comment 28 Petr Hrebejk 2005-02-03 16:03:43 UTC
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
Comment 29 jrojcek 2006-02-10 10:07:33 UTC
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"
Comment 30 _ ludo 2006-02-10 17:42:52 UTC
Thanks for reopening!!!
Yes, a sub dir under my documents is the best thing to do by default.
this sub-dir can be rw.


Comment 31 Antonin Nebuzelsky 2006-03-27 11:28:05 UTC
Reassigning to Milan. Please, reevaluate.
Comment 32 Milan Kubec 2006-03-27 20:13:29 UTC
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.
Comment 33 jrojcek 2006-04-19 16:39:36 UTC
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.
Comment 34 Milan Kubec 2006-05-02 15:18:59 UTC
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.
Comment 35 jrojcek 2006-05-02 15:53:06 UTC
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.
Comment 36 Milan Kubec 2006-05-04 07:40:06 UTC
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\...
Comment 37 Milan Kubec 2006-05-04 10:33:53 UTC
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
Comment 38 Marian Mirilovic 2006-08-17 07:32:38 UTC
*** Issue 51852 has been marked as a duplicate of this issue. ***
Comment 39 Jiri Skrivanek 2008-10-27 09:55:27 UTC
*** Issue 151392 has been marked as a duplicate of this issue. ***