wlr/taskbar pushes the modules on the right over the screen when I open windows.
A solution to this would be a max-length option, which limits the total width of the taskbar module.
Some nice to have options to possibly implement along side:
- A "squeeze" (name TBC) flag - when the bar reaches the max width, each window button will be shrunk to fit all buttons into the available width
- A flag that makes all buttons split the available space equally between them - one button uses all the space, two have half each, etc
- An option that sets each button to a fixed width, regardless of the length of the content
Also this is related to this issue: https://github.com/Alexays/Waybar/issues/882
Any updates on this?
Would be really nice to have this<3
Would be really nice to have this<3
Are there any workarounds for that?
I think the obvious solution would be to have some kind of scroll box.
I think the obvious solution would be to have some kind of scroll box.
Why? The behaviour in most (all?) panels is to shrink window buttons to fit.
It's not sustainable. If the button is too small you can't read or see anything and then what?
- Max width of buttons, if there is enough space they grow as big as that.
- Min width of buttons, if the available space is smaller than button_count * current button_width shrink buttons to MAX(min_width, available_space / button_count).
- If new button_width * button_count is still > available space start scrolling
By applying the patch below, titles can shrink, although icons don't.
diff --git a/src/bar.cpp b/src/bar.cpp
index d0a187c6..4b667b90 100644
--- a/src/bar.cpp
+++ b/src/bar.cpp
@@ -798,7 +798,7 @@ auto waybar::Bar::setupWidgets() -> void {
if (config["fixed-center"].isBool() ? config["fixed-center"].asBool() : true) {
box_.set_center_widget(center_);
} else {
- box_.pack_start(center_, true, false);
+ box_.pack_start(center_, true, true);
}
box_.pack_end(right_, false, false);
diff --git a/src/modules/wlr/taskbar.cpp b/src/modules/wlr/taskbar.cpp
index f4b137c0..bfe182c3 100644
--- a/src/modules/wlr/taskbar.cpp
+++ b/src/modules/wlr/taskbar.cpp
@@ -271,6 +271,9 @@ Task::Task(const waybar::Bar &bar, const Json::Value &config, Taskbar *tbar,
button.set_relief(Gtk::RELIEF_NONE);
+ text_before_.set_ellipsize(Pango::EllipsizeMode::ELLIPSIZE_END);
+ text_after_.set_ellipsize(Pango::EllipsizeMode::ELLIPSIZE_END);
+
content_.add(text_before_);
content_.add(icon_);
content_.add(text_after_);
Considering potential compatibility with #2647, mouse wheel scrolling would be unavailable. An alternative is to stack icons behind each other when the bar becomes full, unstack on mouseover and scroll via mouse position on taskbar.
A fairly simple workaround I've applied to my configuration for now is using the rewrite option of the wlr/taskbar config. The config looks like this:
"wlr/taskbar": {
"format": "{icon} {title}",
"on-click": "activate",
"rewrite": {
"^(.{16}).+$": "$1…"
}
}
This regular expression will match any format output over 16 characters, and truncate it down to those characters plus an ellipsis. 16 was chosen kind of randomly by me, because it fits decently onto my screen. In effect this looks like this (note the ellipsis characters at the ends of the long names):
If there's a LOT of windows this doesn't ultimately prevent them from flowing out, but it at least puts a boundary on individual windows.
Any updates on this? Looks like there's been no movement, not even an incorporation of this patch: https://github.com/Alexays/Waybar/issues/917#issuecomment-1774038594
Considering potential compatibility with #2647, mouse wheel scrolling would be unavailable. An alternative is to stack icons behind each other when the bar becomes full, unstack on mouseover and scroll via mouse position on taskbar.
Both features can coexist easily if the scrolling is an action that can be choosed and used for on-scroll-up/down. The scrolling could be done by the way of a classical scrollbar or even side buttons too.