application context architecture

[urbantumbleweed]

There are a number of keyboard shortcuts that should work differently depending on the current view state of the application. The concept of context has not yet been built into the application and will need to be prior to being able to resolve issues that depend on the the feature.

Examples of issues that depend on context are: #104 and #105.

[PropGit]

Context also affects mouse responses and touch gestures (when on touch-interface devices).

[PropGit]

There may also be logical groups of keys that can be defined and those groups have the same meaning in different contexts, while no meaning in other contexts.

[PropGit]

Definition of Key Groups and Contexts:

Key Groups:
[Logical groups of keys that have similar meaning in certain contexts]

• Text
  • Includes 190+ key combinations that emit glyphs by themselves (0x20..0x7E, 0xA0..0xFE, and most Unicode glyphs)
  • Alt-# combinations
  • FUTURE: Propeller support will add an additional 58 glyph codes which are emitted for certain key combinations
• Text Tab
  • Tab (0x08)
• Text Enter
  • Enter (0x13)
• Text Edit and Navigation
  • Left, Right, Up, Down, Ctrl-Left, Ctrl-Right, Shift-Left, Shift-Right, Ctrl-Shift-Left, Ctrl-Shift-Right, Alt-Left, Alt-Right, Shift-Up, Shift-Down, Ctrl-A, Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Up, Ctrl-Down, Ctrl-Home, Cmd-Up, Ctrl-Search-Left, Ctrl-End, Cmd-Down, Ctrl-Search-Right, Home, End, Shift-Home, Shift-End, Ctrl-Shift-Home, Ctrl-Shift-End, PageUp, PageDn, Shift-PageUp, Shift-PageDn, Bksp
• Source Entry
  • Includes Text plus Text Enter plus special Tab, Shift-Tab (emits or removes groups of spaces)
• Source Edit and Navigation
  • Includes Text Edit and Navigation plus Ctrl-D, Ctrl-Z, Ctrl-Shift-Z, Ctrl-F, Ctrl-G, Ctrl-Shift-G, F3, Shift-F3, Ins, Del, Ctrl-Tab, Ctrl-Shift-Tab
• Operation
  • Ctrl-O, Ctrl-N, Ctrl-S, Ctrl-Shift-S, Ctrl-P, Ctrl-I, F6, Search-6, Ctrl-T, F7, Search-7, Ctrl-R, F9, Search-9, F1, Search-1
  • FUTURE: F8, Search-8, Ctrl-M, plus more future Propeller support functions
• App Navigation
  • Ctrl-<, Ctrl->, Esc
• Prompt Navigation
  • Tab, Shift-Tab, Esc, Enter

Contexts:
[Only the Key Groups listed below are active in each context]

• Editor - Focus is on the source editor (most common)
  • Source Entry keys affect source code directly
  • Source Edit and Navigation keys move cursor around in source code, affect view port, and switch to other source
  • Operation keys trigger app functions (New, Save, Download, Identify, etc.)
  • App Navigation keys switch focus to other contexts; Esc sends focus back to Editor
• Terminal - Focus is on the Transmit or Receive Pane of Debug Terminal
  • Text, Text Tab, and Text Enter - If focus is on Receive Pane, focus switches to Transmit Pane and emits text characters
  • Text Edit and Navigation - moves around in text with keyboard
  • Operation keys trigger app functions (New, Save, Download, Identify, etc.)
  • App Navigation keys switch focus to other contexts; Esc sends focus back to Editor
• Terminal Status Panel
  • Space/Enter activates focused field
  • Cursor keys select list field items (such as baud rate)
  • Prompt Navigation - switches focus to other fields
  • Operation keys trigger app functions (New, Save, Download, Identify, etc.)
  • App Navigation keys switch focus to other contexts; Esc sends focus back to Editor
• Project/File View
  • (TBD)
  • App Navigation keys switch focus to other contexts; Esc sends focus back to Editor
• Memory Map
  • (TBD)
  • App Navigation keys switch focus to other contexts; Esc sends focus back to Editor
• Prompt
  • Prompt Navigation key switch focus to other fields of the prompt and accept (Ok) or reject (Cancel) the prompt

[urbantumbleweed]

@PropGit After much thought and discussion on this issue a concept has emerged that we are proving internally. Here is a summary of the thought processes thus far.

The current state of the application does not include the concept of context. This means that event handlers are registered at the root level of the application and are triggered universally during a user's session. For this reason, pressing the 'tab' key while viewing a modal would still affect the text editor that is opened behind the modal while it may or may not toggle through the modal button options.

Additionally, issue #276 highlights the need for us to maintain a history of context state. For example, while canceling on an "overwrite" prompt, we are taken back to a save prompt but not necessarily the save prompt that led up to the "overwrite" prompt; this happens because we are not using history to return to the previous dialog but instead have dom elements wired to handlers and therefore cannot determine which context we came from.

So as we got to thinking about this, our first approach was to create a context stack with context objects including both type and metadata (used for populating views and handlers). The idea here is that context state could be added to and popped from the stack, resolving the history issue of the "overwrite" dialog. This seemed to solve part of our problem, but it did not provide us with an answer on the need to change the meaning of a specific event (i.e tabbing) in different contexts.

All in all we considered a couple different ideas, all of which required us to architect a system to manage context state, track view hierarchy, and manage history. While the initial ideas came close in terms of resolving the current problem, it would be at the expense of complicating the code-base and reducing maintainability long-term. So, after much deliberation we came to realize that this problem relates very closely to that of webpages and could be solved through giving each "context" a separate route. However, being in a chrome application removes the APIs we would use to do routing.

While investigating our options we considered a well established open-source library called 'React-Router'. We are very optimistic about this direction. By default React Router uses the html history api, but it has the ability to manage its own state history object in memory. Furthermore, it simplifies our idea of contexts by using 'routes', which in our case are simply various states of the application. We can use the routes to determine what set of functionality is available to the current view.

After taking a look throughout the weekenend and testing the library within the confines of a packaged Chrome application, we have confirmed that this is promising avenue to pursue. This is a major undertaking and will not be implemented by the end of this sprint. It is clear there are many things that could change regarding the way we construct our views and handle events. We will be in a better position to discuss this by the demo, but will likely need another sprint cycle to complete the implementation.

[PropGit]

@urbantumbleweed - Awesome work guys! Sounds like you really dove into this as a team and explored things deeply. I like the sound of the solution you are headed towards. Thank you for all the details.

It is clear there are many things that could change regarding the way we construct our views and handle events.

This makes me nervous. Maybe you can fill me in on what you mean here in our meeting.

Regarding using React-Router routes to keep context history, something occurred to me to be careful about. (I'm not sure it will be a problem, but thought I should pose the question). Will this have any effect on inter-session behavior?

• For example, right now if you do a Save As and enter an already existing filename, the app presents the Overwrite prompt... but if the app is closed at that moment (without acknowledging the prompt), restarting brings it back in a different state (the overwrite prompt is not there).
  What I'd want you to be thinking of and protecting against are situations like this that would perhaps unintentionally preserve state and context across abortive actions (app closes from user or system action, or some other system or app error that abruptly aborts a call chain of some sort, whether real or logical).

[urbantumbleweed]

@PropGit: We are going to discuss this further on our call Wednesday when we can the discuss technical implications in regards to changing views.

One thing to keep in mind about React-Router state is that the history object is only in memory and will behave similarly to how undo-redo history works on documents.

We will discuss further and if needed on our call.