Re: projects ui recommendations

Chris Le Dantec wrote:
>> Some thoughts.
>>
>> - I'm not sure I like the removal of the output and resource trees
>>  from the explorer. The explorer paradigm seems to me to be
>>  fundamentally designed to support drag-and-drop. If we remove the
>>  output and resource trees, we don't seem to be exploiting this drag
>>  and drop capability. Perhaps I'm more sensitive to this because in
>>  SE (nee EE) we would expect that this feature might get used more
>>  than in other editions, as logical applications would always be
>>  decomposed into multiple projects linked by output-resource
>>  relationships.
> 
[...]
> frequency. as with most setup activities they aren't likely to be an 
> ongoing, many time a day task (the kinds of things where drag and drop 
> offer the most in user aid).
> 
It is an error to think about "Resources" and "Outputs" nodes only in 
terms of managing the project setup. The way they were used in the 
project explorer, they also provide browsing capabilities. Browsing 
Output files may not be so useful once the user understands the IDE, 
browsing Resources - external dependencies of the project - is quite 
desirable.
C.f. IntelliJ IDEA - both "sourcepath" and "classpath" project view 
contain actually a mix of project own and external sources/ classes. In 
Eclipse, external deps are browsed directly in the project Navigator, as 
if they were items in the project's directory.

In a sense, these use cases were supported in NetBeans 3.x, since the 
IDE treated all filesystems (either those containing project's contents 
and those used to introduce external deps) equally - so it allowed to 
browse and search through the external stuff.

I do not think that simply dropping the associated use cases because of 
problems the particular UI design had should be an option, since it 
degrades functionality compared even to NetBeans 3.1.

> 
>>  An alternative would be to have a "project relationship view" that
>>  would omit sources and ONLY show outputs and resources. Perhaps even
>>  a spiffy graphical view would be good...planarizing a DAG into 2-D
>>  graph is much more comprehensible than a tree, which is necessarily
>>  limited since a tree can only show containment graphically, not
>>  arbitrary relationships.
>>
> 
> this is certainly a possibility and the infrastructure spec explains how 
> something like this would turn up as another tab in the explorer.
> 
Chris, have you ever seen a dependency graph ? I wonder how you would 
make such diagram fit into the Explorer window.

> 
> your objection to the concept of active project seems more a disguised 
> request for a vs 'Solution' like feature. to start with, we already have 
> the concept of a Project Group that collects any number of projects 

Solution is quite different from [current] Project Group: starting with 
that there's at most ONE Solution opened at a time, while the UI spec 
says there may be multiple Project Groups opened at a time.
So any settings (startup project, ...) that is decided by (singleton) 
Solution is ambiguous if set for (several) Project Groups.

Solutions, for example, are the place where Configurations are created 
or removed; the set of Configurations applies to all members (projects) 
of the Solution. There's no such functionality in Project Groups vs. 
Projects - set of Configurations is local to each project and 
independent of other ones.

So these two concepts are not really comparable in their delivered 
functionality for fundamental reasons.
Maybe we should precisely define what a Project Group stands for (now 
IMHO: nothing more than an container that influences open/close cycle of 
its children) to see whether the concept is useful at all or is just 
another all-three-users case.

-Svata