monomer/tasks.md

62 lines
3.2 KiB
Markdown
Raw Normal View History

2020-03-31 06:14:52 +03:00
- 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?
2020-04-07 07:04:55 +03:00
- We already provide this with the State monad and corresponding lenses
- Improve mouse support/current state of mouse and keyboard for event handling
2020-04-11 23:31:55 +03:00
- 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?
2020-03-31 06:14:52 +03:00
- How will long running (i.e., not immediate) user tasks will be handled?
2020-04-28 00:29:28 +03:00
- Using local coordinates for widgets **CANCELLED**
- How do we adjust current displacement?
2020-04-28 01:42:54 +03:00
- Track drawing operations made by a Widget
- Reorganize drawing operations
2020-04-28 00:29:28 +03:00
- Pending
2020-04-07 07:04:55 +03:00
- Stop, think and design
2020-03-31 06:14:52 +03:00
- How should all of this be organized?
- How should modules be layed out?
- What are good interfaces the different parts of the system?
- Does it make sense that handleEvent is the only pure function in a widget?
2020-04-28 00:29:28 +03:00
- Based on the previous design, refactor modules
- Improve hstack/vstack
- If space is 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?
- Could container handle padding and centering?
- Implement styling engine. Think why Maybe Double instead of Maybe Dimension (to handle pixels, percent, etc)
- Improve ergonomics
- Check if advanced type level features would improve the design
- Check what syntax extensions can be abused to make life easier
- Look for ways that allow both lenses and user events to be used in the same widget
- Related to previous, look for ways to simplify widget setup. Default instance with common values?
- Keep sending mouse move event if mouse is away but button is still pressed
- Create layer widget to handle overlays/dialog boxes/tooltips (takes care of overlays)
- Add text selection/editing to textField
- 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)
2020-04-28 01:42:54 +03:00
- Implement SDL_Surface + Cairo backend
- Can we cache some drawing operations?