me/iced
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Fix spelling and grammar in ROADMAP

Browse source 
Co-Authored-By: memoryruins <memoryruinsmusic@gmail.com>
This commit is contained in:
Héctor Ramón 2019-10-25 22:44:17 +02:00 • committed by GitHub
parent d66dc4aee6
commit e3cf59fd99
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

12
ROADMAP.md
View file

@ -74,7 +74,7 @@ It exposes a renderer-agnostic `Application` trait that can be implemented and t
Finally, `iced` unifies everything into a simple abstraction to create cross-platform applications: Finally, `iced` unifies everything into a simple abstraction to create cross-platform applications:
- On native, it uses `iced_winit` and `iced_wgpu`. - On native, it uses `iced_winit` and `iced_wgpu`.
- On web, it uses `iced_web`. - On the web, it uses `iced_web`.
This is the crate meant to be used by __end-users__. This is the crate meant to be used by __end-users__.
@ -101,7 +101,7 @@ When it comes to `iced_native`, we may need to add the concept of _event propaga
When it comes to `iced_wgpu`, we should be able to use scissoring and transformations. [`wgpu`] has a [`RenderPass::set_scissor_rect`] that should work nicely. When it comes to `iced_wgpu`, we should be able to use scissoring and transformations. [`wgpu`] has a [`RenderPass::set_scissor_rect`] that should work nicely.
The main issue here will be [`wgpu_glyph`], which is used currently to render text primitives. [`wgpu_glyph`] is powered by [`glyph-brush`], which caches glyphs to render text very fast. However, the current cache model does not seem to be composable (i.e. once you issue a draw call the cache is purged). We will need to change it (and potentially contribute) to accomodate for this use case. The main issue here will be [`wgpu_glyph`], which is used currently to render text primitives. [`wgpu_glyph`] is powered by [`glyph-brush`], which caches glyphs to render text very fast. However, the current cache model does not seem to be composable (i.e. once you issue a draw call the cache is purged). We will need to change it (and potentially contribute) to accommodate for this use case.
[`RenderPass::set_scissor_rect`]: https://docs.rs/wgpu/0.3.0/src/wgpu/lib.rs.html#1246-1248 [`RenderPass::set_scissor_rect`]: https://docs.rs/wgpu/0.3.0/src/wgpu/lib.rs.html#1246-1248
[`glyph-brush`]: https://github.com/alexheretic/glyph-brush [`glyph-brush`]: https://github.com/alexheretic/glyph-brush
@ -153,7 +153,7 @@ Most applications need to perform work in the background, without freezing the U
We can let users return an asynchronous action (i.e. a future) producing a `Message` in `Application::update`. The runtime will spawn each returned action in a thread pool and, once it finishes, feed the produced message back to `update`. This is also how [Elm] does it. We can let users return an asynchronous action (i.e. a future) producing a `Message` in `Application::update`. The runtime will spawn each returned action in a thread pool and, once it finishes, feed the produced message back to `update`. This is also how [Elm] does it.
When it comes to implementing this, [`winit`] already supports user-specific events that can be sent from another thread. Accomodating `iced_winit` for this functionality should not be too complicated. When it comes to implementing this, [`winit`] already supports user-specific events that can be sent from another thread. Accommodating `iced_winit` for this functionality should not be too complicated.
[Elm]: https://elm-lang.org/ [Elm]: https://elm-lang.org/
@ -196,7 +196,7 @@ The challenge here is designing the public API of subscriptions, so users can bu
### Layers ### Layers
Currently, Iced assumes widgets cannot be laid out on top of each other. We should implement support for multiple layers of widgets. Currently, Iced assumes widgets cannot be laid out on top of each other. We should implement support for multiple layers of widgets.
This is a necessary feature to implement many kind of interactables, like dropdown menus, select fields, etc. This is a necessary feature to implement many kinds of interactables, like dropdown menus, select fields, etc.
`iced_native` will need to group widgets to perform layouting and process some events first for widgets positioned on top. `iced_native` will need to group widgets to perform layouting and process some events first for widgets positioned on top.
@ -207,12 +207,12 @@ Allow widgets to request a redraw at a specific time.
This is a necessary feature to render loading spinners, a blinking text cursor, GIF images, etc. This is a necessary feature to render loading spinners, a blinking text cursor, GIF images, etc.
[`winit`] allows controlling the event loop in a flexible way. We may be able to use [`ControlFlow::WaitUntil`](https://docs.rs/winit/0.20.0-alpha3/winit/event_loop/enum.ControlFlow.html#variant.WaitUntil) for this purpose. [`winit`] allows flexible control of its event loop. We may be able to use [`ControlFlow::WaitUntil`](https://docs.rs/winit/0.20.0-alpha3/winit/event_loop/enum.ControlFlow.html#variant.WaitUntil) for this purpose.
### Canvas widget ### Canvas widget
A widget to draw freely in 2D or 3D. It could be used to draw charts, implement a Paint clone, a CAD application, etc. A widget to draw freely in 2D or 3D. It could be used to draw charts, implement a Paint clone, a CAD application, etc.
As a first approach, we could expose the underlying renderer directly here, and couple this widget with it ([`wgpu`] for now). Once [`wgpu`] gets WebGL or WebGPU support, this widget will be able to run on web too. The renderer primitive could be a simple texture that the widget draws to. As a first approach, we could expose the underlying renderer directly here, and couple this widget with it ([`wgpu`] for now). Once [`wgpu`] gets WebGL or WebGPU support, this widget will be able to run on the web too. The renderer primitive could be a simple texture that the widget draws to.
In the long run, we could expose a renderer-agnostic abstraction to perform the drawing. In the long run, we could expose a renderer-agnostic abstraction to perform the drawing.