Bug 67814 - Show In > Package Explorer doesn't ask for removal of last filter [package explorer]
Summary: Show In > Package Explorer doesn't ask for removal of last filter [package ex...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 RC1   Edit
Assignee: Dirk Baeumer CLA Friend
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-18 10:22 EDT by Markus Keller CLA Friend
Modified: 2005-05-27 05:46 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA Friend 2004-06-18 10:22:50 EDT 
200406180010; Not a dup of 66646.

'Show In > Package Explorer' doesn't ask for removal of a filter iff there's
only a single filter set.

Steps:
- Disable all filters in Package Explorer, except for 'Referenced Libraries'.
- Open editor for java.util.Vector
- Navigate > Show In > Package Explorer
=> fails, doesn't ask for filter removal. Works iff at least one other filter
(which would not filter the element) is active.
Comment 1 Dirk Baeumer CLA Friend 2004-06-20 09:53:32 EDT 
Not critical for 3.0. We could put this into the readme. Erich ?
Comment 2 Erich Gamma CLA Friend 2004-06-20 14:51:59 EDT 
agreed, readme is good enough
Comment 3 Dirk Baeumer CLA Friend 2005-05-22 16:37:20 EDT 
The problem is that the package explorer only checks if the new filter list is
greater than zero. If we remove the last filter the number of filter is zero.

The correct implementation (simply checking if the list is greater than zero can
lead to other false positives as well; imagine the element isn't filter at all
but still not presentable in the package explorer) should first get the list of
current filters and then check if the new list is smaller than the old one. 

However, this requires making the already present method getEnabledFilterIds API.

Erich, would you support this. Its not critical for 3.1 since we live with the
bug for a while now, however can be annoying..
Comment 4 Erich Gamma CLA Friend 2005-05-23 05:54:16 EDT 
Fix makes sense and since it is annoying we should not hold it back for 3.1.

The method that becomes public is in a class mostly owned by Dani. Dani is there
any reason to not make this method public?
Comment 5 Dani Megert CLA Friend 2005-05-23 06:02:23 EDT 
There's no problem making it API if it's really needed since we return a copy.
The setter should remain private.
Comment 6 Dirk Baeumer CLA Friend 2005-05-24 05:38:39 EDT 
Made the method public, however changed the name to internalGet... add speced it
in a way to bot be called by clients outside of JDT/UI.
Comment 7 Dirk Baeumer CLA Friend 2005-05-24 05:40:04 EDT 
Fixed.
Comment 8 David Saff CLA Friend 2005-05-27 05:29:55 EDT 
Verifying...
Comment 9 David Saff CLA Friend 2005-05-27 05:33:20 EDT 
Verified in I20050527-0010.  Markus, please update resolution to VERIFIED.
Comment 10 Markus Keller CLA Friend 2005-05-27 05:46:35 EDT 
Setting to verified.