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.
This reverts commit f51ba2d7ecf3f560c8ce4d3ab8419ecf6265839c.
This commit introduced a regression, which prevented i3bar to be redrawn
at all in some circumstances. It will later be reintroduced in a bigger
refactoring of event-dependencies
