ebob-discussion

[EBOB-DISCUSS] UI for "Inspect": please respond

[Liam M. <lm...@wp...>]

My original idea for what to display when the user selects "inspect" was 
the Properties view that comes with Eclipse. There are a few problems 
with this (ask me if you're curious), so I switched to a 
TableTreeViewer. A table tree viewer is basically a table with a tree in 
the far left column. Unfortunately it doesn't allow user-specified 
images in the tree column. I was really hoping to display a field's 
public/private/static/final properties with an image, the same image 
that gets displayed in the Package Explorer or the Outline (I'm already 
displaying this for methods in the right-click). I tried putting the 
images in the right column (which isn't great in any case), but they are 
limited to what seems to be 16x16 pixels, which is too small.

I have an idea which I think is better than the above two, but seeing as 
how this would be my third rewrite, I just wanted to check with the rest 
of you to get your input. The Visual Editor Project uses a TreeViewer 
(the view is called "Java Beans"). You can right-click on an individual 
variable and select "set text", and it will rename the item right in the 
tree. This is something we can do for modifying public fields. (You can 
also select "rename" to get a popup, but I prefer doing it right in the 
tree). It allows images, and the "search" view uses the same 27x16 
images that I would use in its tree, so I'm guessing I wouldn't have any 
problem with image size.

This way, we can expand objects that are within other objects in a UI 
that's fairly consistent with Eclipse, as opposed to a pop-up "Inspect" 
dialog which would open yet another "Inspect" dialog.

Here's an example of the kind of table I was thinking of (where 'o' is 
where the images would be):

+ objName: ObjClassType
|-- o int primitiveField = 6
|-- o Boolean wrapperField = true
|-+ o MyInterface userClassField = MyClass
| |-- o String stringField = "my string"
| |-- o String nullField = null
| |-+ o int[] arrayField = int[2]
| | |-- int[0] = 0
| | |-- int[1] = 1
| + o List listField = ArrayList

The above is pretty much what you'd see in the debug view, except that a 
non-primitive Boolean object would have a node with its primitive value 
underneath it unlike above.

I think we should also stick something in the properties view, but I 
have no idea what to put there. Maybe variable name, object type, 
associated project, and the constructor it was instantiated with (but 
I'm not sure why someone would want to know that).

Does this sound alright?

Liam

RE: [EBOB-DISCUSS] UI for "Inspect": please respond

[Gary P. <gpo...@co...>]

Comments embedded below.

	--Gary
 

-----Original Message-----
From: ebo...@li...
[mailto:ebo...@li...] On Behalf Of Liam
Morley
Sent: Wednesday, December 22, 2004 3:24 AM
To: ebo...@li...
Subject: [EBOB-DISCUSS] UI for "Inspect": please respond

My original idea for what to display when the user selects "inspect" was the
Properties view that comes with Eclipse. There are a few problems with this
(ask me if you're curious),
[gfp] I'm curious.

 so I switched to a TableTreeViewer. A table tree viewer is basically a
table with a tree in the far left column. Unfortunately it doesn't allow
user-specified images in the tree column. I was really hoping to display a
field's public/private/static/final properties with an image, the same image
that gets displayed in the Package Explorer or the Outline (I'm already
displaying this for methods in the right-click). I tried putting the images
in the right column (which isn't great in any case), but they are limited to
what seems to be 16x16 pixels, which is too small.
[gfp] I bet with a little creativity you can come up with a 16x16 image that
would work. You can also just use what many tools put in for public (+),
private (-), and protected (#) properties and add something for final.

I have an idea which I think is better than the above two, but seeing as how
this would be my third rewrite, I just wanted to check with the rest of you
to get your input. The Visual Editor Project uses a TreeViewer (the view is
called "Java Beans"). You can right-click on an individual variable and
select "set text", and it will rename the item right in the tree. This is
something we can do for modifying public fields. (You can also select
"rename" to get a popup, but I prefer doing it right in the tree). It allows
images, and the "search" view uses the same 27x16 images that I would use in
its tree, so I'm guessing I wouldn't have any problem with image size.
[gfp] Modifying it the way you would in the properties or Java Beans view is
fine.

This way, we can expand objects that are within other objects in a UI that's
fairly consistent with Eclipse, as opposed to a pop-up "Inspect" 
dialog which would open yet another "Inspect" dialog.
[gfp] There's precedent for using inspect dialogs since they are very much a
part of debugging.

Here's an example of the kind of table I was thinking of (where 'o' is where
the images would be):

+ objName: ObjClassType
|-- o int primitiveField = 6
|-- o Boolean wrapperField = true
|-+ o MyInterface userClassField = MyClass
| |-- o String stringField = "my string"
| |-- o String nullField = null
| |-+ o int[] arrayField = int[2]
| | |-- int[0] = 0
| | |-- int[1] = 1
| + o List listField = ArrayList

The above is pretty much what you'd see in the debug view, except that a
non-primitive Boolean object would have a node with its primitive value
underneath it unlike above.

I think we should also stick something in the properties view, but I have no
idea what to put there. Maybe variable name, object type, associated
project, and the constructor it was instantiated with (but I'm not sure why
someone would want to know that).

Does this sound alright?
[gfp] It's probably fine. Now, putting on my Mr. Draco hat ... are these the
important things that will keep you from having a working project? What's
the first deliverable? Get that and then incrementally add. I'm really
concerned that you're suffering from feature creep. Not that this isn't a
good thing to do in the sense of a research project, but you do need to
realize that there's a deadline that will be quickly coming up.

Liam



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Ebob-discussion mailing list
Ebo...@li...
https://lists.sourceforge.net/lists/listinfo/ebob-discussion

Re: [EBOB-DISCUSS] UI for "Inspect": please respond

[Liam M. <lm...@wp...>]

Comments embedded.

Gary Pollice wrote:

>[gfp] I'm curious.
>  
>
The properties view uses a table tree viewer, but instead of allowing a 
complete heirarchy, they allow just one level- any property can have a 
"category", but you can't have nested categories. So we'd have to have a 
popup for inspecting an object within the object. (We couldn't have 
replace the contents of the properties view because that would break 
with the properties view being selection based.) Also, anyone can turn 
these categories on or off so we can't expect them to be there; the 
category would have to end up being something like the name of the 
variable, and everything else would be on the same level. It also 
doesn't support images whatsoever, so I couldn't use the same images 
that Eclipse uses in the rest of the UI. It's all less than ideal.

>[gfp] I bet with a little creativity you can come up with a 16x16 image that
>would work. You can also just use what many tools put in for public (+),
>private (-), and protected (#) properties and add something for final.
>
Are you saying we could do it in ASCII? Or come up with our own smaller 
image? I actually misspoke about the image size- I just checked, and the 
TableTreeViewer is cutting off the images to a size of 10x10 pixels, 
which I don't understand at all. The icons which are the size we would 
want are 16x16. I think that being consistent with the JDT would be 
great, seeing as how they give us a whole bunch of images to use off the 
bat. I'd also want to follow 
http://www.eclipse.org/articles/Article-UI-Guidelines/Contents.html#IconSpecsOvr_VDG.

>This way, we can expand objects that are within other objects in a UI that's
>fairly consistent with Eclipse, as opposed to a pop-up "Inspect" 
>dialog which would open yet another "Inspect" dialog.
>[gfp] There's precedent for using inspect dialogs since they are very much a
>part of debugging.
>  
>
A pop-up dialog while debugging in Eclipse? Where is that?

>[gfp] It's probably fine. Now, putting on my Mr. Draco hat ... are these the
>important things that will keep you from having a working project? What's
>the first deliverable? Get that and then incrementally add. I'm really
>concerned that you're suffering from feature creep. Not that this isn't a
>good thing to do in the sense of a research project, but you do need to
>realize that there's a deadline that will be quickly coming up.
>
Actually I'm way ahead of schedule, and I'm bored. The deadline for this 
iteration is in 1 week, I could do this in two days (seeing as how I can 
reuse most of the code), and it's really all that's assigned to me this 
iteration. If we had to release it today, I'd release the existing 
tabletreeviewer from last iteration.

Liam