chrisduerr / leechbar Goto Github PK

The performance rework has changed the API quite a bit. All the docs should be re-checked and stuff that is new/changed should be fixed.

It's incredibly annoying that it's not possible to clone these two structs. This should be changed.

Hey, thanks for making this library! I'm encountering a panic when I try to run any examples.

thread 'main' panicked at 'Unable to get primary output crtc information: Error { ptr: 0x7f977da454b0 }', libcore/result.rs:945:5
stack backtrace:
   0:     0x564aff54689b - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h085b5cb2919943dc
                               at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x564aff54d280 - std::sys_common::backtrace::print::he25c82f98f7aac81
                               at libstd/sys_common/backtrace.rs:71
                               at libstd/sys_common/backtrace.rs:59
   2:     0x564aff53d500 - std::panicking::default_hook::{{closure}}::hc30a4462d8c591a0
                               at libstd/panicking.rs:380
   3:     0x564aff53d257 - std::panicking::default_hook::hcb9c5feec9166013
                               at libstd/panicking.rs:396
   4:     0x564aff53d94b - std::panicking::rust_panic_with_hook::h9f5570af4bf0234b
                               at libstd/panicking.rs:576
   5:     0x564aff53d80e - std::panicking::begin_panic::hc973540f5677dae3
                               at libstd/panicking.rs:537
   6:     0x564aff53d70a - std::panicking::begin_panic_fmt::habd3beed8a63031a
                               at libstd/panicking.rs:521
   7:     0x564aff53d6a2 - rust_begin_unwind
                               at libstd/panicking.rs:497
   8:     0x564aff58ffb0 - core::panicking::panic_fmt::hc0bf389917b16633
                               at libcore/panicking.rs:71
   9:     0x564aff429c38 - core::result::unwrap_failed::h393f698bfb8cccb1
                               at /checkout/src/libcore/macros.rs:23
  10:     0x564aff428d3d - <core::result::Result<T, E>>::expect::hedaa7ff381d77d38
                               at /checkout/src/libcore/result.rs:809
  11:     0x564aff418120 - leechbar::bar::primary_screen_info::hc0b8df8c6c679a04
                               at src/bar.rs:408
  12:     0x564aff417449 - leechbar::bar::screen_info::hf2927b171988f0cb
                               at src/bar.rs:340
  13:     0x564aff414892 - leechbar::bar::Bar::new::h8015909145a37f91
                               at src/bar.rs:54
  14:     0x564aff413ff9 - leechbar::builder::BarBuilder::spawn::h2fef54c5fb31fda4
                               at src/builder.rs:223
  15:     0x564aff401b88 - simple::main::hf3b013c8a12622df
                               at examples/simple.rs:26
  16:     0x564aff401788 - std::rt::lang_start::{{closure}}::haa29a9e489c2bc6c
                               at /checkout/src/libstd/rt.rs:74
  17:     0x564aff53d607 - std::panicking::try::do_call::hb11c25abdfc27ad2
                               at libstd/rt.rs:59
                               at libstd/panicking.rs:479
  18:     0x564aff55520e - __rust_maybe_catch_panic
                               at libpanic_unwind/lib.rs:102
  19:     0x564aff541c83 - std::rt::lang_start_internal::ha082c8a960712b5c
                               at libstd/panicking.rs:458
                               at libstd/panic.rs:358
                               at libstd/rt.rs:58
  20:     0x564aff401774 - std::rt::lang_start::hd8ed062ce71df610
                               at /checkout/src/libstd/rt.rs:74
  21:     0x7f9780ec9f49 - __libc_start_main
  22:     0x564aff3f8e89 - _start
  23:                0x0 - <unknown>

xrandr output:

HDMI-A-3 connected 1920x1080+0+0 (0xa8) normal (normal left inverted right x axis y axis) 509mm x 286mm
	Subpixel:   horizontal rgb
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       0
	CRTCs:      0 1 2 3 4 5

library versions:

libxcb 1.12-1
libxrandr 1.5.1-2
xorg-server 1.19.6+13+gd0d1a694f-1

Let me know if I can provide any other info that might assist in debugging.

There seems to be an issue when neither foreground nor background are present.

With components that redraw frequently there seems to be some flickering. It might be a good idea to not clear components when the background doesn't change.

It's intuitive that components are added to the bar in the order of the bar::add call in the source. It's not necessary to have the ordinal exposed to the user, this is just confusing and unintuitive.

