Bug 461347 - Project Explorer - Hierarchical Presentation - closed nested project does not hide when selected Hierarchical presentation; "Open and disable builders" or Explorer mode
Summary: Project Explorer - Hierarchical Presentation - closed nested project does not...
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 4.5   Edit
Hardware: All All
: P3 minor with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-03 22:04 EST by Paul Verest CLA
Modified: 2020-01-04 13:00 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Verest CLA 2015-03-03 22:04:17 EST
In Eclipse Mars M5

When playing with Hierarchical Presentation using https://github.com/Nodeclipse/quickimage

1. in Flat presentation import quickimage-parent, quickimage-feature
2. close them all or quickimage-feature
3. switch to Hierarchical Presentation

quickimage-feature is still shown, though it should be within quickimage-parent
Comment 1 Mickael Istria CLA 2015-04-20 05:30:07 EDT
Here are a few things to at least try to explain why this request is not trivial:

* The Eclipse Resource model doesn't even allow to list the children of a project, so when quickimage-parent is closed, there is no proper way to check that quickimage-feature in a child.

* Your case seems easier than the general case of the sub-project, because it's a direct child (so it seems possible to list it directly as a child, but how should the project explorer behave if quickimage-feature were in a sub-sub-folder - such as features/quickimage-feature ? What should we show in that case? 
Also, let's imagine that quickimage-parent has a pom.xml and the quickimage-feature as direct child. If we close the quickimage-parent, should we hide the pom.xml and show only the quickimage-feature child?
Your opinion on these questions is very welcome.

* We could imagine, in case a project is closed, to provide a filesystem-based navigator, without using Eclipse resource model, but that would create a lot of confusion for users: files would look similar, but depending on whether they are in an open project or not, they would have very different "behaviours" (ie completion wouldn't work, they wouldn't be listed in the Open File dialog...).
I'm afraid introducing those 2 different concepts (resource/filesystem) in the same explorer would really confuse users.

So overall, I don't have a good idea of how to correctly handle the case of closed projects. Although it seems interesting that we make them somehow "browsable", there are big confusion risks associated to this ability.

