Re: projects ui recommendations

Chris Le Dantec wrote:
>> 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. 
> 
> output will still be browsable via the Files view. the resource browsing 
> is something that could be added in for scenarios where it is vitally 
> important. it was discussed by the group here and we agreed that tree 
> browsing resources was not a likely activity; using code completion or 
> javadoc tools is the much more likely task that users will use to browse 
> resources.

Ah, so looking at library's resources, gifs, bundles and non-.class 
stuff will be supported by the user's favourite file manager and a 
textpad, I suppose. Text searches in sources of libraries included in 
the project will be probably done by Find in Files in Windows or grep on 
Unixes and those files will be viewed in a Notepad integrated with the 
search engine.

I don't know about you, but people around here seem to need these things 
fairly often. There are quite a few use cases orthogonal to 
coding/documentation semantics that seem the only ones supported.

>>>
>> Chris, have you ever seen a dependency graph ? I wonder how you would 
>> make such diagram fit into the Explorer window. 
> 
> sure, and it would be tricky, but my point is that it is up to the 
> enterprise group to decide what is the most useful for their users.
> 
What I meant by the sarcasm is that I don't see a particularly 
user-friendly way how to fit a planar graph with > 5 nodes into the 
narrow explorer area. Graph displays are more suitable to have in the 
editor area.

>> 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. 
> 
> there are some differences but i don't think any of them are fundamental 
> in that what is done with a Solution cannot be done with a Project 
> Group. right now there are no features associated with a Project Group 
For example, the Startup Project selection. What will the IDE do if two 
Project Groups specify two different startup projects and the user 
presses "Execute" ? We have

> so it's completely free to become something more feature laden for 
> groups that need it. and it's arguable that for the time being groups 
> that need the extra functionality be the one's to add it to Project 
> Groups -at a later date if others see a demonstrable need for such 
> features they can be moved around so more project types can take 
> advantage of them.
> 
Sorry, Chris, the above paragraph is too Public Relation laden for me to 
understand. Could you please say in in simple words ? Did you meant that 
Project Groups are there just for fun now - and that that people are 
trying hard to think what they should become ? What about removing them 
at all, if they do not represent any functionality and introduce them 
only after a clean model has been found for them ?

-Svata