* separate saved/runtime structure, kind of working
* serializing config
* work
* work
* save config through the configuration screen
* work
* startup wizard
* style(code): cleanups
* fix(session): reload config from disk when switching sessions
* style(fmt): rustfmt
* fix(config): propagate cli config options to screen
* style(fmt): rustfmt
* zellij-tile: Move `data` to zellij-utils
The rationale behind this is that all components of zellij access the
data structures defined in this module, as they define some of the most
basic types in the application. However, so far zellij-tile is treated
like a separate crate from the rest of the program in that it is the
only one that doesn't have access to `zellij-utils`, which contains a
lot of other data structures used throughout zellij.
This poses issues as discussed in
https://github.com/zellij-org/zellij/pull/1242 and is one of the reasons
why the keybindings in the status bar default plugin can't be updated
dynamically. It is also the main reason for why the keybindings are
currently passed to the plugin as strings: The plugins only have access
to `zellij-tile`, but since this is a dependency of `zellij-utils`, it
can't import `zellij-utils` to access the keybindings.
Other weird side-effect are that in some places `server` and `client`
have to access the `zellij-tile` contents "through" `zellij-utils`, as
in `use zellij_utils::zellij_tile::prelude::*`.
By moving these central data structures to one common shared crate
(`zellij-utils`), `zellij-tile` will be enabled to import `zellij-utils`
like `screen` and `client` already do. This will, next to other things,
allow dropping a lot of `std::fmt::Fmt` impls needed to convert core
data structures into strings and as a consequence, a lot of string
parsing in the first place.
* utils: Integrate new `data` module, bump rust ver
Integrates the `data` module that was previously part of `zellij-tile`
to allow sharing the contained data structures between all components of
zellij.
This allows `zellij-tile` to use `utils` as a dependency. However, since
`tile` is build against the wasm target, it cannot include all of
`zellij-utils`, since a lot of dependencies there cannot compile with
`wasm` as target (Examples include: termwiz, log4rs, async-std). Thus we
make all the dependencies that cannot compile against `wasm` optional
and introduce a new feature `full` that will compile the crate with all
dependencies. Along with this, modify `lib.rs` to include most of the
data structures only when compiling against the `full` feature.
This makes the compiles of `zellij-tile` lighter, as it doesn't include
all of `utils`. As a side effect, due to the dependency notation for the
optional dependencies (See
https://doc.rust-lang.org/cargo/reference/features.html#optional-dependencies),
we bump the rust toolchain version to 1.60.0.
* tile: Import `data` from zellij-utils
Add `zellij-utils` as a dependency to `zellij-tile` and allow us access
to the `data` module defined there. Update the re-export in the
`prelude` such that from all of the plugins points of view *absolutely
nothing changes*.
* utils: Fix `data` module dependency
Since the `data` module has been migrated from `zellij-tile` to
`zellij-utils`, we import it from `zellij-utils` directly now.
Also unify the imports for the `data` module members: We import all of
the through `data::` now, not through a mixture of `data::` and
`prelude::`.
* client: Fix `data` module dependency
Since the `data` module has been migrated from `zellij-tile` to
`zellij-utils`, we import it from `zellij-utils` directly now.
Also unify the imports for the `data` module members: We import all of
the through `data::` now, not through a mixture of `data::` and
`prelude::`.
Add the "full" feature flag to the `zellij-utils` dependency so it
includes all the components we need.
* server: Fix `data` module dependency
Since the `data` module has been migrated from `zellij-tile` to
`zellij-utils`, we import it from `zellij-utils` directly now.
Also unify the imports for the `data` module members: We import all of
the through `data::` now, not through a mixture of `data::` and
`prelude::`.
Add the "full" feature flag to the `zellij-utils` dependency so it
includes all the components we need.
* tests: Fix `data` module dependency
Since the `data` module has been migrated from `zellij-tile` to
`zellij-utils`, we import it from `zellij-utils` directly now.
* utils: Remove "full" feature
in favor of conditional compilation using `target_family`. Replace the
rust 1.60 method of specifying optional dependencies based on features
and optionally include the dependencies only when not building for wasm
instead. (I.e. `cfg(not(target_family = "wasm"))`)
* cargo: Update module dependencies
since `client`, `server` and `tile` now all depend on `utils` only.
* Remove gray from theme config and improve colors for dark themes
* improve theme usage
* Add new themes and minor fixes
* improve tokyo-night theme according to new changes
* Fix formatting
* change default black colour
* docs(CHANGELOG): #1274 improve themes
* feat(ui): round frame corners
* Allow rounded_corners to be set without a palette
* Revert "Allow rounded_corners to be set without a palette"
This reverts commit 9271a4b5452f2e59e0ebd55136343f0fbfabaa13.
* fix(style): remove redundant code
* fix(style): clippy lints that somehow got missed
* feat(config): add ui config section
feature(layout): add layout config (#866)
* It is now possible to configure zellij through a layout:
The config file and the layout file will be merged, on conflicting
options the order is as follows:
1. config options `zellij options`
2. layout
3. config
Example:
```
---
template:
direction: Horizontal
parts:
- direction: Vertical
body: true
- direction: Vertical
borderless: true
split_size:
Fixed: 1
run:
plugin:
location: "zellij:tab-bar"
default_shell: fish
```
* add option `theme` that allows for setting of a theme,
the default is `default`
* under `themes` the themes can be described as follows:
either:
```
themes:
default:
fg: [0,0,0]
bg: [0,0,0]
black: [0,0,0]
red: [0,0,0]
green: [0,0,0]
yellow: [0,0,0]
blue: [0,0,0]
magenta: [0,0,0]
cyan: [0,0,0]
white: [0,0,0]
orange: [0,0,0]
```
or
```
themes:
default:
fg: 0
bg: 0
black: 0
red: 0
green: 0
yellow: 0
blue: 0
magenta: 0
cyan: 0
white: 0
orange: 0
```
If the key is different from default, it needs to either be specified on
start with `options --theme [THEME]`, or in the configuration file under
theme: [THEME].
closes#390
