Community
Participate
Working Groups
Given this physical structure: root (a project) sub (another project) foo.txt (a file marked as derived in the /sub project) When I use the "Open Resource" dialog without any filters, I see two entries for foo.txt as expected: /root/sub/foo.txt /sub/foo.txt When I only activate "Hide duplicate resources", then /root/sub/foo.txt is removed as expected. When I only activate "Hide derived resources", then /sub/foo.txt is removed as expected. When I activate both filters, I expect both entries to be removed. What actually happens is that /root/sub/foo.txt is shown and only /sub/foo.txt is removed.
I see what you mean: when both "show derived" and "filter duplicates" are checked, the filtering is not consistent. See http://i.imgur.com/J9pIr39.png Now the question is: does it make sense to filter the duplicated and, at the same time show derived resources? Concerning Bug 490899 comment 9 : Filtering derived items work on project base: we have two objects for the same file if stored in two different Eclipse projects Filtering duplicates work on filesystem base: we filter and remove duplicates. My first thought is to make the two options mutually exclusive. Is there any practical reason to do differently?
No, they should not be mutually exclusive. Again, take the simple example: /root/sub/bin/SomeClass.class /sub/bin/SomeClass.class JDT marks /sub/bin/SomeClass.class as derived. JDT does not (and should not ) care about /root/sub/bin/SomeClass.class. But as a user, I don't want to see /root/sub/bin/SomeClass.class because it is a duplicate. The correct functionality of "Filter Duplicates" should not be broken by also clicking on "Filter Derived".
Created attachment 260724 [details] Screenshot of the bug As you can see in the screenshot, the .class file from the root project is shown, even though it is a duplicate. It should NOT be shown.
New Gerrit change created: https://git.eclipse.org/r/69965
Created attachment 260731 [details] Now we can filter both derived and duplicated resources at the same time. Please, review provided Gerrit change
Andrey, could you please review this change?
The change does not contain any tests, so this could break again without notice.
You are right. I already did a preliminary investigation: The ideal test fires up a non-blocking "Open Resources" Dialog, then enable/disable "Show Derived" and "Filter Duplicates"; then tests which items are displayed in the list. I already spent some time trying to figure out how to test this, and it came out it is not a simple task: for (1) the SWT single-threading model, and (2) for the specific lack of protected/public getters to test the displayed elements in the open resources list. Given that UI tests are not mandatory in Platform UI, and given this specific test is kind of complex, I suggest to add a new bug to address this. For this new bug, I could easily provide a test skeleton that builds a workspace with a master-sub project hierarchy, and it opens the Dialog. But my test, so far, it is not able to interact with the dialog (1) and to get the list of results (2). Maybe we can co-operate on this. Note: Splitting bugs is my way to manage complexity, separating a definite solution w.r.t. something of which I don't know the feasibility.
(In reply to Patrik Suzzi from comment #8) > Given that UI tests are not mandatory in Platform UI I think this should be brought up with the Platform UI team in general. At least to me, not requiring tests seems like a huge problem. > I suggest to add a new bug to address this. If the Platform UI team feels comfortable with marking this as fixed without a test, I won't stand in your way ;)
(In reply to Patrik Suzzi from comment #6) > Andrey, could you please review this change? I do not see *any* change in behavior compared to the previous state. Also the comment 0 example is still unchanged. > When I activate both filters, I expect both entries to be removed. I still see sub/foo.txt if I select both derived/dup filters.
To observe the change you will need to: 1. create master and sub-project 2. create files and mark them as derived resources, as you can see in attachment 260731 [details]
(In reply to Patrik Suzzi from comment #11) > To observe the change you will need to: > 1. create master and sub-project > 2. create files and mark them as derived resources, as you can see in > attachment 260731 [details] This does not match the comment 0, where the duplicated file was marked as derived in a single project only.
Yes, but this bug is a follow-up of Bug 490899. In Bug 490899 comment 8 we can read the reporter checked both boxes: > When I check both boxes, I expect that *both* resources are filtered. Ans in (comment #1) I reported an image with the filtering schema > ... http://i.imgur.com/J9pIr39.png and I referenced the assumptions before of creating this bug. > ... and concerning to Bug 490899 comment 9 Stefan, can you confirm?
(In reply to Patrik Suzzi from comment #11) > To observe the change you will need to: > 1. create master and sub-project > 2. create files and mark them as derived resources, as you can see in > attachment 260731 [details] Also if I mark file as derived in *both* projects, I see no behavior change at all compared to the previous version. I simply see no change at all, and looking at the patch I can't understand where the changes should came from...
(In reply to Andrey Loskutov from comment #14) > I simply see no change at all, and looking at the patch I can't understand > where the changes should came from... It is hard to comprehend. 1. buggy behaviour: https://bugs.eclipse.org/bugs/attachment.cgi?id=260706 from Bug 490899 comment 3. 2. fixed behavior: https://bugs.eclipse.org/bugs/attachment.cgi?id=260731 from this Bug 491085 comment 5) To reproduce the bug, create a master-project and a sub-project. For the subproject override the default location, and put as location a directory under the master project Then open the Window > Show View > Project Explorer. Create the sub-pr.txt file in the sub.project, and set the "Derived" flag in it. Now, you will see a sub-pr.txt file also in the master.project/sub.project; then you should set the "Derived" flag also for it. Then create another file: master-pr.txt (don't set the Derived flag) Now you can launch the Open Resource Dialog and start searching for .txt files. When you select to filter both derived resources, and duplicated resources, you should see only one of the sub-pr.txt, because: there are two derived resources, but one is filtered out, because the duplicates are removed. With the same workspace, before the change, if you select to filter both Derived and duplicated, you will see two files named sub-pr.txt in that list
(In reply to Andrey Loskutov from comment #14) > I simply see no change at all, and looking at the patch I can't understand > where the changes should came from... Sorry Andrey; I cannot reproduce the bug. Excuse me If I asked you to spend your time. AFAIR, The filtering, as requested, was resolved just by calling the scheduleRefresh(); in ShowDerivedResourcesAction#run() The rest of the code was to store the preferences for ShowDerivedResources and for FilterDuplicatedResources, which should belong to the Bug 491085. I added that code to this bug, with the intention to set 491085 as fixed by this. However, I probably tricked myself when initially I set only one file to derived, and later when I set both the sub-files to "Derived". (removing the review flag, and asking further information to the reporter)
@Patrick: Your image and description do not match what I described in comment 0 as well as comment 2. The duplicate file in the root project is NOT marked as derived. It would be very inconvenient to ask the user to manually mark all those files. Often, files are not created by the user, but by a tool like JDT. The tool cannot know that there are duplicates of the file somewhere else in the workspace. See comment 2 for one example. Again: I expect BOTH files to be hidden because: /root/sub/foo.txt is a DUPLICATE /sub.foo.txt is DERVIED @Andrey You understood the bug correctly and I agree that the change does not fix it.
(In reply to Stefan Oehme from comment #17) > @Patrick: Your image and description do not match what I described in > comment 0 as well as comment 2. > > The duplicate file in the root project is NOT marked as derived. It would be > very inconvenient to ask the user to manually mark all those files. Often, > files are not created by the user, but by a tool like JDT. The tool cannot > know that there are duplicates of the file somewhere else in the workspace. > See comment 2 for one example. > > Again: I expect BOTH files to be hidden because: > > /root/sub/foo.txt is a DUPLICATE > /sub.foo.txt is DERVIED > > @Andrey You understood the bug correctly and I agree that the change does > not fix it. When you activate both filters you see a list: including Derived resources and Without duplicates. What you see is correct because you marked as derived only one of the two foo.txt files. This bug seems invalid, because the actual checkboxes are "Show also derived" and "Hide duplicates", and not "Hide derived" and "Hide Duplicates", as you mention.
By "Hide derived" I of course meant "Show derived is disabled". Just look at the screenshot I attached. The duplicate file is shown, even though "Hide duplicate Resources" is checked and "Show derived Resources" is unchecked.
(In reply to Stefan Oehme from comment #19) > By "Hide derived" I of course meant "Show derived is disabled". Just look at > the screenshot I attached. The duplicate file is shown, even though "Hide > duplicate Resources" is checked and "Show derived Resources" is unchecked. This bug is about syncing the resource tree when two projects are mapped to the same physical file. Given this physical structure: root (a project) sub (another project) foo.txt (a file marked as derived in the /sub project) When you right click on foo.txt and mark the file as derived in the /sub project, You want also the corresponding resource in /root/sub is marked as derived. Is this correct?
(In reply to Patrik Suzzi from comment #20) > This bug is about syncing the resource tree when two projects are mapped to > the same physical file. No. > > When you right click on foo.txt and mark the file as derived in the /sub > project, You want also the corresponding resource in /root/sub is marked as > derived. > > Is this correct? No, that is completely wrong. What I want is this: Given: - I have the nested project structure discussed above - I have marked /sub/foo.txt as derived - I have NOT marked /root/sub/foo.txt as derived When: - I check the "Hide Duplicate Resources" box And: - I uncheck the "Show derived Resources" box Then: - There are NO entries in the list because - /sub/foo.txt is derived - /root/sub/foo.txt is a duplicate
(In reply to Stefan Oehme from comment #21) > What I want is this: > > Given: > - I have the nested project structure discussed above > - I have marked /sub/foo.txt as derived > - I have NOT marked /root/sub/foo.txt as derived > > When: > - I check the "Hide Duplicate Resources" box > And: > - I uncheck the "Show derived Resources" box > > Then: > - There are NO entries in the list because > - /sub/foo.txt is derived > - /root/sub/foo.txt is a duplicate Ok, Suppose I have the list: > - /sub/foo.txt is (derived) > - /root/sub/foo.txt (not-derived) 1. You want first I remove the duplicate then to remove the derived, Correct? 2. When I first remove the duplicate, which one of the two above should I keep in the list: the foo.txt (derived), or the foo.txt (non-derived)? 3. Tell me the logic of your choice at 2, so it can be implemented.
(In reply to Patrik Suzzi from comment #22) > Ok, Suppose I have the list: > > - /sub/foo.txt is (derived) > > - /root/sub/foo.txt (not-derived) > > 1. You want first I remove the duplicate then to remove the derived, Correct? Correct :) > 2. When I first remove the duplicate, which one of the two above should I > keep in the list: the foo.txt (derived), or the foo.txt (non-derived)? The behavior should be the same as when I only use "Hide duplicates". As far as I can tell, the logic is that the shortest one stays in the list. That matches my expectation as a user.
(In reply to Patrik Suzzi from comment #8) > Given that UI tests are not mandatory in Platform UI, and given this > specific test is kind of complex, I suggest to add a new bug to address > this. Um, that's not quite the case Patrik. We have quite a large inventory of tests. I think this discussion points out being able to reproduce the bug is important.
Moving to 4.7, please move back if necessary.
Please note that this also affects the "File search". For example, when I search for a string inside "message.properties", the result will be shown twice: * Inside the /src/-folder of the JDT project (correct) * Inside the /jdt-project/bin/-folder of the root project (incorrect). Countless times I've accidentally edited the file inside the bin-folder, which obviously has no effect.
What Christian said above. Manually going through duplicate search results wastes brain cycles that could be used elsewhere.
6 years later I arrive at this unfixed bug and after reading all comments, I think the OP has a valid use-case but they incorrectly specify how the UI should function. Using Eclipse 2021-12. In the Open Resource dialog, choosing to hide duplicates should only hide ONE of the duplicates, leaving one shown. This correctly works today. So: - /sub/bin/SomeClass.class is hidden - /root/sub/bin/SomeClass.class is shown, because the parent project has no information that the contents of 'bin' is derived.
