Re: Project Groups - UI proposal ready

Todd Fast wrote:
>> I am not comfortable with the idea of basic and advanced modes

See reply to Jano - this was never intended as part of any final UI, 
only as a convenience while developing the UI.

>> These seem more like a choice when creating a group, so why not 
>> instead use a toggle in the Create New Group dialog (when the user
>> hits the toggle, he's presented with more or fewer options)?

If indeed we kept Advanced mode as a separate option, that is how it 
would presumably be displayed. (JButton "Advanced >>" is customary.)

>> Groups should definitely stay away from any sort of build
>> dependency determination

There is no relationship between groups and the build process, except 
insofar as "required project" relationships might affect both the build 
sequence of certain project types and the content of "Master Project" 
groups.

>> This seems like much less of an issue if groups are not presented 
>> directly in the project view and are just invisible sets of
>> projects that are opened as a unit

Which is currently the case.

>> I'm not really clear on the value of the autosynch feature. It 
>> requires a lot of explanation to the user for what seems like a
>> dubious feature.

How so? Jano's perspective (and mine) is that a user would expect a 
group to be autosynch by default, as this behavior matches the simple 
notion of "switchable workspace". I would be more worried about 
explaining non-autosynch free groups, since in that case you need to 
think about synchronizing the group definition with the current reality, 
and master/folder groups where the open project list can be out of synch 
with the natural definition of the group.

>> I think the whole story could be simplified by removing the
>> autosynch feature, and just give the user the ability to snapshot
>> the current set of projects to the current group, or to a new
>> group.

That is precisely what the non-autosynch free group does. Did you try 
it? To help people out a bit I am attaching a current NBM.

>> The use case that autosynch seems to be trying to address is in the
>> shutting down of the IDE and restarting, in which the user would
>> like to see the last set of projects he had open previously.

The IDE already does that. Autosynch free groups mean that if you switch 
to a different group and then back, you will have the same set of 
projects open as you did originally.

>> How are dependencies for master projects determined?

This is a generic part of the project system infrastructure. Compare the 
list of Required Projects in the Open Project dialog.

>> if I have a composite application project with dependencies on BPEL
>> projects, XSLT service projects, Java EE projects, etc., how will
>> the group system know these are dependent?

Don't you work on such "enterprise" project types? If so then you should 
know the answer. (I don't.)

>> Have you given any thought to using groups to hide projects from
>> the view, even though they are still open in the IDE?

No. This sounds rather confusing to me.

>> Has the idea of a special group project type been considered
>> instead

You can already (today) define a freeform project which is empty save 
for a list of subprojects (which can be given as relative paths). The 
GUI to set this up is missing but it is easy with a text editor so 
making a GUI would not be so hard. You could then use that with a master 
project group, for example. Try opening the 'demo' subdirectory of a 
(recent) JDK 6 installation to see an example (clearly the UI could be 
improved given sufficient interest).

>> Could we use a similar approach for projects by persisting names of
>> groups a project is associated with into each project?

Perhaps but this would force changes on project types and I'm not sure 
it's particularly intuitive. Also it will be useless if you want to 
group together the trunk versions of projects in an app vs. the branched 
versions, assuming the names have not changed since the branch was made.

>> it would require users to manually open projects in order to see them 

That would defeat much of the purpose of the project group feature, 
which is to enable quick switching between groups.

-J.

-- 
[email protected]  x22801  netbeans.org  ant.apache.org
       http://google.com/search?q=e%5E%28pi*i%29%2B1