The ordinal should probably still be used internally, but it should be calculated automatically when calling bar::add.

Being able to use multiple pictures and compose them together could significantly lower the cost of creating images for the user.

This could be done with a layers system that renders in order. Every time Background::image is called, a new layer is added that is drawn above the previous layers.

Getting started with a library like leechbar can be quite complicated, because everything is specific to the library itself. However examples have a high value because they are easy to reuse and expand. This is why it should be a priority to cover most common tasks with examples.

Some examples that should be added are:

• Time component
• Volume component

In the docs the defaults for builders should be clearly documented.

Background color does not work anymore. It only sets a color for all components, instead of setting a color for the whole bar.

If the user has an underline below the whole bar, he might just want to set the yoffset once. It's probably a good idea to allow a global yoffset. And when the yoffset of a component is set, the global one should be ignored completely and the component offset should be used.

This should make it easy to do BarBuilder::new().yoffset(-5.) without having to worry about the offset of anything else.

Right now mouse events only allow checking if a button has been clicked, it is not possible to detect a button that is being held down.

It should be possible to detect this. The easiest way to do so is having two separate events, one for button down, one for button up.

A proper logging system is setup already, but it's barely used. There should be messages for stuff like events received, component redrawn etc.
This would probably make debugging easier and just helps figuring out what's going on right now.

Right now every call can update the component, so the order in which functions like background and foreground are called is important. This might make it harder for the user to expect what will happen when modifying self in these methods.

As a possible solution having an update method that is run as the first thing with access to &mut self and every other method only having access to &self would be one viable option. Like that, the state of a component can't be changed in unexpected ways (unless the user really wants to go for it with stuff like lazy static).

Spawning multiple bars doesn't seem to work properly. Right now it is required to start the binary multiple times if you want to have multiple bars.

Right now the bar works, but the price for that is incredibly hight. For a normal setup the CPU might be going up to 20% on two threads.

This should be fixed to reduce the CPU usage to an unnoticable amount. RAM usage can also be optimized, seems to be non-critical tho, because even with images the peak memory usage does not exceed a few MBs.

Curretly the documentation mainly has one central example block on each page. Instead of documenting everything in one example, the documentation should provide examples for as many methods as possible.

The ideal would be to have a specialized example for every method.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error(PrimaryScreenInfoError(147), State { next_error: None, backtrace: None })', /checkout/src/libcore/result.rs:906:4 note: Run with `RUST_BACKTRACE=1` for a backtrace.

This happens on some broken i3 machine. It fails at randr::get_output_info. Fails at getting the primary screen info with no output set. Works when output is set manually.

Currently the text height is always calculated automatically. This is a good idea and supporting bottom/top alignment is probably not needed.

However when setting an underline with the beckground image, it might be nice to offset the text by a bit, so it is centered when ignoring the line.

Something like this:

let text = Text::new("Hello, World").y_offset(-3)

Simple structs like MouseButton should implement every basic trait that comes with std, so people can do with them whatever they want.

These are a few of the traits that should be considered for every public type from leechbar:

• Clone
• Copy
• Debug
• Eq
• Hash
• Ord
• PartialEq
• PartialOrd

If fixed width is bigger than screen width, it will fail. The default behavior should probably be to clamp the fixed width in between 0 and the screen width.

It might be worth exploring other Width configurations that could potentially fail.

Probably an issue with window struts, or setting a fallback for the ewmh properties.

Using timers for updates works in a lot of cases, but introduces some overhead and doesn't allow to interrupt it once the timer is sleeping.

As an alternative to a timer, it should be possible to use events to signal that an update is required.

If a component background image is bigger than the component text, it might just lead to a massive image. It should be possible to add a background image, but still have the text width as width.

Mouse events are essential for making a bar interactive.

For this first version the bar should be able to propagate mouse click events to the component that has been interacted with.

Right now errors are utterly terrible. They don't help fixing bugs in the bar and they don't help the user with what he needs to fix if it's his fault.

It would probably be a good idea to completely redesign the approach taken to handling XCB errors.

With some configurations there is an issue that the text in center isn't rendering when text on the right is being rendered.

Currently whenever the timeout runs out, the component is redrawn no matter what. It should be possible for the user to return a "No Redraw" response where no matter what else is received, the component is not redrawn.
This would probably reduce resource usage dramatically in some cases.