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 8299

Summary:	USER TEST: "Which Package" dialog that appears when using File > Open to view a simple text file causes confusion
Product:	utilities	Reporter:	jhoffman <jhoffman>
Component:	Code	Assignee:	issues@www <issues>
Status:	CLOSED FIXED
Severity:	normal	CC:	cledantec, druiz, mvenkatraman
Priority:	P4
Version:	3.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:

Description jhoffman 2000-11-08 23:25:55 UTC

During the FFJ user test, all of the users were surprised or confused by the
need to choose a package when all they wanted to do was to view a text file.
There should be a mechanism to view/edit text files without requiring that the
user knows that they must be in a java package.

The File > Open file chooser should also have a Text filter, so that the user
can indicate what type of file they are opening.  When a text file is chosen,
there could be an option of the file dialog that says something like "Add this
item to the explorer <filesystem/package dropdown>".  By default, this would
be unselected for text files but selected for java (and related) files.

Another idea would be to add a checkbox item to the current "Which package"
dialog box that says "Add this item to the selected package below:" and would
be selected by default.  If the user simply wanted to open the file for viewing
(and commands like Compile would be disabled), then he or she would deselect
the checkbox.  I would prefer a solution more in line with the first one above
since under normal conditions it does not require another dialog to appear.

I'm open to other suggestions, as well...

Comment 1 Chris Ledantec 2000-11-09 09:18:59 UTC

in order to do the first solution we need to create our own file chooser. this
is work that is just now getting under way but keep in mind that the limitation
within the dialog are not currently under our direct control.

additionally it isn't always the case that viewing a txt file is so simple. if
the package is selected incorrectly here then the user must create an
additional mount for the files that need editing. since this is all tied to the
internal classpath there is the potential that things will break.

another option is that for txt files and other exceptions an entry in
filesystems is not needed (or rather, directory that the file lives in is
selected by default and it's properties make it hidden and not part of any
classpath). the problem with this is that once a user bcms accustomed to using
the explorer for file manipulation (which is where it should happen, not
through open file) they won't know where to look...

the above problem could be solved via projects by dumping txt files and what
not into some kind of scratch area in the project. but now i'm quickly falling
down the tree of hypothetical solutions so i'd better stop.

Comment 2 Peter Zavadsky 2000-11-09 14:29:59 UTC

Reassigned from txt to core.

Comment 3 Jesse Glick 2001-01-17 15:27:59 UTC

Good grief, if only I knew the problems I would cause when I made
OpenFileAction! :-) Since it seems to be pretty universally confusing and
misleading, why not just delete the thing (not terribly useful to begin with,
only ever intended as a shortcut for advanced users) and let some future
projects module handle it correctly?

Comment 4 Peter Zavadsky 2001-03-01 18:21:35 UTC

Fixed in [main-trunk]. Available in next build. If opening .txt file which is
not mounted already. Is mounted as with default package silently (without
showing package dialog) and opened (if text module is enabled).

Note: From internal(code) point of view is needed more generic solution, e.g.
to detection of supported extensions, detections of textual extesions and acting
appropriatelly.

Comment 5 Peter Zavadsky 2001-03-05 08:49:00 UTC

Additional. [main-trunk]Next build available. I made only for java files asking
the user for mount point. This should be the more appropriate "long-term"
solution.

Comment 6 pfelenda 2003-04-22 17:37:15 UTC

Verified in dev 200304220100 and release33.

Comment 7 Quality Engineering 2003-07-01 15:31:04 UTC

Resolved for 3.4.x or earlier, no new info since then -> closing.