Community
Participate
Working Groups
hi, when you define a ".options" file as part of the trace-switches mechanism, it is not displayed in the Project Explorer. Its visible from the Navigator. thanks, Andrew
by default .* resources are filtered in the Project Explorer you can make them show up via: the view menu -> Customize View -> Filters tab -> uncheck .* reosurces
(In reply to comment #1) > by default .* resources are filtered in the Project Explorer > > you can make them show up via: the view menu -> Customize View -> Filters tab > -> uncheck .* reosurces thanks, but my thinking was that .options as a file with special significance in plug-in projects should be automatically defined as an exclusion to this rule? I've reopened the bug for reconsideration
The problem we have is that the .options file is a PDE file and the Project Explorer is a JDT view. I am not aware of any way the JDT provides to allow other tools to modify their filter (and there could be a good case made that this is not a good idea). I am moving this bug to the JDT for them to comment/consider the request for this as a special case or allow some mechanism to let other components override the .* filter.
The filter is contributed by /org.eclipse.ui.navigator.resources/plugin.xml
One option (that may be a bit of work) could be to enhance the navigator content to support an 'extensionFilter' as well as a 'commonFilter'. The extensionFilter could support attributes such as : * extensionId - the ID of the filter being extended. * prepend / append flag to indicate whether the rule should be included at the beginning or the end of the filter chain * combination operator, e.g "AND" or "OR" * filterExpression - the additional criteria to be checked So for this example, you would have an addition filter prepended to commonFilter extension "org.eclipse.ui.navigator.resources.filters.startsWithDot", the combination operator would be "AND" and the filter expression would represent "NOT / adapt->IResource / test->name = .options" I guess this may be too big a change for just this one enhancement (i.e. .options); would there be other similar scenarios that would make an enhancement like this worthwhile?
Probably best add a "activeInPerspectiveID" to the list of things an extensionFilter would need, in order to prevent the customization from 'polluting' the whole of Eclipse.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
