From: Gary P. <gpo...@co...> - 2004-12-22 15:11:02
|
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 |