Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant