Re: Alternative UI of Project Explorer

cL wrote:
> i have seen the design and it has it's merits. i'm not convinced that pushing Resources and Outputs to other tabs will increase their discoverability but it's also something to

The intention is not to increase visibility of those nodes, but in fact 
to have them not obscur the most central IDE view during normal work.

Under normal circumstances, the user accesses almost exclusively project 
content, not external referencies or build settings.

As an excercise. I tracked how many times in the past week I invoked 
Project Properties in IntelliJ IDEA, which specifies such parameters: _4 
times in the whole week_ (when the project dependencies changed). And I 
coded for the whole week intensively, approx 6 hours a day (that is 
accessed source files).

> labor intensive to work with inter-dependent projects. e.g. if you have 
> three projects that are all connected to each other (via b.t. outputs as 

Well, again, compare how labor-intensive is scrolling up and down the 
tree to find the other location in severeal screen heigh tree content 
compared to switching a combo (which I plan to have a hotkey assigned for).

> resources) typically only one of those is the one you care to run. with 
> an active project the runnable project is set active while work 
> continues on other projects. without an active project the user will 
> need to switch to the desired project before running.  it's an extra 

Well. According to usability study, there's an usability problem with 
having actions bound to an Active project (since the user thinks actions 
are working with current selection).

Whatever solution will be found to that issue, it can be equally applied 
to introduce Build and Execute action variants tied to a particular 
build target in a project (although not displayed in the Explorer), a 
particular project or a particular execution profile -- the issue is 
just the same.

At the end, it may make sense to have (for build style actions):
- build the current object
- build the entire current project
- build the "active" project

I think there are legal use cases for all of them.

BTW (copying from nbui@):
> 
> what i'm suggesting is that we have places for outputs and resources and sources but we look at calling them things that are more in-line with the expectations that using a particular language entail

When having tabs, it is quite easy for Java nature to disable Resources 
view (tab) by default and introduce "Classpath" tab instead. I have yet 
to think how to present various cases, like a resource that is used only 
in a specific build tagret, or runtime-classpath-only resource.
The user is then free to open "External Resources" view and see them all 
  external stuff unfiltered.

-Svata