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

All widgets/primitives should take an object #20

Open
4 of 6 tasks
smithfarm opened this issue Sep 25, 2017 · 0 comments
Open
4 of 6 tasks

All widgets/primitives should take an object #20

smithfarm opened this issue Sep 25, 2017 · 0 comments
Assignees
Labels

Comments

@smithfarm
Copy link
Owner

smithfarm commented Sep 25, 2017

mfile-www implements a number of "widgets", or primitives such as dform, dmenu, etc. for displaying "pages of content" and accepting user input.

With the advent of the target stack, there is a need to standardize how the "content" is provided to the widget. It will be good if each widget expects to receive an object. The exact contents of the object will differ from widget to widget, but it will be an object.

The start method of each primitive will take two arguments:

  1. the content object, called "state"
  2. an optional options object, called "opts"

When stack.push or stack.pop is called, the caller will provide these two arguments, and stack.push/pop will pass them on to the widget's start function.

If no state is given on stack.pop() - i.e. state === undefined - the state will be taken from the stack.

  • dmenu
  • dform
  • dbrowser
  • dnotice
  • dtable
  • drowselect
@smithfarm smithfarm self-assigned this Sep 25, 2017
smithfarm added a commit that referenced this issue Sep 25, 2017
No matter what the primitive (dmenu, dform, dtable etc.), the start
function takes two arguments: state and opts.

References: #20
Signed-off-by: Nathan Cutler <[email protected]>
smithfarm added a commit that referenced this issue Sep 25, 2017
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

1 participant