This storybook is about support for intuitive visual inspection of the internal structure of factbases, as a debugging aid for transformations. Stories:

• selection history navigation→
• consistent tree view → completed (3. iteration)
  • \"show enclosing...\" → completed (3. iteration), except for smooth scrolling spike and for change of collapse/expand state
  • smooth downward scrolling →
  • keep expansion state →
  • consistent behaviour of context menu and toolbar →
• consistent wood view → completed (3. iteration)
  • \"show referenced...\" → completed (3. iteration)
  • \"show referenced ...\" in other tree → completed (3. iteration)
  • toolbar toggle for \"show reference\" behaviour →
• inspection of factbases in nonstandard modules →

• disable inappropriate behaviour! → completed (april 08)
• cleanup factbase inspector context menu and toolbar → completed (april 08)
• fix broken \"open factbase inspector\" behaviour → completed (april 08)
• integrated \"open factbase inspector\" dialog →
• language parametric inspector → completed for Java (4. iteration) but …
  • bug free up and down navigation in eiffelri inspector → completed (april 08)
    • Document how to fix the EiffelRI specification →
• display nonreferenced children → completed for Java (4. iteration) but …
  • bug free display of unreferenced children in eiffelri inspector → completed (april 08)
    • Document how to fix the EiffelRI specification →

Description: Provide “back” and “forward” arrows in the Inspector toolbar that let you navigate to the previous / next selection of a node in the current Inspector.

Aim: Let users maintain / reconstruct the context of their work by going back to previously selected nodes – which represent previous focus of their attention.

Priority: Medium

Description: Only show descendants below a given node.

• When displaying the tree for a given element ID, only show the node and its descendants, that is, its direct and indirect children.
• Note that what is displayed as a child needs to be consistent with the type of node that is displayed. Each type of node has different types of children.

Aim: Make the PEF Navigator display consistent with mental model of a tree by not showing non-child-elements below a given node!

Priority: High.

Description: Add context menu item to show an enclosing element above the current node!

• The order of the items in the context menu should reflect the containment hierarchy (outermost = topmost):
  • “Show enclosing …”
    • “Project”
    • “File”
    • “Package”
    • “Class/Interface”
    • “Method/Field”
    • “Node”
• The subitems of “Show enclosing …” should depend on the type of the node. For each ancestor element of the node, there must be one context menu item below “Show enclosing…” for displaying the corresponding referenced node.
• Only applicable items should be displayed (note that this is not the same as “greying out unapplicable items”).
• When klicking these items, grow the displayed tree upwards, expanding it just as much as necessary to show the new topmost node and the one that was (and still remain) selected. Do this preferably in an animated way, scroling the previous contents downward, so that the expansion is easy to understand.

Aim: Give the user a way to see also the ancestors of a node while still supporting the mental model of a tree.

Priority: High.

Description: When displaying enclosing elements do it in an animated way, scroling the previous contents downward.

Aim: Give visual feedback to the user so that the expansion is easy to understand.

Priority: Low. (Better usability)

Description: When displaying enclosing elements maintain the expansion state of the current one.

Aim: Don'tconfuse the user by changing the appearance of things that didn't chnge conceptually.

Priority: Low. (Better usability)

Description: The “Show Enclosing” context menu item is enabled for some node whereas the Toolbar button is disabled for the same node. That must not be. They must behave consistently. Preferably, the “Show Enclosing” should still be active if the enclosing element is already displayed. Then the view is just shifted so that the enclosing element becomes visible.

Aim: Don't confuse the user by inconsistent behaviour.

Priority: Medium

Description: The context menu of a node contains a node-type-specific “Show referenced…” item.

• The “Show referenced…” menu contains one item for each reference to an “out of family node” that is neither an ancestor nor a descendant of the selected one. E.g.:
  • an invocation references the definition of the invoked method
  • a field access the definition of the accessed field
• Menu items for out of family nodes must be displayed but do not need to do anything yet (giving them behaviour is part of the really show referenced nodes story).

Aim: Complete the node-type-specific context menu so that it displays every other node that is somehow connected to a node.

Priority: High.

Description: The toolbar should display an icon that indicates the currently chosen option for “Show Reference” behaviour. Clicking on the icon displays in a drop-down menu the two possible choices and lets the user select one. Selection feedback is given by showing that choice in the drop-down menu as “checked” and displaying its icon in the toolbar. The options are:

• “Show References in New Inspector” (its icon already exists and points to the side)
• “Show References as Children” (its icon should be similar to the one above but point downwards): If this option is active, references are displayed in the same inspector, below the referencing node.

The default should be “Show references in new Inspector”. The explicit choice of the user should be remembered in the project proferences, so that it can be restored after shutting down and restarting.

Aim: Satisfy users that prefer the old PEFNavigator behaviour, Tobias in particular

Priority: High.

Description: Make it possible to inspect different elements and their parents / children in different PEF navigators that can be arranged freely, like any other view. Showing a PEF tree in an editor would also be acceptable but not so nice because one looses the ability to have an own menu bar. However, one could take advantage of other structural elements (see for instance Mylyn task editor, XML config editors, …).

