-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MultiKey -> HistoryFrame? #208
Comments
I don't think we should make any drastic behavioral changes for 1.0. We're On Fri, Sep 2, 2016, 6:26 AM Logan Johnson notifications@github.com wrote:
|
WFM. Do think MultiKey should stop being a key though. |
Totally agree there. And a name change if we can come up with one. KeyMap? On Fri, Sep 2, 2016, 7:16 AM Logan Johnson notifications@github.com wrote:
|
There's a lot of confusion around how MultiKeys and other keys interoperate. In practice, an app that uses MultiKeys will likely only want MultiKeys in its History. (Somebody stop me if I'm wrong, here). There's a 0,1,N thing happening.
The right thing to do here may be:
MultiKey
toHistoryFrame
.HistoryFrames
.This would provide more clarity and structure around History and orient the API toward the common/general case.
A confounding factor is defining the behavior of the navigation methods when called with a simple key. This is the main reason defining MultiKeys is largely left as an exercise for the app author today.
The text was updated successfully, but these errors were encountered: