Resolves#1780
BREAKING CHANGE: Disabling `default-features` will now disable layout
cache, which can have a negative impact on performance.
`Layout::init_cache` and `Layout::DEFAULT_CACHE_SIZE` are now only
available if `layout-cache` feature is enabled.
Resolves#1775
BREAKING CHANGE: Custom backends now have to implement `Backend::Error`
and `Backend::clear_region`. Additionally some generic `Backend` usage
will have to explicitly set trait bounds for `Backend::Error`.
The Clippy check for this (missing_const_for_fn) is already enabled, but
catches more cases in upcoming toolchain versions.
This is part of the work to unblock #1727
### This commit does the following:
- Adds `#[no_std]` to `lib.rs`.
- Adds `extern crate std;` to `lib.rs`.
- Updates `ratatui-core` to explicitly `use` items from std and alloc.
- Prefers `use`-ing alloc over std when possible.
### Explanation:
This allows usages of `std` in `ratatui-core` to be clearly pointed out
and dealt with individually.
Eventually, when `std` is to be feature gated, the associated commit
will be much cleaner.
We don't anticipate removing or deprecating the type alias in the near
future, but it is recommended to update your imports to use the new
name.
Added a VerticalAlignment enum to make the API more consistent. We don't
have a specific use case for it yet, but it's better to add it now and
be able to use it in the future.
BREAKING-CHANGE: The `Alignment` enum has been renamed to
`HorizontalAlignment` to better reflect its purpose. A type alias has
been added to maintain backwards compatibility, however there are some
cases where type aliases are not enough to maintain backwards
compatibility. E.g. when using glob imports to import all the enum
variants. This should not affect most users, but it is recommended to
update your imports to use the new name.
```diff
- use ratatui::layout::Alignment;
+ use ratatui::layout::HorizontalAlignment;
- use Alignment::*;
+ use HorizontalAlignment::*;
```
I was swayed by the arguments about this made by the compiler team In
<https://github.com/rust-lang/compiler-team/issues/750> and decided to
look at how this organization affects ratatui. I found this reduces the
number of lines across the codebase by about 350 and makes the imports
more readable and definitely more greppable as you usually only have
to read a single line. I've found in the past that maintaining imports
regularly leads to merge conflicts which have to be resolved by hand
and this change should reduce the likelihood of that happening.
Main change is in rustfmt.toml, and the rest is just the result of
running `cargo xtask format`.
While implementing this, cargo machete brings up that the various
backend crates are unused by the example crates.
The re-export of each backend crate under ratatui is to make it possible
for libs that rely on a specific version of ratatui to use the same
version of the backend crate. Apps in general should use the backend
crate directly rather than through ratatui as this is less confusing.
- Removes all usages of `ratatui::{crossterm, termion, termwiz}`` in the
examples.
- Adds the backend crate to the dependencies of the examples that use
the backend crate directly.
The paste crate is no longer maintained. Replaces the usages of this in
the Stylize declarative macros with hard coded values. These macros are
internal implementation deatil to ratatui and so the changes should have
no impact on users.
Fixes: https://github.com/ratatui/ratatui/issues/1712
AI coding assistants use the deprecation notes to automatically suggest
fixes. This commit updates the deprecation notes to push those tools to
suggest the correct replacement methods and types.
Specifically, AI tools often suggest using `Buffer::get(x, y)`, because
of their training data where this was prevalent. When fixing these
deprecations, they often incorrectly suggest using `Buffer::get(x, y)`
instead of `Buffer[(x, y)]`.
Other crates (e.g. colorgrad) that deal with colors can convert colors
to a tuple of 3 or 4 u8 values. This commit adds conversion methods from
these types to a `Color::Rgb` instance. Any alpha value is ignored.
```rust
Color::from([255, 0, 0]);
Color::from((255, 0, 0));
Color::from([255, 0, 0, 255]);
Color::from((255, 0, 0, 255));
```
https://crates.io/crates/anstyle makes it possible to define colors in
an interoperable way. This makes it possible for applications to easily
load colors from a variety of formats.
This is gated by the anstyle feature flag which is disabled by default.
---------
Co-authored-by: Orhun Parmaksız <orhun@archlinux.org>
- Move Terminal, TerminalOptions, ViewPort, CompletedFrame, Frame to
ratatui-core crate
- Move render_widget_ref() and render_stateful_widget_ref() to extension
trait (FrameExt) due as the Ref types are unstable and kept in the
main lib instead of -core
- Fix rustdoc errors / feature config issues
BREAKING CHANGE: to call `Frame::render_widget_ref()` or
`Frame::render_stateful_widget_ref()` you now need to import the
FrameExt trait from `ratatui::widgets` and enable the
`unstable-widget-ref` feature.
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
This is the first modularization -alpha release. It captures the changes
necessary to manual publish. And ensures all the crates are properly
setup and to set a baseline for comparison in future release checks etc.
This does not update / check the git-cliff setup / changelog
Part of: #1388
Backend code is now moved to `ratatui-crossterm`, `ratatui-termion` and
`ratatui-termwiz`. This should be backwards compatible with existing code.
Co-authored-by: Josh McKinney <joshka@users.noreply.github.com>
StatefulWidget::State and StatefulWidgetRef::State are now ?Sized.
This allows implementations of the traits to use unsized types for the
State associated type. This is turn is useful when doing things like
boxing different stateful widget types with State which implements
`Any`, are slices or any other dynamically sized type.
Co-authored-by: Josh McKinney <joshka@users.noreply.github.com>
These are less stable than the non-ref traits as we have not yet
committed to the exact API. This change moves them to ratatui from
ratatui-core.
To facilitate this:
- implementations of WidgetRef for all internal widgets are removed and
replaced with implementations of Widget for references to those
widgets.
- Widget is now implemented for Option<W> where W: Widget, allowing for
rendering of optional widgets.
- The blanket implementation of Widget for WidgetRef is reversed, to be
a blanket implementation of WidgetRef for all &W where W: Widget.
BREAKING CHANGE: implementations of WidgetRef no longer have a blanket
implementation of Widget, so Widgets should generally implement the
Widget trait on a reference to the widget rather than implementing
WidgetRef directly. This has the advantage of not requiring unstable
features to be enabled.
Part of: https://github.com/ratatui/ratatui/issues/1388
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
All the widgets now live in their own ratatui-widgets crate, but are re-exported in the main ratatui crate.
This makes it easier to use portions of the ratatui library and is part of the effort to modularize
Part of: #1388
---------
Co-authored-by: Orhun Parmaksız <orhun@archlinux.org>
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
