gin66 / tui-logger Goto Github PK
View Code? Open in Web Editor NEWLogger and Widget for rust's tui crate
License: MIT License
Logger and Widget for rust's tui crate
License: MIT License
Firstly, Thank you for producing this crate. I have thus far found it excellent.
What I'd like to do is have 2 separate log widgets, both displaying different log data dependent on the log target. I'm pretty sure I know the answer is that it's just not possible, but I was wondering if you could shed some insight as to what I might need to do to achieve that goal.
I basically want log::info!(target: "x", "This is log X");
and log::info!(target: "y", "This is log Y");
to show up in different log panes (widgets).
---Logs 1-----------------------Logs 2-----------------------
| This is log X | This is log Y |
| | |
-------------------------------------------------------------
โ๏ธ A bit like that; stylistic hell I know ๐
I want to include millisecond in the timestamp of log file. It seems that tui-logger doesn't expose this function for file log, buy only output_timestamp
for tui.
Cool project!
It has to either be bumped to 25.0
or removed completely.
tui-rs is now 0.6.2 while this crate depends on 0.4.0.
it would complains about 2 different version of tui-rs.
|
121 | .block(Block::default().borders(Borders::ALL).title("log"))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `tui::widgets::block::Block`, found a different struct `tui::widgets::block::Block`
|
= note: expected type `tui::widgets::block::Block<'_>` (struct `tui::widgets::block::Block`)
found type `tui::widgets::block::Block<'_>` (struct `tui::widgets::block::Block`)
note: Perhaps two different versions of crate `tui` are being used?
Hello! Love this crate, we've been using it to log to our TUI app.
I'm wondering if it's possible to simply display the log output to the terminal without running with TUI? Sometimes we disable TUI for debug purposes. I tried running without launching TUI using RUST_LOG=info cargo run
but no log info is output to the terminal.
Hey there,
I'm putting together a widget showcase page at https://ratatui.rs/showcase/third-party-widgets/ and would like to add tui-logger. The demo right now seems a bit complex to use as it shows all the possible features. Would you be interested in creating a simpler demo that just shows the main aspect in a small area like the examples we have on the site already? I'm happy to create the actual gif if you have a good simple demo (though the process is fairly simple - see https://github.com/ratatui-org/website/tree/main/code/widget-showcase-third-party)
error[E0277]: the trait bound `TuiLoggerWidget<'_>: Widget` is not satisfied
--> src/ui.rs:125:21
|
125 | f.render_widget(tui_w, chunks[4]);
| ------------- ^^^^^ the trait `Widget` is not implemented for `TuiLoggerWidget<'_>`
| |
| required by a bound introduced by this call
|
= help: the following other types implement trait `Widget`:
BarChart<'a>
Canvas<'a, F>
Chart<'a>
Gauge<'a>
LineGauge<'a>
List<'a>
Paragraph<'a>
Sparkline<'a>
and 4 others
let tui_w: TuiLoggerWidget = TuiLoggerWidget::default()
.block(
Block::default()
.title("Logs")
.border_style(Style::default().fg(Color::White))
.borders(Borders::ALL),
)
.output_separator('|')
.output_timestamp(Some("%F %H:%M:%S".to_string()))
.output_level(Some(TuiLoggerLevelOutput::Long))
.output_target(false)
.output_file(false)
.output_line(false)
.style_error(Style::default().fg(Color::Red))
.style_debug(Style::default().fg(Color::Green))
.style_warn(Style::default().fg(Color::Yellow))
.style_trace(Style::default().fg(Color::Magenta))
.style_info(Style::default().fg(Color::Cyan))
.state(&app.states[0]);
// ..
f.render_widget(tui_w, chunks[4]);
0.9.3, change introduced in c3ef34e, enables termion
in ratatui
when using ratatui-support
feature. This is breaking change on systems which are not supported by termion
(i.e., mainly Windows). This could be avoided by allowing users to just use ratatui
feature, but this crate doesn't compile properly with it since it uses #[cfg(not(feature = "ratatui-support"))]
.
I think either all cfg
expressions should be changed to #[cfg(not(feature = "ratatui"))]
or even better #[cfg(feature = "ratatui")]
, or the latest change in Cargo.toml
should be reverted/reconsidered.
Is this possible to change the default logging level based on the value of RUST_LOG
environment variable? I tried setting it but it had no effect.
Quickly resizing from big window to small (~25 chars width) crashes the program. Tested using Kitty terminal.
thread 'main' panicked at /home/.../tui-logger-0.11.0/src/lib.rs:1203:33:
attempt to subtract with overflow
There is a medium level security advisory for tui-logger
:
$ cargo audit
Crate: time
Version: 0.1.45
Title: Potential segfault in the time crate
Date: 2020-11-18
ID: RUSTSEC-2020-0071
URL: https://rustsec.org/advisories/RUSTSEC-2020-0071
Severity: 6.2 (medium)
Solution: Upgrade to >=0.2.23
Dependency tree:
time 0.1.45
โโโ chrono 0.4.24
โโโ tui-logger 0.9.0
error: 1 vulnerability found!
Hey there!
Looks like the latest version of tui_logger
includes an info
call that's very noisy for users:
https://github.com/gin66/tui-logger/blob/master/src/lib.rs#L942-L946
I can certainly adjust the verbosity of tui_logger
for my log levels, but I feel like this might've just been leftover from a previous version ๐ I'll put in a PR removing the log, but I'd be happy to adjust it to trace
if you need that information for something else
As for 6 August 2023 tui repository is archived fdehau/tui-rs#654.
I think it's time to make ratatui feature default one and tui support as legacy feature.
It might make it easier to keep up with new versions of ratatui (as for now tui-logger 0.9.5 doesn't work with ratatui 0.23.0.
I have a file in main.rs with logs then in another directory i have tui logger, how can i pass to tui-logger the logs to be displayed on the terminal?
I tried compiling your examples with
cargo run --example demo --no-default-features -F ratatui-support,examples-ratatui-crossterm
and
cargo run --example demo --no-default-features -F tui-rs,examples-tui-crossterm
Both give errors that look like termion
is still being used instead of crossterm
โฏ cargo run --example demo --no-default-features -F ratatui-support,examples-ratatui-crossterm 09:54:21
Compiling crossterm_winapi v0.9.1
Compiling winapi-util v0.1.5
Compiling termion v1.5.6
Compiling regex-automata v0.3.6
Compiling chrono v0.4.26
Compiling is-terminal v0.4.9
error[E0433]: failed to resolve: maybe a missing crate `sys`?
--> C:\Users\username\.cargo\registry\src\index.crates.io-6f17d22bba15001f\termion-1.5.6\src\lib.rs:24:9
|
24 | pub use sys::size::terminal_size;
| ^^^ maybe a missing crate `sys`?
|
= help: consider adding `extern crate sys` to use the `sys` crate
error[E0433]: failed to resolve: maybe a missing crate `sys`?
--> C:\Users\username\.cargo\registry\src\index.crates.io-6f17d22bba15001f\termion-1.5.6\src\lib.rs:27:9
|
27 | pub use sys::tty::{is_tty, get_tty};
| ^^^ maybe a missing crate `sys`?
|
= help: consider adding `extern crate sys` to use the `sys` crate
error[E0433]: failed to resolve: maybe a missing crate `sys`?
--> C:\Users\username\.cargo\registry\src\index.crates.io-6f17d22bba15001f\termion-1.5.6\src\async.rs:5:5
|
5 | use sys::tty::get_tty;
| ^^^ maybe a missing crate `sys`?
|
= help: consider adding `extern crate sys` to use the `sys` crate
... several more of these
Is there a way to compile without termion
?
With the recent release of ratatui, the tui-rs revival project, I think it would be best to support the new version to help people convert over.
There are a few other crates moving already, like ansi-to-tui.
Thanks for putting together this package.
I'm not able to get this to work with tracing unfortunately. Do you have any idea what might be going on?
I have the following code in the main.rs
:
use tracing_subscriber::{
self, filter::EnvFilter, prelude::__tracing_subscriber_SubscriberExt, util::SubscriberInitExt, Layer,
};
fn main() {
let directory = ...;
let log_path = directory.join("debug.log");
let log_file = std::fs::File::create(&log_path)?;
let file_subscriber = tracing_subscriber::fmt::layer()
.with_file(true)
.with_line_number(true)
.with_writer(log_file)
.with_target(false)
.with_ansi(false)
.with_filter(EnvFilter::from_default_env());
tracing_subscriber::registry().with(file_subscriber).with(tui_logger::tracing_subscriber_layer()).init();
...
}
And I'm using the following render function:
fn render(f: &mut super::Frame<'_>, rect: tui::layout::Rect) {
let state = TuiWidgetState::new().set_default_display_level(LevelFilter::Trace);
let w = TuiLoggerWidget::default()
.style_error(Style::default().fg(Color::Red))
.style_debug(Style::default().fg(Color::Green))
.style_warn(Style::default().fg(Color::Yellow))
.style_trace(Style::default().fg(Color::Magenta))
.style_info(Style::default().fg(Color::Cyan))
.state(&state);
f.render_widget(w, rect);
}
I'm not getting any log output if I do this. If I use the SmartWidget, I get the borders but no logs. I'm getting logs in my file from tracing, just not in the TuiLoggerWidget.
Any idea what might be going on here?
It'd be nice if slogger was supported alongside log
I think tui-logger would greatly benefit from the ability to customize the format of logged messages. It seems that the message format is hardcoded. In my specific case, I'm logging messages from multiple child processes that are sent back to the parent via a pipe. For things like warnings and errors, the "location" that the log is printed from is of no use because it's the same line(s) every time (the place in the parent where the message is read from the pipe and logged in the parent). Additionally, in my case, the logging of the target is redundant noise and I would prefer if it wasn't there. Finally, in long running processes, I can see where H:M:S time stamps aren't enough (think about a process that has uptime in the days, weeks, or longer).
In the absence of a formal way to specify the formatting a simple compromise would be a "passthrough" mode that just logs the string passed to log without any additional formatting or text added (but keeps the coloring / style set).
Currently, if logs scroll out of the frame, there is no way (other than changing log levels) to view logs that have scrolled out of the frame. This can be problematic in just-noisy-enough applications where there are enough logs to overflow out of the window, as there's no way to view if they were successful or not.
It would be awesome if there was a way to scroll the output log (potentially by focusing on the log widget, and using a KeyModifier + UP/DOWN). I see in your implementation that you use the offset
field of TuiWidgetInnerState
to control how far the window has scrolled, but since that field is private I was unable to make any manual modifications.
I'm using the logger widget pretty extensively in the wash project on GitHub, and would be happy to contribute a PR if we wanted to talk about a solution here... I implemented scrolling in an output window by using the SHIFT+UP/DOWN key combination to increase/decrease the scroll offset. Code for scrolling up.
It would also be neat to be able to set the title log / title target attributes of the TuiLoggerSmartWidget
. I don't intend on replacing them, but simply buffering them with a space character on each side increases readability with the widget borders in my opinion. You can see below the r
seems almost connects with the border.
Also, please let me know if I'm missing an obvious way to scroll or do this as the crate exists today (I'm using version 0.4.13
with the "tui-crossterm" feature).
Thanks for the awesome project.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.