Aim: Make it possible to inspect different elements and their hierarchies side-by-side, thus comparing different portions of the factbase that are “far away” in the tree or are not children of each other. Support a 1:1 correspondence of view and displayed tree (not multiple PEF trees in the same view). The latter enables the consistent navigator tree view.

Priority: High.

Description: Let subitems in the “Show referenced…” context menu open a new tree view for displaying the referenced item.

• Open a new PEF navigator view without hiding the previous one!

Aim: Complete the node-type-specific context menu so that it displays every other node that is somehow connected to a node.

Priority: High.

Description: The “Open New Inspector” context menu of the Factbase Inspector currently opens a dialog that is not working anymore. Fix the functionality (make the open by id and open by fully qualified name work again). They should open a new Inspector (instead of displaying the node in the same inspector, as done by the initial implementation). After fixing this create an integrated \"open new inspector\" dialog.

Aim: Bugfix, consistency of 'old' JT actions with new multi-inspector behaviour.

Priority: High

Dependencies: —

Description: In addition to what is indicated in the screenshot below

• add a “Open Inspector for current editor selection” option. Do this only if the editor is the window that has the focus and if it contains a “legal” selection.
• If the window that has the focus is the Prolog Console and there is a selection that is a legal identity then fill this identity as a default value into the identiy textfield.
• Open the same dialog from the JT Menu, the Editor Contet Menu, the Prolog Console Context Menu, the Inspector Context Menu and the Inspector Toolbar!

Screenshots showing dialog

Not this	but this

Screenshots showing behaviour

Not this (old behaviour)
nor this (current bahaviour)	but this
Currently does nothing	Open new inspector!

Aim: Unique point of access for similar behaviour.

Priority: Medium

Dependencies: —

Description: Cleanup the Factbase Inpector's context menu and toolbar:

• Move “Open New Inspector” to the bottom and insert a separator.
• Rename “Show in Java Editor” to “Show Source Code”
• Improve icons:
  • “Show Enclosing” and “Show Referenced” → Copy or create similar icons as those in the Java Type Hierarchy.
  • “Show Source Code” → use the icon shown in the Inspector for nodes with existing source code.
  • “Show Source Code Comparison” → use the icon shown in the Inspector for added / modified nodes with existing source code.
    • Since you create the menu dynamically anyway, decide at run-time which icon (“modified” or “added”) and which tool tip text to display!
• Perform all changes consistently also in the Factbase Inspector's toolbar (and the tool tips).

	Not this (initial state)
	and also not this (yesterday evening)	but this

Aim: Consistency, intuitive handling by sensible grouping

Priority: Medium.

Dependencies: This should best be done by Patrick who already did a lot similar stuff yesterday!

Description : Make sure that the menu items and the behaviour of the Inspector are language parametric, not hardcoded!!!

• Test it using the EiffelRI samples.

Aim: Language Independence!

Priority: Highest

Dependencies: no \"package\" in \"show enclosing\" menu

Description : Remove the bugs illustrated by the attached screenshot. Although the language definition contains all the necessary ast_node_subtree/2 declarations (for the children), children are not displayed. SImilarly, enclosing nodes (ancestors) are not displayed although there are “parent” references in the ast_node_def/3 declarations.

Test: The

Aim: REAL Language Independence!

Priority: Highest

The screenshot shows the behavour after consulting the sample0100.pl from the ''EiffelRISamples4JT'' project. The called list_factbase_eiffelri utility predicate is contained in the attached ''listFactbase.txt'' file. Add it to the EiffelRISamples4JT and never try it on a big factbase!!!

Description: Display also children that are not referenced directly by an element but have “parent” references to the element.

• If that is not done, expanding upwards can lead to disappearing children. E.g. because packages have no (explicit) children the previously displayed subtree disappears!!!

Aim:

Priority:

Dependencies: language parametric inspector

Description : Display unreferenced 'exheritance' children for the 'classDecl' shown in the screenshot below.

Aim: REAL Language Independence!

Priority: Highest

The example is the same as for the bug free up and down navigation in eiffelri inspector story.

Fixed: See : http://butterbur03.iai.uni-bonn.de:8080/jira/browse/JT-260

Description: Only enable in the Factbase Inspector the context menu and toolbar behaviour that makes sense for the current node.

• For nodes that do not have attached source code → Grey out “Show in Java Editor” / “Show Source Code” and “Show Source Code Comparison”!
• For nodes that have not been transformed → Grey out “Show Source Code Comparison”!

Aim: Avoid errors, confusion and uggly behaviour by disabling what does not make sense.

Priority: High

Description: Let the Factbase inspector work also for non-standard modules.

• Provide a way to specify a module when opening a Factbase Inspector. Display the contents of that module. This (currently) only makes sense in conjunction with an explicit Id or a fully qualified name. Currently, editor contents is always associated to the default module “user”.

[After integrating Tim's extension, which will let us display old versions from a repository, the editors might be associated with repository versions and with the corresponding modules into which the old versions have been imported. Then it would be possible to oen an editor selection in an Inspector associated to the module to which the editor is associated. ]

Aim: Uniform behaviour for all factbases.

Priority: High