monomer/tasks.md
2020-06-24 00:45:57 -03:00

6.7 KiB

  • Done

    • Check events only for interested widgets (use focus for keyboard and region for mouse)
    • Add handling of disabled widget nodes
    • Add handling of custom external actions for widgets
    • Do something with return of custom handlers (the exact same thing we do with event handlers)
    • Add scroll support
    • Add hstack/vstack containers
    • Improve input (keyboard) handling
    • Implement copy/paste
    • Add HiDPI handling
    • Handle window resize
    • Improve handling of Color (turn to 0.0 to 1.0 instead of 0 to 255? only do it for alpha?)
    • Add handling of non visible widget nodes
    • Handle widget fixed size
    • Add good looking caret to textField
    • Add support for onFocus/onBlur
    • Maybe we don't need this and we can get by with position in render function?
      • Add support for onEnter/onLeave (keep track of previous active widgets)
      • We probably need it for drag&drop
    • How is the user going to provide state updates?
      • We already provide this with the State monad and corresponding lenses
    • Improve mouse support/current state of mouse and keyboard for event handling
    • Make handleEvent run inside MonadState (required to update user provided lenses) CANCELLED
    • Add logic that allows widgets to update user state
    • Does it make sense to avoid lenses internally, given that we already include the dependency?
    • How will long running (i.e., not immediate) user tasks will be handled?
    • Using local coordinates for widgets CANCELLED
      • How do we adjust current displacement?
    • Track drawing operations made by a Widget
      • Reorganize drawing operations
    • Stop, think and design
      • How should all of this be organized?
      • How should modules be layed out?
      • What are good interfaces for the different parts of the system?
      • Does it make sense that handleEvent is the only pure function in a widget?
      • Based on the previous design, refactor modules
    • Current massive refactor
      • Replace Tree with Containers' Tree
      • Fix issue with event handling (click makes everything disappear)
      • Fix focus situation (remove _focusRing and replace with single focus, then use _widgetNextFocusable)
      • Provide focus to render (needed by textField)
      • Check if resize children still makes sense (maybe the widget itself can resize on the corresponding event?)
      • Handle SetFocus request
      • Check if WidgetState is really needed
        • Maybe Data.Dynamic can be used, but currently abadoned
      • Rethink Tree.Path import
      • Clean up Seq imports
      • Where can we use Seq? Does it make sense to use it everywhere? What about Traversable?
      • Reorganize Common Types. What do other projects do? They should be simple to import and use
    • Create composite widget, allowing isolated event handling and UI creation
    • Create application widget, based on composite
      • Remove UserTask concept, handle it as WidgetTask
    • Support long running tasks that can provide events through a channel
    • Add Multiple response support (extra value in EventResponse)
    • Try to remove all those Typeable requirements in CompositeWidget
      • Removing Monad from Widget/WidgetInstance was good enough
      • Some Typeable constraints still needed, but user should not need to do anything
    • Provide a way of initializing the application
      • Probably taking a simple event that is relayed to appEventsHandler is enough?
    • Implement Global keys
    • Improve merge process
    • Add a way to get path of widget given an id, and provide a method to send a message/event (most likely, a new Request kind)
    • Rename EventResult to something more accurate
      • Replace resultWidget and friends with non-Maybe versions (update widgets)
  • Pending

    • Add renderLast function to Renderer, which delays rendering until the first pass is done
      • Futher calls to renderLast should not be ignored (tooltip on dropdown menu?)
      • A handleDelayedRendering also needs to be added
      • We also need a way of receiving events on upper layers
      • All this is needed for dropdowns, but it's also useful for tooltips
    • Improve hstack/vstack
      • If available space is greater than requested, do not apply resizing logic
    • Does a styling engine make sense or doing something similar to Flutter is simpler?
      • Does keeping style for some things (fixed width/height) make sense?
      • Could container handle padding and centering?
      • Implement styling engine. Think why Maybe Double instead of Maybe Dimension (to handle pixels, percent, etc)
      • Improve FixedSize. Consider adding min/max width/height
    • Improve ergonomics
    • Keep sending mouse move event if mouse is away but button is still pressed
    • Fix scroll click navigation
    • Should Resize be restored?
    • Create layer widget to handle overlays/dialog boxes/tooltips (takes care of overlays)
    • Add text selection/editing to textField
    • Request text input when text field gets focus (required for mobile)
    • Add testing
      • Delayed until this point to try to settle down interfaces
    • Look for opportunities to reduce code duplication (CompositeWidget and BaseContainer)
    • Try to unify path handling on widgetFind and widgetNextFocusable
    • Create Checkbox
    • Create Radio
    • Create Dropdown
    • Create Color Selector
    • Create Dialog
    • Create File Selector
    • Drag & drop for user (add attribute indicating if component supports being source/target)
      • Add new request types (drag started, drag stopped, drag cancelled)
      • Add new events (drag hover)
      • SDL supports Drag and Drop integration with OS
    • Implement SDL_Surface + Cairo backend
      • Can we cache some drawing operations?
    • Check if using lifted-async is worth it
    • Can we generalize _widgetFind?
      • To find widgetInstances that need a specific kind of event (entities that need timeStep)
      • Instead of passing Point, pass WidgetQuery ADT. Currently it would support... PointQuery
      • Do we need this?
      • It is implemented in chore/unify-query. I honestly don't think it's an improvement