monomer/tasks.md

- 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 laid 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 abandoned
    - 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)
  - 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
  - Create Dropdown
  - 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?
      - Yes! All these properties are staying
    - Could container handle padding and centering?
      - No, staying how it is now. It does not disallow having a container, of course
    - Implement styling engine. Think why Maybe Double instead of Maybe Dimension (to handle pixels, percent, etc)
      - Handle this with a widget that takes care of assigning space
    - Improve FixedSize. Consider adding min/max width/height
      - Not for the moment
  - Improve ergonomics
    - https://hackage.haskell.org/package/string-interpolate
    - Check if advanced type level features would improve the design
    - Check what syntax extensions can be abused to make life easier
      - https://limperg.de/ghc-extensions/#basic-patterns
      - https://limperg.de/ghc-extensions/#datakinds
      - Maybe -> https://typeclasses.com/extensions-intro
    - Look for ways that allow both lenses and user events to be used in the same widget
      - Most likely through a Default instance
    - Related to previous, look for ways to simplify widget setup. Default instance with common values?
    - Find way of providing instance config (style, visibility, etc) before providing children (some sort of flip operator)
      - Just provide `style` after children. SwiftUI does it this way
    - Fix border drawing. Handle simple case (more efficient)
  - Fix scroll click navigation
    - Highlight bar when mouse over
    - Highlight handle when mouse over
    - Handle clicks in bar outside handle
    - Handle handle drag
    - Mouse over on overlapping axis gives precedence to vertical scroll
  - Keep sending mouse move event if mouse is away but button is still pressed
    - Handle mouse enter/leave window events
  - Add support for scroll requests from children
  - Improve Dropdown
    - Expose customizable interface
    - Request scroll when needed
    - Validate Maybe values are supported
    - Create nullable version which takes care of fmapping traversable with Just
  - Check why vstack fails when using [spacer, listView]
  - Remove status from Click event. Add ButtonPressed and ButtonReleased events
  - Change order of parameters. We should always pass _old_ before _new_
  - Unify criteria for instantiation
    - Component name without underscore receives parameters positionally
    - Component name with underscore receives Config instance
  - If two flexible sized and one remaining elements are in a vstack, problems arise
  - Add renderer parameter to resize. It will be needed for auto adjustable Label and to handle ellipsis in texts
    - Maybe creating a record of functions would be useful?
    - Besides calcTextBounds, we need isClipboardPaste and isClipboardCopy which could be customizable
      - Customization discarded. What would it be needed for?
  - Try to unify path handling on widgetFind and widgetNextFocusable
    - This is cancelled fo the moment. I can't find a good reason for doing it.
    - WidgetEnv was added as a parameter for completeness sake
    - This is also needed for _widgetPreferredSize and _widgetResize
    - Generalize the "startFrom" concept of _widgetFind (and also validate it's actually well/fully implemented)
  - Should Resize be restored? -> Restored
  - Make sure enabled/visible attributes are being used
    - This needs modifying WidgetContext (former PathContext) to include visible and enabled attributes
  - Move widgetPath into WidgetInstance (do it in init/merge)
    - Move currentPath into WidgetInstance
    - Move focusedPath and targetPath to WidgetEnv
    - Visible and enabled would get updated on init/merge
  - Format code!

- Pending
  - Add testing
    - Delayed until this point to try to settle down interfaces
    - Validate stack assigns space correctly
    - Use weight to control allocations
  - Look for opportunities to reduce code duplication (CompositeWidget and BaseContainer)
  - Add header in all files, indicating license and documenting what the module does
  - Improve styling options. Handle cases for Normal, Hover, Focused with independent background and border
  - Add support for dashed borders
  - Create self rendered version of dropdown and list
    - Show listview in appropriate location (if dropdown is at bottom, the listView should be up)
  - Add config for Label to choose from: Overflow | Cut (better name?) | Ellipsis
  - Create Checkbox
  - Create Radio
  - Create Slider
  - Create Dial
  - Improve textField
    - Add text selection/editing to textField
    - Find non visible character that returns correct height if input is empty
  - Request text input when text field gets focus (required for mobile)
    - Also set TextInputRect
  - Use newtypes whenever possible
  - Compare Cairo/Skia interfaces to make Renderer able to handle future implementations
  - Create Layer widget
  - Create Dialog
    - Make sure that focus change requests do not leave overlay if active (most likely an if clause is needed in handleFocusChange)
  - Create File Selector
  - Create Color Selector
  - Create Layout with width/heights specified in percents
  - Create Tooltip component. It just wraps a given component and draws the tooltip with renderOverlay
  - 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](https://github.com/maoe/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