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

Svata Dedic wrote:
> cL wrote:
> 
>> Svata et al:
>>
>>>
>>> * Dynamic behaviour of collapsing
>>> If last data item in a level is deleted, should the structure collapse
>>> into a single node ?
>>
>>
>> it should collapse only if the parent of the node is the collapsed node.
>>
> Shouldn't it also collapse if the now empty package is a direct child of 
> Packages node ?

well, no, if there is one and only one package under the Packages node 
it will be present. the spec does say that the collapsing stops on the 
last package whether it has data or not -at the very least there will be 
one package node under Packages that is either a single package (org) or 
a collection down to either the first non-empty or last empty package 
(org.netbeans.modules.etc).

[snip]
>>>
>>> * Rename: What the user should see in "Rename" dialog ?
>>> Full package's name or just the last component ? If the former,
>>> how exactly will the rename operation proceed, if the user
>>> changes names of more components of the full package's name,
>>> enters fewers components or more components ?
>>
>>
>> it shouldn't matter if the user enters fewer or more components 
>> -whatever belonged in the outer most package still belongs in the 
>> outer most package regardless of what it is called. so if the 
>> collapsed node is o.nb.m.f.g and it gets renamed to o.nb.m.f.b.f the 
>> whatever was in g is now in f and the additional components are 
>> created on disk.
>>
> 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.

> 
>>>
>>> * What will "delete" operation on the node do ? Delete everything from
>>> the topmost folder(s) collapsed into the node ? Delete only folders
>>> that correspond to the last component ? Different "delete" action UI 
>>> ? How
>>> it should look ?
>>
>>
>> if you delete a package then you delete its contents. deleting the 
>> collapsed node will delete everything it contains -this is why we'll 
>> warn the user.
>>
> I don't think the explanation is clear enough for me ;-) Assuming, 
> there's a node "org.netbeans.modules.java", what will be deleted ? 
> Folder(s) "org/netbeans/modules/java" and its(their) contents, or folder 
> "org" and everything below ?

org and everything below.

> 
> Technically content of the package "org.netbeans.modules.java" is only 
> contents of folder "org/netbeans/modules/java" and its subfolders, NOT

yes, but in the logical view of the world we are presenting the user is 
acting on nodes that are aggregate representations of the physical stuff 
on the drive. i consider this to be the same as deleting a java form in 
the ide now -the user is unaware that they are actually deleting two 
files, not just one.

[snip]
> What is "active build target" ? There's no such thing AFAIK. There's 
> "project default build target" (inf spec 7.2.1), but there's no 
> guaranteee that it is "Compiled Classes"-type build target or that you 
> can infer exactly one or "the first" Compiled Classes-type build target 
> from it.

sorry, Default Build Target. if there's no useful info there then the 
default can be either the first as listed in the Packages node 
customizer or the root selected the last time this dialog was used.

[snip]
> So if I have a package "foo.bar" and want to copy over contents of 
> "com.blurb", what's the user procedure which ends with a new package 
> "foo.bar.blurb" which has contents of "com.blurb" copied in ?

1.create package blurb in foo.bar
2.copy contents of com.blurb to foo.bar


> 
>>
>>> - only the lowest level will be copied
>>> - how to handle multiple merged folders ?
>>
>>
>> for copy it shouldn't matter since what is being copied is a package 
>> structure (o.nb.m.f.b) and not a specific location. when it is pasted 
>> it the package structure that gets pasted.
>>
> Consider a situation with 2 java source roots:
> src1/com/sun/
>     Foo.java
> src2/com/sun/
>     bar.xml
> 
> What is "the package structure" in this example ? Do you mean that when 
> data is copied, the output will will merge into one physical location ?

yes, when the user pastes things they'll get to choose where to paste it 
and the whole bit will end up in one physical location.

> 
> 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.

> 
>> for cut -and delete too -the warning will need to prompt the user to 
>> select where to cut/delete from if it's merged.
>>
>> +-------------------------------------------+
>> |                                           |
>> +-------------------------------------------+
>> |                                           |
>> | Cutting [Deleting] the packages will       |
>> | remove the package and its contents.      |
>> |                                           |
>> | The selected package exists in multiple   |
>> | Java Roots, please choose from where it   |
>> | should be cut [deleted].                  |
>> |                                           |
>> | Root: |_All Occurances________________|V| |
>> |                                           |
>> |                         [ Ok ] [ Cancel ] |
>> +-------------------------------------------+
>>
>> the root choices are:
>>
>> -All Occurances -cuts/deletes from all java roots (default)
>> -java roots -as many roots that fit the criteria.
> 
> 
> So does it mean that when the user issues "cut" ("delete") but selects 
> just one Java Root, the Cutted (Deleted) object will remain onscreen, 
> and will be cut (deleted) only partially ?
> 
> Quoting from another answer near the beginning of the e-mail:
>  > if you delete a package then you delete its contents. deleting the
>  > collapsed node will delete everything it contains -this is why we'll
> 
> That somehow contradicts to the chooser ascii-arted above, which allows 
> a partial deletion.

yeah. i realized this. i think this dialog is the way to go bcs it may 
not be clear what the user really wants to cut when there are roots 
providing overlapping packages -so yes, if the user selects one root 
only the bits from that root are cut leaving the rest in place. the user 
who does this has a very good idea of what they're doing so i'm not 
worried about it.

cL
-- 

ui.netbeans.org
interaction designer
[email protected]