monomer/tasks.md
2020-09-26 01:44:54 -03:00

224 lines
12 KiB
Markdown

- 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 widgetUpdateSizeReq 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!
- Use newtypes whenever possible
- Make types Lens friendly
- Use lenses whenever they make the code clearer
- Use Lenses for Main/Core.hs' updateInputStatus
- Create Lenses for Graphics/Types.hs
- Make BaseWidget and BaseContainer use a custom type instead of just Widget. Maybe also rename them?
- Improve styling options. Handle cases for Normal, Hover, Focused with independent background and border
- Add support for dashed borders
- NanoVG does not seem to support this
- If we ever move to Skia, reconsider
- Fix ListView keyboard navigation
- Handle mouse entering/leaving the window
- Rename policy... to policyW/H
- Create Checkbox
- Create Radio
- Reorganize Drawing (move helpers to bottom)
- Create Image
- Add config for Label to choose from: Overflow | Cut (better name?) | Ellipsis
- DrawStyledBackground should draw borders after widget content
- Request text input when text field gets focus (required for mobile)
- Also set TextInputRect
- Improve textField
- Add text selection/editing to textField
- Find non visible character that returns correct height if input is empty
- 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
- Further textField improvements
- Handle long text and cursor position
- Scissor needed?
- Add support for changing cursor position with mouse click
- Rethink Image handling
- Should image component keep a copy around?
- Should it be provided to renderer every time and, if removed, put back in the list?
- Otherwise, when graphics memory is exhausted new images will not be added (until the widget is disposed)
- Rethink the idea of global theme in WidgetEnv
- Add option to render inner rounded borders with normal outer ones
- Further textField improvements
- Add support for validation
- Add max length limit
- Add range limit
- Initialize validators (maybe input is invalid and that needs to be signaled)
- Think widget config in a similar way to style config (combinator functions)
- Pending
- textField should support textFieldV and validInputV
- Rethink focus handling. Maybe return list of all focusable elements? Currently shift-tab is not possible
- http://hackage.haskell.org/package/data-clist-0.1.2.3
- Compare Cairo/Skia interfaces to make Renderer able to handle future implementations
- Can _wiChildren be removed from Widget and only be kept in Container?
- Rename spacer
- Make sure that focus change requests do not leave overlay if active (most likely an if clause is needed in handleFocusChange)
- Fix dropdown issues
- Show listview in appropriate location (if dropdown is at bottom, the listView should be up)
- Implement OnChange/OnChangeReq for listView and dropdown (currently they only implement the Idx versions)
- Create Layer widget
- Create Dialog
- Create Tooltip component. It just wraps a given component and draws the tooltip with renderOverlay
- Add testing
- Delayed until this point to try to settle down interfaces
- Validate stack assigns space correctly
- Use weight to control allocations
- Refactor modules where consistency is lacking
- Add header in all files, indicating license and documenting what the module does
- Add examples
- Add user documentation
Maybe postponed after release?
- Add options to image widget (stretch/crop/etc)
- Add support for urls to image widget
- Add options to label/button (ellipsis/cut)
- Further textField improvements
- Handle mouse selection
- Handle undo history
- Create numeric wrapper that allows increasing/decreasing with mouse
- Create Slider
- Create Dial
- Create self rendered version of dropdown and list
- Create File Selector
- Create Color Selector
- Create Layout with width/heights specified in percents
- 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
- Look for opportunities to reduce code duplication (CompositeWidget and BaseContainer)
- Check if using [lifted-async](https://github.com/maoe/lifted-async) is worth it
- Implement SDL_Surface + Cairo backend
- Can we cache some drawing operations?