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: | User-choosable filter of the "Open" file dialog for the Java Files | ||
---|---|---|---|
Product: | utilities | Reporter: | Victor Vasilyev <vvg> |
Component: | Open File | Assignee: | Jaroslav Havlin <jhavlin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 209998 | ||
Bug Blocks: | |||
Attachments: | The patch that removes code of the "Java files" filter from the module "User Utilities" (<hg repo main>/utilities) |
Description
Victor Vasilyev
2010-03-14 17:00:58 UTC
Created attachment 95138 [details]
The patch that removes code of the "Java files" filter from the module "User Utilities" (<hg repo main>/utilities)
See the comments about applying the patch above.
I just noticed that I forgot to add one comment NOI18N NOW: return new String[] {".java"}; SHOULD BE: return new String[] {".java"}; // NOI18N Could you please, do it during transaction. Sorry, but I am not sure if this is the most appropriate solution - should Java (and C/C++ and all other language supports) really be friends of the User Utilities module and have dependency on it? In the current situation, I would have to create a brand new bridge module, just to hold the one implementation class that would provide the filter (making java.source or java.editor depend on User Utilities does not seem feasible to me). Could you please consider some alternative approaches before we create such a module? For example, the filter could be specified declarativelly in the layer, binding a name to a list of mime types and these mime types would be used to recognize file types (would require FileObjects, but is the most precise way). Thanks. Jan, I agree it is not the best solution. Seems requirements against an implementation should be collected and refined before to have clear constraints and criteria of quality. Probably, we also need examine a variant of extracting of the Open File functionality into a separate module to have it as an optional functionality of the NetBeans platform. Let we to suspend discussions and activities in this area until the NB6.9 release. To track this issue I'll reassign it to myself. Please use target milestone. Fixed, see bug 209998. |