History behavior

Revision as of 21:14, 1 February 2007 by Ted (Talk | contribs)


Overview

This article focuses on history managements of the main editors and various tools in EiffelStudio 6.0 with docking. The goal is to clarify the history behaviors, and the implementation should follow this requirement. Here we do not discuss history management tool specific, i.e. history of diagram operations and history of metric calculations.

Behaviors

Main editor history management

Recording

  • The history manager records a stone (an object representing a cluster, class or feature etc.) after the following behavior except that the processing stone is the same as the active one.
  • Click on a node of the feature tool and cluster tool.
  • Pick a cluster/class/feature from anywhere in EiffelStudio and drop onto a main editor, a main editor tab or places where a new tab editor is created to load the stone.
  • Enter a class/feature in the main address tool bar.

Back and Forth

  • Choosing an entry from the list of address tool will navigate the active stone to the one chosen, no history removing.
  • With a stone to be activated, the history manager first try to look for an editor containing an equivalent stone, if fails, it takes current editor to load the given stone, otherwise, the editor containing a proper stone is activated and navigated to the right position. Here, an equivalent stone means a stone with identical underlying class, i.e. a feature stone {HASH_TABLE}.has is equivalent to a class stone {HASH_TABLE}.

Removal

  • The number of elements reaches the maximum number a user specified. A recording behavior removes the oldest element.
  • When the active stone is not the last one in the history, a recording behavior, before a real extending, removes all elements after the active stone.

Modification

  • Back and Forth modifies an active stone with its location and formatter, that are the line number of the text viewing and the active formatter.

Tool history management

Four tools provide history management. They are Class, Feature Relation, Diagram and Dependency. Internally there is a stand alone history manager working for each tool.

Recording

  • The history manager records a stone (an object representing a cluster, class or feature etc.) after the following behavior except that the processing stone is the same as the active one.
  • Pick a cluster/class/feature from anywhere in EiffelStudio and drop onto tools including Class, Feature Relationship, Output, C Output, External Output, Error, Warning, Diagram and Dependency.
  • Enter a class/feature in the address tool bar available on tools of Class, Feature Relation, Diagram and Dependency.
  • The recording takes place in a functioning tool which is chosen and activated by the PND or address entering behavior (or all tools needed, See Compliant Solution/Behavior). The activation behavior follow this default rule: a class stone activates a Class tool, a feature stone activates Feature Relation tool.
  • There are basically two kinds of history managed tools, one is class based tool, Class, Diagram and Dependency, and the other is feature based tool, Feature Relation. A class based tool only records class stones (not feature stones any more). And a feature based tool only records feature stones.

Back and Forth

Removal

  • The number of elements reaches the maximum number a user specified. A recording behavior removes the oldest element.
  • When the active stone is not the last one in the history, a recording behavior, before a real extending, removes all elements after the active stone.

Compliant Solution/Behavior

  • In order to keep similar behavior to EiffelStudio5.7, a new preference, "tools.context_tool.propagate_stone" is added. Upon a True value when a tool receives a stone, it propagate the stone to the other history managed tools who will extend their own history if needed. Otherwise, the tool simply decide which tool the stone should go and deliver it.