Re: Projects tab UI

Svata Dedic wrote:

> Vitezslav Stejskal wrote:
>
>> Hi Svato,
>>
>> here are my answers for your more UI oriented questions:
>>
>> Svata Dedic wrote:
>>
>>> Things, which are not obvious (to me) even after reading the UI spec 
>>> (please consider these as clarifications requests for both 
>>> functionality and the UI):
>>>
>>> * Could an already opened projects be added onto a Workplace ? 
>>
>>
>> Programaticaly, opening/closing the projects has nothing to do with 
>> showing/hiding it on the projects tab. However, the user shouldn't 
>> see any difference. So from users standpoint the answer would be: no.
>>
> A ProjectDesciptor could be opened programmaticaly using 
> ProjectManager.open(). Has such project to be closed before it can be 
> placed (and reopened) on Workplace ?

No.

>
>>>
>>> * Could one remove a project from the Workplace without closing it 
>>> first  ? (a counterpart operation for the first one). 
>>
>>
>> Not using the public API. And again the user should see only one 
>> version of 'Project Close' action, that one which closes the project 
>> and removes it from the Projects tab or do you have usecases 
>> questioning this approach?
>>
> I am not clear on designed role of Workplace API. Given that a project 
> can be opened (manipulated, ...) without opening on Workplace, I 
> assumed the Workplace is a layer above ProjectManager.

Yes, this was our intention. I admit that the Workplace API doesn't 
allow to fully manipulate the 'content of workplace' and exposes only 
the most required operations - open/close - which, in fact, are 
conjunction of 'opening the project' and 'adding it to workplace' (and 
reverse op. for close).

[snip]

> Yes, but I am not getting why the *same* action, "Close", behaves 
> differently based on whether a project is present in a Project Group. 

Agreed, the behavior of Close action is weird.

> For me as "dumb" user, project groups are just way how to organize 
> things (btw I was quite disappointed when I was required to give a 
> filename for a project group I was creating). Why should "organized" 
> project nodes behave differently from "unorganized" ones ? That's not 
> very intuitive, IMHO.

Ehm, I don't understand this. The group is not just a UI concept 
comletely buried somewhere in the IDE. Our intention is to make its 
persistance visible for the user and allow to share it among users in 
the similar way how projects will be shared.

>
> I would rather follow Microsoft Visual Studio's approach -- they 
> present closed projects in their Workspace and the user is in charge 
> to Load/Unload/Remove them. 

I have no strong opinion on this. The Eclipse has it too. It's more 
consistent than current implementation in the prototype.

-vita