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

[WIP] Return events from TextEdit #1137

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

daboross
Copy link
Contributor

@daboross daboross commented Feb 16, 2018

This is still largely incomplete, inefficient, will break when used with certain configurable event transformers and has bugs with line_infos.

Still, it runs! The code demonstrates at least part of the design, and does compile.

Progress so far: I have added TextEvent, changed TextEdit to give Vec, and modified things enough to compile.

Things left to do:

  • handle possible insertions during the deletion path, and deletions during the insertion path. event_transform can turn any event into any other event, so this will be necessary
    • we'll likely just want an "apply_event" function or closure to do this
  • In general, rework code which could be made cleaner under the event design
  • migrate TextBox to return events as well. It currently functions, though, so this could be done in a future PR
  • add support for "side-extending" text boxes. I've got no current idea how to do this, but I'd like to be able to support username/password input boxes which allow the user to type a lot of text, and just scroll to the side when they do this. Might be a future PR.

Besides pure programming, there are a few things I'm not sure what to decide on:

  • decide on whether to use smallstring::SmallString, String, or char for events. We're usually just typing one character at a time, but we might type more. I chose SmallString initially as a compromise, but we might want to do something different.

  • decide on if support for "passing through opaque "data" events" from event transformers is a good idea

  • decide on if event transformers themselves are a reasonable idea.

    I chose to add them because I wanted to uphold "multiple keypress/typing/clicking events should function the same whether they're in the same conrod 'frame' or not". If a TextEdit wrapper was choosing to disallow numbers, the "event transform" allows TextEdit to know the wrapper has done this when it's processing the next bit of input.

Replaces #964.

This is still largely incomplete, inefficient, and will break when used
with certain configurable event transformers.

Still, it runs! It also demonstrates the design I have in mind for doing,
well, this overhaul.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant