Difference between revisions of "History behavior"
(→Tool history management) |
|||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
= Overview = | = Overview = | ||
| − | This article | + | 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 = | = Behaviors = | ||
== Main editor history management == | == Main editor history management == | ||
| − | === | + | === Recording === |
| − | === Back and | + | The history manager records a stone (an object representing a cluster, class, feature, etc.) after any of the following actions, unless the stone being processed is the same as the active one: |
| − | === | + | * After clicking on a node of the feature tool or cluster tool. |
| + | * After picking a cluster, class or feature from anywhere in EiffelStudio and dropping it onto a main editor, a main editor tab or some place where a new tab editor is created to load the stone. | ||
| + | * After entering a class or 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 == | == Tool history management == | ||
| − | === | + | Four basic tools and customized tools provide history management. The basic tools are Class, Feature Relation, Diagram and Dependency. Internally there is a stand alone history manager working for each tool. |
| − | === Back and | + | === Recording === |
| − | === | + | The history manager records a stone (an object representing a cluster, class, feature, etc.) after any of the following actions, unless the stone being processed is the same as the active one: |
| − | === | + | * After picking a cluster, class or feature from anywhere in EiffelStudio and dropping it onto the Class, Feature Relationship, Output, C Output, External Output, Error, Warning, Diagram or Dependency tools. |
| + | * After entering a class or feature in the address bar available on the Class, Feature Relation, Diagram and Dependency tools. | ||
| + | * 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: the class based tools (Class, Diagram and Dependency), and the 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. | ||
| + | * In feature relation tool drops or enters in address bar a class that contains a feature A with the same name as current feature B, this class stone will be treated as a feature stone A. | ||
| + | |||
| + | === Back and Forth === | ||
| + | * Choosing an class entry from the list of address bar that belongs to a class based tool or choosing a feature entry from the list of address bar that belongs to a feature based tool will navigate to the stone in current tool. No entry is added in current tool, but possible entry is recorded in other tools if "link tools". | ||
| + | * Choosing a class entry from the list of address tool that belongs to a feature based tool does no effect to current tool, but the class is delivered to class based tools if "link tools" and possible entry is recorded in those tools. | ||
| + | * Clicking "Back" or "Forth" is relatively simply because of the unity of stones in history managers. These behaviors only function on current tool. | ||
| + | === 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, "interface.development_window.link_tools" is added. Upon a True value when a tool receives a stone, it propagate the stone to the rest of 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. | ||
| + | |||
| + | = Conclusion = | ||
| + | * Advantages: Independent history management on each tool that make life clearer; More Class/Feature relation tools are possible in the future; Try to be smart per user demand and does not break much behaviors against EiffelStudio5.7. | ||
| + | * Disadvantages: Would confuse the user, especially when all tools are pulled off, they looks independent but actually sometimes are connected. | ||
Latest revision as of 20:17, 26 March 2007
Contents
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, feature, etc.) after any of the following actions, unless the stone being processed is the same as the active one:
- After clicking on a node of the feature tool or cluster tool.
- After picking a cluster, class or feature from anywhere in EiffelStudio and dropping it onto a main editor, a main editor tab or some place where a new tab editor is created to load the stone.
- After entering a class or 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 basic tools and customized tools provide history management. The basic tools 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, feature, etc.) after any of the following actions, unless the stone being processed is the same as the active one:
- After picking a cluster, class or feature from anywhere in EiffelStudio and dropping it onto the Class, Feature Relationship, Output, C Output, External Output, Error, Warning, Diagram or Dependency tools.
- After entering a class or feature in the address bar available on the Class, Feature Relation, Diagram and Dependency tools.
- 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: the class based tools (Class, Diagram and Dependency), and the 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.
- In feature relation tool drops or enters in address bar a class that contains a feature A with the same name as current feature B, this class stone will be treated as a feature stone A.
Back and Forth
- Choosing an class entry from the list of address bar that belongs to a class based tool or choosing a feature entry from the list of address bar that belongs to a feature based tool will navigate to the stone in current tool. No entry is added in current tool, but possible entry is recorded in other tools if "link tools".
- Choosing a class entry from the list of address tool that belongs to a feature based tool does no effect to current tool, but the class is delivered to class based tools if "link tools" and possible entry is recorded in those tools.
- Clicking "Back" or "Forth" is relatively simply because of the unity of stones in history managers. These behaviors only function on current tool.
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, "interface.development_window.link_tools" is added. Upon a True value when a tool receives a stone, it propagate the stone to the rest of 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.
Conclusion
- Advantages: Independent history management on each tool that make life clearer; More Class/Feature relation tools are possible in the future; Try to be smart per user demand and does not break much behaviors against EiffelStudio5.7.
- Disadvantages: Would confuse the user, especially when all tools are pulled off, they looks independent but actually sometimes are connected.
