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.

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.

It'd be nice if slogger was supported alongside log

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)

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

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.

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?

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 😃

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?

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.

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.

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!

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?

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?

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).

It has to either be bumped to 25.0 or removed completely.

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!