i3bar previously used get_colorpixel on strings without the leading # (ff0000
instead of #ff0000). Since it uses libi3’s get_colorpixel now we needed to
update a few places.
The new default looks like this (like in docs/userguide):
colors {
background #000000
statusline #ffffff
focused_workspace #ffffff #285577
active_workspace #888888#222222
inactive_workspace #888888#222222
urgent_workspace #ffffff #900000
}
If you want to go back to the previous colors, use:
colors {
background #000000
statusline #ffffff
focused_workspace #ffffff #480000
active_workspace #ffffff #480000
inactive_workspace #ffffff #240000
urgent_workspace #ffffff #002400
}
In order to not duplicate configuration options and make stuff confusing, we
dropped the commandline flags (except for socket_path and bar_id). This means
that you *have to* specify bar_id when starting i3bar. The best way is to let
i3 start i3bar, which it will do automatically for every bar {} configuration
block it finds.
Thanks to yvesf for this simple python test script:
from gi.repository import Gtk as gtk
def cb(*a):
print a
def si_popup(*a):
print a
status_icon = gtk.StatusIcon()
status_icon.set_from_stock(gtk.STOCK_OPEN)
status_icon.connect("activate", cb)
gtk.main()
This fixes the condition where the i3 socket for some reason did not produce an
error, but the X server exited (earlier than i3?) and the left-over i3bar
process would consume 100% CPU.
How to reproduce the problem:
1) Start ./testcases/Xdummy :8
2) Start DISPLAY=:8 i3bar -s <socket path to i3 on :0>
3) Kill the Xdummy
In case of a 1024 px screen and a 1128 px status line, the status line was not
only cut off (it has to be, obviously), but the right part showed some black
pixels.