I've been using Hierarchical view for some time now, for multiple projects, of multiple kinds, in the same workspace. And my usage habit has become to not close projects unless it's ncessary (eg when I'm working on projects that depend one and other, but with incompatible versions; but this never affects "parent" projects), and now, I'm wondering: what are the real use-cases where closing a parent project makes sense?...
Comment 2 Paul Verest CLA 2015-04-20 11:07:05 EDT
(In reply to Mickael Istria from comment #1)
nice comment

Hierarchical Presentation adds new questions, and above example is not giving full picture.

I would prefer showing files in closed project, and you already pointed at way (to provide a filesystem-based navigator) 

I have long wanted for explore mode in Eclipse. Often I just need to take a quick look at project, and really need to compile it. Or will need it to compile but it would take 10-30 minutes for all dependencies (here in China). So I just import as General project, or recently add minimal .project file (using `nodeclipse -g` command) and import as existing. (Hopefully there will be a way to import from command line while Eclipse is opened. [1]) This allows to start learning while maven `mvn package` is still executing.

[1] https://github.com/seeq12/eclipse-import-projects-plugin

I think project explore mode is to be between closed and opened project mode.
In explorer mode it should open file for viewing and editing, without starting build. Yes, there may be reminding prompt later like 
"You were exploring project and have change .java file. 
Would you like open project with re-build?"

Transitions from Closed to Opened and Opened to Closed:

               -----open------>
Closed                               Opened   
       -explore-> Explored  -open-> 

             <------close------
Closed                               Opened   
       <-close- Explored  <-explore-

Icon for project can include something like loupe, so Q is used.

I.e. it would add Explore command to context menu (below Open Project or Close Project) and likely "Open in Explore mode" checknox in most Open/Import project dialogues.

With that above could be that quickimage-parent would become in Explored mode to show folders for subprojects.

Yes, this is more about trying concept that would fit nice into existing user habits.

> but that would create a lot of confusion for users: files would look similar, but depending on whether they are in an open project or not, they would have very different "behaviours" (ie completion wouldn't work, they wouldn't be listed in the Open File dialog...).
First project icon is to be different: use loupe, different color.
Try opening Java/Maven as general project: J is while instead of blue color, and there is no validation markers or subtree and java file (actually the same if copy java file into not-source folder)

> I'm afraid introducing those 2 different concepts (resource/filesystem) in the same explorer would really confuse users.
Yes, that why new concept is first to become crystal clear and easy and natural to grasp for users. (resource/filesystem) or opening project in "general project mode"

Well, "open in General project mode" while longer is close to actual meaning.

By the way IntelliJ IDEA has "power saving mode", where several feature like advanced content assist are disabled.

Also it would solve for new users's question of "Eclipse becoming slower and taking n minutes to open" because workspace has got too many opened projects.  
Personally I prefer keep most of projects opened, just because I often look into sources and read/modify note files (like README) there.
The "open in General project mode" or "Explore mode" would just be enough,
because I don't need actually those projects to be rebuilt every Eclipse restart or be shown in full red color just because some related projects are not opened.  

Should I just (close this issue and) create new 
'project "explorer mode" or "General project mode"' ?
Comment 3 Mickael Istria CLA 2015-04-21 08:35:45 EDT
Thanks for this nice story and ideas. I have a few questions/comments to evaluate whether this actually requires new concepts, or whether it's just a few controls to add here and there.

(In reply to Paul Verest from comment #2)
> I have long wanted for explore mode in Eclipse. Often I just need to take a
> quick look at project, and really need to compile it. Or will need it to
> compile but it would take 10-30 minutes for all dependencies (here in
> China). So I just import as General project, or recently add minimal
> .project file 

Quick note here: if you use the Create New Project on an existing location, that's exactly what happens. Also, an alternative import workflow is incubating: https://wiki.eclipse.org/E4/UI/Smart_Import . If you try it, the 1st page exactly does that: import a directory as a general project, for exploration. Then 2nd page allows configuration of the project.

> I think project explore mode is to be between closed and opened project mode.
> In explorer mode it should open file for viewing and editing, without
> starting build.

So your main (only?) reason for closing a project is to disable automatic build and remote dependency resolution on this project?

> Also it would solve for new users's question of "Eclipse becoming slower and
> taking n minutes to open" because workspace has got too many opened
> projects.

Using the most recent milestone, can you describe a user-story that brings to this complaint? Which plugins to install? What kind of projects to load?
I'm working with hundreds of projects open in my IDE, being mostly PDE and m2e projects (simultaneously), and don't face the issue you mention.

> Personally I prefer keep most of projects opened, just because I often look
> into sources and read/modify note files (like README) there.
> The "open in General project mode" or "Explore mode" would just be enough,
> because I don't need actually those projects to be rebuilt every Eclipse
> restart or be shown in full red color just because some related projects are
> not opened.  

It seems to me that a "Open and disable builders" operation would be more or less what you call the Explore mode. Does that sound similar to you?

> Should I just (close this issue and) create new 
> 'project "explorer mode" or "General project mode"' ?

Let's just keep the general brainstorming here for now. Not sure moving to a new ticket would help at that point ;)
Comment 4 Paul Verest CLA 2016-03-25 11:59:49 EDT
(In reply to Mickael Istria from comment #3)

> Quick note here: if you use the Create New Project on an existing location,

Create New Project on an existing location are bad words to tell to new users.

Is Smart_Import merged? https://wiki.eclipse.org/E4/UI/Smart_Import

> So your main (only?) reason for closing a project is to disable automatic
> build and remote dependency resolution on this project?

Using general projects and/or closing project is a way to keep Eclipse (with many project in workspace) quick.

> Using the most recent milestone, can you describe a user-story that brings
> to this complaint? Which plugins to install? What kind of projects to load?
> I'm working with hundreds of projects open in my IDE, being mostly PDE and
> m2e projects (simultaneously), and don't face the issue you mention.

Well m2e has become much better now, but it still blocks UI.
(For a 10-30 seconds on a simple adding dependency to pom.xml and save, then trying to do some other operation)
or getting User operation is waiting.

> It seems to me that a "Open and disable builders" operation would be more or
> less what you call the Explore mode. Does that sound similar to you?

Yes, "Open and disable builders" wording is more Eclipse-like. Is it existing feature?
Comment 5 Eclipse Genie CLA 2020-01-04 13:00:12 EST
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.