Re: java mdr ui spec

Tim Boudreau wrote:
> You could consider docking the object explorer into the *right*
> side of the editor, at least if getScreenSize() returns a reasonable
> value for width (okay, with layers that's a little hard).

this leaves a huge visual chasm between the cause and the effect as the 
user will have to move their attention all the way across the screen. if 
they need to further interact with the list the they'll be mousing a lot 
too. i think having the two explorers together will prove to be more 
useful than separating them by any remarkable distance.

> 
>> Open Issues (from the document)
>>
>> Does the tree work everywhere? Should some of the views have a 
>> different display model (list, tree table, etc)
> 
> 
> I played with this writing the class navigator module.  If you're
> only displaying a flat list of something like class members, it
> uses horizontal space better to use a list and avoid the
> 
> |_
> |_
> |_
> 
> line of the tree.

for sure. and i think there are several places where a list would be 
sufficient. i think we'll need to look at each case and make a call. it 
might be useful to package other information into some of the views 
(members along with the classes in subclasses view) which might mean 
more trees.

> 
>> What information has been left out of the spec. Specifically, in the 
>> Object Explorer, are there details in any of the views that should be 
>> added?
> 
> 
> Another option for UI, if we wanted to go there, is a Mozilla-style
> component that can be popped open on demand, and the rest of the time,
> shows a small line and handle that can be clicked.  Sort of like a
> JSplitPane you can open with a single click, I don't know what they
> call such a component.  You'd know better than I if they're intuitive.

this is exactly what i had in mind. probably didn't describe it 
accurately enough.

> 
>> Is the UI implementable? The split pane spec'd here is a never before 
>> seen item for nb.
> 
> 
> How so?  Not much reason it couldn't be its own explorer component -
> it's mainly how they're positioned together that determines the
> perception that it and the traditional explorer are the same component
> or different ones, AFAIK.

just a sanity check. i think my feet are on the ground but one never 
knows for sure. :-)

cheers,
cL