Skip to content
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

Open
loganj opened this issue Sep 2, 2016 · 3 comments
Open

MultiKey -> HistoryFrame? #208

loganj opened this issue Sep 2, 2016 · 3 comments
Labels
Milestone

Comments

@loganj
Copy link
Collaborator

loganj commented Sep 2, 2016

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:

  1. Rename MultiKey to HistoryFrame.
  2. Change History so that it's always composed of 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.

@loganj loganj added the API label Sep 2, 2016
@loganj loganj added this to the 1.0 beta milestone Sep 2, 2016
@rjrjr
Copy link
Collaborator

rjrjr commented Sep 2, 2016

I don't think we should make any drastic behavioral changes for 1.0. We're
still learning to live with these.

On Fri, Sep 2, 2016, 6:26 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:

  1. Rename MultiKey to HistoryFrame.
  2. Change History so that it's always composed of 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.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#208, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABzBHX00XKb1ZP7ISHB1WIRnsm00Rf6xks5qmCP1gaJpZM4JztGT
.

@loganj
Copy link
Collaborator Author

loganj commented Sep 2, 2016

WFM. Do think MultiKey should stop being a key though.

@loganj loganj modified the milestones: post-1.0, 1.0 beta Sep 2, 2016
@rjrjr
Copy link
Collaborator

rjrjr commented Sep 2, 2016

Totally agree there. And a name change if we can come up with one. KeyMap?
KeyChain :) ?

On Fri, Sep 2, 2016, 7:16 AM Logan Johnson notifications@github.com wrote:

WFM. Do think MultiKey should stop being a key though.


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#208 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABzBHZXSu2QhMhErRIZU_4ZMsQQw-O9Fks5qmC-hgaJpZM4JztGT
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants