Difference between revisions of "Rodin Keyboard"
From Event-B
Jump to navigationJump to searchimported>Nicolas m (in) |
imported>Nicolas m (→Specification) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
== Definitions == | == Definitions == | ||
| − | * '''Translator''': mechanism that transforms a '''source chain''' into a '''target chain | + | * '''Translator''': mechanism that transforms a '''source chain''' into a '''target chain''' |
| − | * '''Token''': | + | * '''Token''': character sequence in a chain that is of one lexical kind |
* '''Transformation Rule''': specification of the modification of a token sequence into another token sequence | * '''Transformation Rule''': specification of the modification of a token sequence into another token sequence | ||
| − | * '''Combination''': specification of a transformation from a single token into another single token | + | * '''Combination''': specification of a transformation from a single input token into another single output token |
| + | * There are 3 kinds of lexical entities in a source chain: | ||
| + | ** '''spacings''' (space, tabulation, end of line, ...) | ||
| + | ** '''text symbols''' (identifier-like) | ||
| + | ** '''math symbols''' (all other symbols) | ||
== Requirements == | == Requirements == | ||
| Line 25: | Line 29: | ||
# The translator must support contributed combinations | # The translator must support contributed combinations | ||
# The translator must avoid non-termination due to combination contributions | # The translator must avoid non-termination due to combination contributions | ||
| + | #: This will be enforced by a stronger requirement: the translation must be idempotent for any given input chain, caret position and set of combinations | ||
| + | # The translator must check that combination input tokens are either text or math symbols | ||
| + | # The translator must not process a token that has the caret over it | ||
| + | # Once a symbol has been translated, it can never be translated back into its original text form (even virtually during a translation) | ||
| − | |||
[[Category:Design]] | [[Category:Design]] | ||
Revision as of 15:51, 28 January 2014
The Rodin Keyboard is an extensible keyboard for inputing mathematical formula (in Unicode). The Rodin keyboard provides the following facilities:
- A ModifyListener (RodinModifyListener) that can be attached to a SWT widget. When the content of the widget is modified, the keyboard reacts and translate the content accordingly. Currently, RODIN Keyboard supports Text and StyledText widget.
- An utility class Text2MathTranslator with a static method translate(String) for manually translating any string (or sub-part of a string) into mathematical formula.
- An Eclipse View called Rodin Keyboard View which provides an text input area which will translate the input text into mathematical formula. This View can be found under category RODIN.
The Rodin Keyboard however does not contain any pre-defined translation rules for any mathematical symbols. Instead, this task is left for the developers who want to declare different "keyboards" corresponding to the mathematical language that they want to use. Moreover, different combinations can be used to enter the same mathematical symbols.
Currently, there are two keyboards available:
- Standard keyboard for Event-B.
- LaTeX-style keyboard for Event-B.
Specification
Definitions
- Translator: mechanism that transforms a source chain into a target chain
- Token: character sequence in a chain that is of one lexical kind
- Transformation Rule: specification of the modification of a token sequence into another token sequence
- Combination: specification of a transformation from a single input token into another single output token
- There are 3 kinds of lexical entities in a source chain:
- spacings (space, tabulation, end of line, ...)
- text symbols (identifier-like)
- math symbols (all other symbols)
Requirements
- The translator must be able to deal both with static translation of a whole chain and on the fly translation of a user input chain (characters being typed in continuously)
- The translator must help maintain a coherent caret position
- The translator must keep spacing unchanged
- The translator must support contributed combinations
- The translator must avoid non-termination due to combination contributions
- This will be enforced by a stronger requirement: the translation must be idempotent for any given input chain, caret position and set of combinations
- The translator must check that combination input tokens are either text or math symbols
- The translator must not process a token that has the caret over it
- Once a symbol has been translated, it can never be translated back into its original text form (even virtually during a translation)
