Community
Participate
Working Groups
Eclipse Mars brought the hierarchical project view, which was a big step in the right direction. Users can now hide sub-project folders inside a parent project. Unfortunately, the same is not true for the "Open Resource" view. This view still shows a duplicate entry for every nesting level you have in your project hierarchy. For instance: root sub foo.txt Will show up twice as /root/sub/foo.txt /sub/foo.txt There are two workarounds, neither of which work well: 1) Adding resource filters for the subproject folders. This completely removes them from the resource tree, so the use has no chance to get a quick overview of all folders in the project. Also, for large projects (100s of sub-projects) resource filters really slow down refresh/auto-build 2) Marking the folders as "derived". They no longer show up in "Open Resource" by default, but this leads to other funny behavior. For instance, eGit automatically adds such folders to .gitignore by default. I think if two resources have the same physical location, the "Open Resource" view should only show the one with the shortest workspace path, i.e. /sub/foo.txt in the example above.
Damn, I just found "Filter duplicated resources" in the filter dropdown. This should absolutely be the default :)
Also, the combination with "Filter derived resources" does not work well: root sub foo.txt If foo.txt is marked as "derived" in /sub, then the "Open Resource" view will show /root/sub/foo.txt, even though "Filter duplicates" was activated. I think the duplicate filter should be applied before the derived filter.
Created attachment 260706 [details] The animated gif shows how to reproduce the issue. If I understand correctly, we can solve this bug by setting "Filter Duplicated Resources" as default.
New Gerrit change created: https://git.eclipse.org/r/69847
The proposed change sets by default the "Filter Duplicated Resources" to true.
Please also make sure to apply the "Duplicate" filter before the "Derived" filter, otherwise you'll get the somewhat confusing behavior I described above.
Created attachment 260708 [details] Video shows Project explorer using different objects for the same physical resource. The mentioned behavior seems not related to filter priority. I verified that the project explorer uses different objects to represent the same physical resource when the resource belong to more than one projects. So, after you set the "derived" property, the filter actually hide the filtered resource. I suggest to close this bug as resolved and open another one about setting properties on physical objects, as the extent of the second is broader.
I know that the file is represented by two different objects and that only one of them is derived. That's exactly my point: When I check both boxes, I expect that *both* resources are filtered. The longer one because it is a duplicate and the shorter one because it is marked as derived. What actually happens is that the longer one *not* filtered. I strongly suspect this is because the shorter one is filtered first (because it is derived), so the longer one is not filtered, because it is no longer detected as a duplicate.
(In reply to Stefan Oehme from comment #8) I agree there is something strange in the filter, but I cannot describe it properly, as I don't have a proper abstraction for that. This is Why I suggest to open a new bug. > When I check both boxes, I expect that *both* resources are filtered. The > longer one because it is a duplicate and the shorter one because it is > marked as derived. The "longer is a duplicate" is arbitrary: if we have two files corresponding to the same path (i.e. ending sub-p/sub.txt) according to "my mapping" (non bidirectional), when you remove duplicates, you lose information on the original files. So, if you want to filter on a property of the original file you must do this filter before the the "remove duplicates" operation > > What actually happens is that the longer one *not* filtered. I strongly > suspect this is because the shorter one is filtered first (because it is > derived), so the longer one is not filtered, because it is no longer > detected as a duplicate. What happens is quite different, looking at the code [#1]: (1) in the restoreDialog() [#2] you'll see that first the "remove duplicate" filter is added to the list of filters [#3]. then the applyFilter() is called. This apply filter is a complex filter operation, computing aldo the isDerived (2) For the actions executed after clicking on the checkboxes, we have two different kind of executions: (a) for removing duplicates, we add a filter to the list, and we schedule a filter operation for later [#4], while, (b) for filtering derived we apply the filter on the fly [#5] #1 https://goo.gl/q2kQ3E - gitHub repo for: eclipse.platform.ui/bundles/org.eclipse.ui.ide/extensions/org/eclipse/ui/dialogs/FilteredResourcesSelectionDialog.java on GitHub #2 https://goo.gl/m2LOZQ - Line 254 #3 http://goo.gl/a7c9Oq - Line 264 #4 https://goo.gl/zzTZpe - Line 549 #5 https://goo.gl/RDLd2b - Line 569 (line numbers are valid as of today;) Hope this is enough to make you reconsider the extent of this and open a new bug to agree on a concrete model of filtering that will make happy also the other users of the Ctrl-R Filter, that is most of the Expert Eclipse Users. If you open that bug, I'm strongly interested in the discussion.
(In reply to Patrik Suzzi from comment #9) > (2) For the actions executed after clicking on the checkboxes, we have two > different kind of executions: (a) for removing duplicates, we add a filter > to the list, and we schedule a filter operation for later [#4], while, (b) > for filtering derived we apply the filter on the fly [#5] Sorry, [#4] and [#5] are swapped, it's the other way around. .
See Bug 491085
New Gerrit change created: https://git.eclipse.org/r/70712
The proposed solution sets "Filter Duplicated Resources" = true by default. To be consistent it also set the default value of "Show Derived" to false.
(In reply to Patrik Suzzi from comment #13) > The proposed solution sets "Filter Duplicated Resources" = true by default. > To be consistent it also set the default value of "Show Derived" to false. This is should not be changed. The current defaults (both off) are by design. Like the hierarchical mode is also not the default.
Two possible solutions: close as INVALID or link the hierarchical view to the preference in the dialog.
(In reply to Dani Megert from comment #14) > This is should not be changed. The current defaults (both off) are by > design. Like the hierarchical mode is also not the default. Is there a reasoning somewhere why it is a benefit to the user to see the same resource multiple times? Or was the default set "by design" to not change the behavior when it was introduced? I can't think of any reason why I would want to see the same file multiple times, ever.
Same for me, plus I'm usually ("by default") not interested in searching for auto-generated files either. Could you elaborate on that design? Which type of user does it have in mind?
(In reply to Christoph Obexer from comment #16) > I can't think of any reason why I would want to see the same file multiple > times, ever. For example to see that more than one project contains the same file.
(In reply to Dani Megert from comment #18) > (In reply to Christoph Obexer from comment #16) > > I can't think of any reason why I would want to see the same file multiple > > times, ever. > > For example to see that more than one project contains the same file. That's the definition of "duplicate". But what's the use case? By far the most prominent case are nested projects (the standard for both Gradle and Maven) and these users definitely don't want to see duplicates: http://stackoverflow.com/questions/17797438/eclipse-maven-showing-multiple-paths-for-the-same-file http://stackoverflow.com/questions/15064796/eclipse-file-search-finds-the-same-file-multiple-times http://maven.40175.n5.nabble.com/Duplicate-resources-td139103.html https://www.waltercedric.com/index.php?option=com_content&view=article&id=2048&catid=129:maven-build-system&Itemid=332 https://advancedweb.hu/2015/11/03/eclipse_maven/
(In reply to Stefan Oehme from comment #19) > By far the most prominent case are nested projects (the standard for both > Gradle and Maven) and these users definitely don't want to see duplicates: I agree with the latter but I don't think we have any data to prove the former. Anyway, the proposed solution from comment 15 would solve the problem.
(In reply to Dani Megert from comment #20) > (In reply to Stefan Oehme from comment #19) > > By far the most prominent case are nested projects (the standard for both > > Gradle and Maven) and these users definitely don't want to see duplicates: > > I agree with the latter but I don't think we have any data to prove the > former. > > Anyway, the proposed solution from comment 15 would solve the problem. Only if the hierarchical view becomes the default, otherwise it wouldn't change much. Many users aren't even aware of the hierarchical view, as it doesn't work in the Package Explorer.
(In reply to Stefan Oehme from comment #21) > Only if the hierarchical view becomes the default, otherwise it wouldn't > change much. Many users aren't even aware of the hierarchical view, as it > doesn't work in the Package Explorer. There's a bug open for that.
(In reply to Dani Megert from comment #22) > (In reply to Stefan Oehme from comment #21) > > Only if the hierarchical view becomes the default, otherwise it wouldn't > > change much. Many users aren't even aware of the hierarchical view, as it > > doesn't work in the Package Explorer. > > There's a bug open for that. See bug 491185.
Cool, then tying that behavior to the hierarchical view would work for me.
*** Bug 497859 has been marked as a duplicate of this bug. ***
(In reply to Dani Megert from comment #15) > Two possible solutions: close as INVALID or link the hierarchical view to > the preference in the dialog. +1 for that. Although the hierarchical view isn't a preference per se but a memento on the project explorer. So it requires to retrieve the project explorer view (if this one is active) and read its state. This value should be used to set the default value of the "Duplicate resource" filter, but users should still be allowed to change it in the dialog.
I actually happen to like Patrik's patch and don't get Dani's comment that "This is should not be changed. The current defaults (both off) are by design." Indeed, I'm curious about the use-cases that prevent from changing "Show Duplicates" to true by default? Pragmatically, in all projects I've worked on, I've never found a good reason to show mulitple entries for the same file in "Open Resources", and I've always seen this as an issue rather than as a feature. So I'm most likely missing something that leaves me unconvinced by Dani's comment so far. Is there some preference available to influence the default value of dialog settings? Or any simple way to change that from downstream IDEs (such as EPP ones)?
(In reply to Mickael Istria from comment #27) > I actually happen to like Patrik's patch and don't get Dani's comment that > "This is should not be changed. The current defaults (both off) are by > design." > Indeed, I'm curious about the use-cases that prevent from changing "Show > Duplicates" to true by default? Pragmatically, in all projects I've worked > on, I've never found a good reason to show mulitple entries for the same > file in "Open Resources", and I've always seen this as an issue rather than > as a feature. So I'm most likely missing something that leaves me > unconvinced by Dani's comment so far. If it's just about editing the file, then filtering can work, but if you also want to use the dialog to go to the containing folder via 'Show In', then you need to have the choice. > Is there some preference available to influence the default value of dialog > settings? Or any simple way to change that from downstream IDEs (such as EPP > ones)? No. There's no mechanism to provide initial values for dialog settings. See a possible solution suggested in my comment on https://git.eclipse.org/r/#/c/90192/
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. -- The automated Eclipse Genie.
> The information can be, for example, that the problem still occurs, Yes, it does. > that you still want the feature Yes! And to be clear the 'feature' that I want... is a more sensible default behavior for the setting that enables the 'fix' for this bug. I really don't like how Eclipse seems to often have this 'bug fix' for some strange behavior but then also has an obscure preference that disables the bug fix by default over some misguided (just i.m.o) fear that there may be folks out there who actually wanted the strange behavior. > If it's just about editing the file, then filtering can work, but if you also > want to use the dialog to go to the containing folder via 'Show In', then you > need to have the choice. I don't need that choice I have never ever wanted to show files from a nested project in the parent project, it just doesn't make sense to me to think of that resource in that way. In every case where I'm seeing the UI treat this 'nested' as if it belongs directly to the parent project I have found this nothing but confusing and undesirable. Yes, I speak only for myself here, but I suspect that this really how most people feel and keeping the i.m.o. 'broken' behavior as the default is wrong. If there really are people out there who want it this way, have them switch the preference instead. As it is now, I think most people will be annoyed by this behavior, and probably are not aware that there is an obscure 'fix this bug' preference they need to toggle to get it to behave properly.
+1 for changing the default, I also think the scenario of Dani is less likely to impact users than the current default.
Setting the target to 4.15M1 so that we can discuss if necessary.
> Yes, I speak only for myself here No @Kris, you don't speak for yourself. You also speak for me.
I got bugged a few times by this feature today, wasting about ~1 hour trying to understand and fix a bug about markers not being visible (because i was on the wrong "pointer" to that file, I figured out after 1 hour). I'd just like to change the hardcoded default value.
New Gerrit change created: https://git.eclipse.org/r/156254
Regarget for 4.16 M1. Mickael/Andrey please handle it.
Fixing bug 568790 should fix it automatically.
I think we can consider it's a dup of bug 568780. Setting the "hidden" flag would avoid such duplicates to be shown in many places (open resources, search...). The workspace should provide an option to manage whether to automatically hide folders which are available as nested projects. *** This bug has been marked as a duplicate of bug 568780 ***
As an alternative, Open Resources is basically built-in Ctrl+3, where resources are de-duplicated.
