This storybook is about smooth multi-way linking of Prolog Console, Java Editor, and Factbase Inspector, giving the user the freedom to work as she wants, not as the system forcs her.

• show node selection in java editor → completed (3. iteration)

• show editor selection in factbase inspector → supposed to be completed (3. iteration) — But does not work !
  • spike: fuzzy java editor selection →
• visual feedback about source linkability → completed (4th iteration)
• source code linking for transformation results → completed (4th iteration)

• source code linking for imported factbases →

Description: Displays in the Java editor the selection corresponding to the node selected in the Factbase Inspector.

Priority: High.

Description: Shows in the Factbase Inspector the topmost element corresponding to the selection from the editor.

Priority: High.

Status: supposed to be completed (in 3. iteration) but does not work!

Description: Determine the closest consistent selection for the current mouse position or for a selection that does not match exactly one element in the java editor.

• Don't try to be perfect in guessing the user's intentions: If it's too hard or ambiguous, simply ask her to make herself a sensible selection.

Aim: This is a “service” functionality that makes others more easy for the user by freeing her of too much mouse klicking.

Priority: Medium.

Dependencies: It should be integrated into show editor selection in factbase inspector and java selection to clipboard

Description: The Factbase Inspector should indicate for each node visually the transformation status and source code availability.

Example query:

Map result = session.queryOnce("ID = " + getId() + ", dirty_tree(ID), slT(ID,_,_)");

Icon	Meaning	Expert Hint → Prolog Query
	Original node ID has source location	not(dirty_tree(ID)), slT(ID,_,_)
	Modified node ID has source location	dirty_tree(ID), slT(ID,_,_)
	Node ID added in a context that has a source location	dirty_tree(ID), not(slT(ID,_,_)), once( (ast_ancestor(ID,Anc),slT(Anc,_,_))
	Original node ID has no source location	not(dirty_tree(ID)), not(slT(ID,_,_))
	Modified node ID has no source location, had source location before	modified_tree_without_source_location(ID)
	Node ID added in a context that has no source location	dirty_tree(ID), not(slT(ID,_,_)), not(once( (ast_ancestor(ID,Anc),slT(Anc,_,_)))

Aim: Maximum feedback for the user. Avoid surprise if user tries to open source code that is not available. Avoid surprise if user tries to open source code that needs to be reengineered first → side-by-side view (see “source code linking for transformation results”).

Priority: High.

Dependencies: —

Description: If the user selects the “Show in Java Editor” context menu item for an added or modified node, open the side-by-side view of the “Save to associated project…” JT Menu item, but focus on the file and enclosing context of the currently selected node. Display in the right-hand-side view (the one for the transformation results) a text selection that corresponds to the node selected in FB Inspector.

Aim: Uniform source code linking for original and transformed nodes. For the transformed ones it is even more important to selectively “see” the effects! Consistency with the display of changes used otherwise (for the “save” functions).

Priority: Very High.

Dependencies: visual feedback about source linkability

Description: Source linking for imported factbases. Enable source code linking from the Factbase Inspector even if the project initially associated to the imported factbase is not open or the factbase resides in a module different from “user”.

Aim: Exporting factbases is mainly done for large projects that are (a) only analysed but not modified and (b) expensive to create at each start of JT. Export / import only saves time if after the export the project is disassociate from a factbase (“the JT nature is taken away”). So we need the ability to make all source code linking independent of the association of a project to the JT nature, otherwise imported projects will only be half as useful, without source code linking!

• When working with imported factbases that are not in the “user” module it is OK to assume that the “user” module contains no relevant facts. Imported factbases that are not in “user” are typically used to compare to other factbases that are in other non-default modules.

Priority: High.

Dependencies: Ability to inspect a factbase that is not in the “user” module.