Community
Participate
Working Groups
If projects are structured hierarchical, I assume that the user prefer to seem this in this structure. Assuming that the hierarchical view is stable enough, I suggest to enable this mode as default for Neon.
Mickael, you are maintaining this mode. Do you feel it is ready to be the default mode?
There are still some open issues if you search for "project hierarchical", but didn't look at them in detail.
I believe bug 461266 needs to be addressed before considering making this feature default. Other issues open seem to be more nice-to-have or minor usability discussions about how to interact better with a project hierarchy, those ones wouldn't be blocker for making it default IMO.
(In reply to Mickael Istria from comment #3) > I believe bug 461266 needs to be addressed before considering making this > feature default. +1 Please try to fix that bug for M7. Having hierarchical view on per default would be a great enhancement.
Mass move to 4.6 RC1. We might push out more to 4.7.
This is IMO not something that we can target for 4.6. At least, I cannot commit to fixing all related issues in the allowed timeframe. Moving 4.7.
Mickael, shall we target 4.6.1 with this one?
I believe the only noticeable differences remaining are: 1. The problem report on Project Explorer doesn't cascade up to parent. 2. Search and other dialogs browsing workspace do not reflect the project hierarchy. I've been using hierarchical projects for a couple of years now and I don't believe those are major issues, and I highly prefer hierarchical view with those 2 issues to the flat view. So my opinion is that it would be a good thing this enable it by default as part of 4.6.1. If we change the default, then I believe it would only affect new instances of Project Explorer. So people who already have a workbench/workspace wouldn't notice the difference until they close Project Explorer and start again. It would actually be very interesting to make the initial behavior a preference. I would even consider it as a requirement for making hierarchical layout default.
(In reply to Mickael Istria from comment #8) > I believe the only noticeable differences remaining are: > 1. The problem report on Project Explorer doesn't cascade up to parent. > 2. Search and other dialogs browsing workspace do not reflect the project > hierarchy. > > I've been using hierarchical projects for a couple of years now and I don't > believe those are major issues, and I highly prefer hierarchical view with > those 2 issues to the flat view. > So my opinion is that it would be a good thing this enable it by default as > part of 4.6.1. We have to make sure to put this into M1, so that we get early feedback. > If we change the default, then I believe it would only affect > new instances of Project Explorer. So people who already have a > workbench/workspace wouldn't notice the difference until they close Project > Explorer and start again. I didn't look at the Project Explorer code, but usually the view settings are stored on each change, i.e. close and reopen wouldn't help. If the goal is to force everyone at least once to get the hierarchical mode, then we could add migration code to the view that sets the hierarchical mode, but just once. After that the user's choice is used again > It would actually be very interesting to make the initial behavior a > preference. I would even consider it as a requirement for making > hierarchical layout default. -1 to mix view settings and preferences.
(In reply to Dani Megert from comment #9) > We have to make sure to put this into M1, so that we get early feedback. Mickael, can you prepare already a Gerrit review, which I can merge after we declare 4.6.0?
Thanks to Dani's comment, I now give up on the idea that a preference is necessary. So yeah, we can consider it just after Neon release.
(In reply to Mickael Istria from comment #11) > Thanks to Dani's comment, I now give up on the idea that a preference is > necessary. So yeah, we can consider it just after Neon release. Getting late for "just after the Neon release".
Delayed. Also revert assignee to default as I cannot commit to work on this task for M4 (other higher priority stuff in current todo-list).
(In reply to Mickael Istria from comment #13) > Delayed. > Also revert assignee to default as I cannot commit to work on this task for > M4 (other higher priority stuff in current todo-list). ==> then you can't set a milestone.
Is there anyone against having Project Explorer set as default at the moment? If not, I can look into doing this.
(In reply to Ian Pun from comment #15) > Is there anyone against having Project Explorer set as default at the > moment? If not, I can look into doing this. You mean set the hierarchical mode to default, right?
By trying to enable the hierarchical project presentation by default from my product I found this Bugzilla. Usually for that we use preferences with plugin_customization.ini file (like well described here https://www.eclipse.org/forums/index.php/t/1093476), and currently this working model it not working for this specific option. Or a least I still didn't found the way to get it working. Does someone know any solution and/or workaround ? Thanks by advance.
(In reply to Julien D from comment #17) > By trying to enable the hierarchical project presentation by default from my > product I found this Bugzilla. > > Usually for that we use preferences with plugin_customization.ini file (like > well described here https://www.eclipse.org/forums/index.php/t/1093476), and > currently this working model it not working for this specific option. Or a > least I still didn't found the way to get it working. > > Does someone know any solution and/or workaround ? Yep. See bug 511580 and "Dialog settings defaults" section in https://help.eclipse.org/2019-03/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fproduct_configproduct.htm
(In reply to Andrey Loskutov from comment #18) > Yep. See bug 511580 and "Dialog settings defaults" section in > https://help.eclipse.org/2019-03/index.jsp?topic=%2Forg.eclipse.platform.doc. > isv%2Fguide%2Fproduct_configproduct.htm Unfortunately such preferences are stored in a .prefs file (see wkps/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.ui.navigator.prefs) and not from any dialog_settings.xml. Also my previous EF link does not point to expected topic, please use https://www.eclipse.org/forums/index.php/t/1093476/ instead (last '/' seems to be important).
The state of the Project Explorer is stored as a "memento", which is yet-another more complex structure to store state, see https://wiki.eclipse.org/FAQ_How_does_a_view_persist_its_state_between_sessions%3F . Memento is not easy to statically configure like a dialog settings or a preference. The best way to change it is most likely to write a plugin that listens to view creation event and programatically change the state of the Project Explorer. Instead of directly using the memento or the CNF APIs for that, it's probably best to use the Command/Handler service and invoke the "org.eclipse.ui.navigator.resources.nested.changeProjectPresentation" command. Looking at ProjectPresentationHandler will give hints about what parameters can be passed to the command.
New Gerrit change created: https://git.eclipse.org/r/142869
Suggested quick fix. Not sure if I missed any cases. (In reply to Eclipse Genie from comment #21) > New Gerrit change created: https://git.eclipse.org/r/142869
@all: I've been using it happily since its inception and never felt the need to move back to flat view. I have the impression the hierarchical view is now stable enough and functionally much better then the Flat one. Should we try to make it default in 4.15?
(In reply to Mickael Istria from comment #23) > @all: I've been using it happily since its inception and never felt the need > to move back to flat view. I have the impression the hierarchical view is > now stable enough and functionally much better then the Flat one. Should we > try to make it default in 4.15? I would vote +1 only if there will be a way for product owners to unset this via the product customization. Otherwise -1. We have workspaces with hundred thousands of files, and I fear hierarchical mode will made such workspaces unisable.
(In reply to Andrey Loskutov from comment #24) > I would vote +1 only if there will be a way for product owners to unset this > via the product customization. Otherwise -1. We have workspaces with hundred > thousands of files, and I fear hierarchical mode will made such workspaces > unisable. So maybe I'll just try to replace usage of a memento to store the state with a preference? With this, it'd be persisted across view close/open cycles and would be configurable in plugin_customization.ini.
(In reply to Mickael Istria from comment #25) > (In reply to Andrey Loskutov from comment #24) > > I would vote +1 only if there will be a way for product owners to unset this > > via the product customization. Otherwise -1. We have workspaces with hundred > > thousands of files, and I fear hierarchical mode will made such workspaces > > unisable. > > So maybe I'll just try to replace usage of a memento to store the state with > a preference? With this, it'd be persisted across view close/open cycles and > would be configurable in plugin_customization.ini. This would be nice, but also we would need to write transition code that converts existing memento into preferences.
(In reply to Andrey Loskutov from comment #26) > This would be nice, but also we would need to write transition code that > converts existing memento into preferences. So one question is: would it be OK for people who do not use the hierarchical view right now to move to hierarchical view by default and having to set the preferences to the other value? If so, we do not need to care about the existing memento as the default behavior would be either the desired "better" behavior or the same one as offered by memento.
(In reply to Mickael Istria from comment #27) > (In reply to Andrey Loskutov from comment #26) > > This would be nice, but also we would need to write transition code that > > converts existing memento into preferences. > > So one question is: would it be OK for people who do not use the > hierarchical view right now to move to hierarchical view by default and > having to set the preferences to the other value? Yes. > If so, we do not need to > care about the existing memento as the default behavior would be either the > desired "better" behavior or the same one as offered by memento. I believe not only this one option is stored in the memento. If I understand you right, you wanted to switch from using memento to preferences? Or did you mean only this one option? In that case no transition code needed IMO.
(In reply to Andrey Loskutov from comment #28) > I believe not only this one option is stored in the memento. If I understand > you right, you wanted to switch from using memento to preferences? Or did > you mean only this one option? In that case no transition code needed IMO. Only this one option for now; maybe generalize it later if we feel the need for it.
New Gerrit change created: https://git.eclipse.org/r/155609
Gerrit change https://git.eclipse.org/r/155609 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=cfb996bcb93c216e6cf7b37eae4a5c09c5650ab9
This will probably also need to be documented in the migration guide.
New Gerrit change created: https://git.eclipse.org/r/156072
Gerrit change https://git.eclipse.org/r/156072 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=2abb229c448083b7f9ed1d5c40a6c33588c3c863
