Re: Packages node UI spec - underspecified and hard to read

cL wrote:
>>>
>> Well, you did not answer the question. You gave a specific example, 
>> but not a specification of how a "rename" operation is supposed to be 
>> working with the folders and files on user's harddrive.
>> I think you should define the effect of "Rename" UI operation precisely:
>> - when and which levels are renamed
>> - when a new directory is created
>> - when a folder is removed
>> - when contents of a folder will be moved to parent/child
> 
> you're asking for the logical semantics which should be clear but aren't 
> part of the ui. i will work with Tomas to clarify things and then 
> incorporate any relevant parts into the ui spec.
> 
Chris, you are kidding: You shouldn't put an action into UI when you can 
not tell what the action will do: how it will operate, how the UI state 
changes.

The UISpec should make clear what action has what semantics. The 
semantics is not clear and you are UI designer so you should provide the 
meaning, NOT Tomas. Without precise semantics, you do not do UI design, 
but just paitning.

I seem to have to bring these issues to nbdiscuss@ mailing list for 
community resolution what is (or should be) the UI spec and its author 
responsible for, if not for appearance and semantics of the GUI. The 
fact that GUI can be designed without semantics worries me a lot.

> 
>>
>> Now what to do when there are conflicting resources for Copy/Cut ? Or 
>> just resources with the same filename sitting in the same package, but 
>> different folders ? Which file gets ultimately copied ? The first one, 
>> last one ?
> 
> this depends on the location things are pasted to. if the root chosen 
> has files with the same name then the user needs to be prompted to 
> overwrite or cancel the operation.
> 
The user is pasting from multiple physical locations, merging them 
together. There are files, with the same name on 2 or more locations, 
which are being merged into a single folder. What now ?

-Svata