When a workspace marked 'urgent', i3bar unhide
itself. if I want to hide it again, I must press the
modifier.This sometimes annoys me.
In this patch I change the above behavior to this:
If a urgent workspace occurs, i3bar will unhide itself;
and when you navigates away from the last urgent
workspace and there is no more urgent workspace, i3bar
will hide itself.
This can happen if you move your mouse pointer to the very left of the
screen and then click. For better usability, we handle this edge case
like a click on pixel 0.
If the first line of the input starts with {"version":, then the input is
considered to be JSON, otherwise it is interpreted as plain text.
Only the "full_text" and "color" parts of a block are currently understood by
i3bar.
We now use 5px padding for the workspace text on both sides. Some
fonts will look off-by-one (e.g. fixed), but that's because X core
fonts have padding. This padding is per-char, varies wildly across
different fonts, and would be a major pain to offset for. Even if
we could take this padding into account, this would probably make
things look even worse for some fonts.
This re-introduces borders around the workspace buttons in i3bar.
No additional pixels will be consumed (you will not lose any space for your
windows).
Abstracted draw_text and predict_text_width into libi3. Use
predict_text_width from libi3 in i3 too. This required tracking
xcb_connection in a xcb_connection_t *conn variable that libi3
expects to be available in i3bar.
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
darkraven