[Feature Request] multiple colors per block about i3blocks HOT 22 CLOSED

Unfortunately, multiple colors per block is not supported by the i3bar protocol, and dynamic blocks is not supported (yet?) in i3blocks.

The closest you can get is a script which probes a given partition, prints the good color, or does nothing if the partition does not exist yet, alongside a static listing of potential partitions, such as this config:

# globals, for boilerplate
command=~/bin/part_probe.sh /dev/$BLOCK_NAME
# write a udev rule to trigger a pkill -RTMIN+1 i3blocks when a device appears, and use:
interval=once
signal=1
# or make the script block on the device update, and use:
# interval=repeat

[sdd1]
[sde1]
[sde2]
[sdf1]
[sdg1]
[sdg2]
[sdg3]

But as you mentioned, that might not be convenient in your case.

from i3blocks.

+1 for dynamic blocks

Could they be implemented as "sub blocks" ? For example we could have a delimiter or some kind of "end of block" character in our scripts, and for each of those "sub blocks" a block would be displayed, inheriting the settings from i3blocks.conf as well as the printed data for each "sub block".

They would of course be sent as completely separate json objects to i3bar.

What do you think?

from i3blocks.

This feature might indeed be interesting, in some cases like this. My concern is that I want to keep it simple by keeping i3blocks as close to the i3bar protocol as it can be. Adding a notion of sub block and a special syntax doesn't feel that way. Second, this would require dymamic memory allocation during updates, which is not actually needed! Those are not blocking points, but I have to think a bit more about that to ensure this is worth it.

from i3blocks.

To avoid needing dynamic allocation, you could make a MAX_SUBBLOCKS variable which determines how many blocks should be pre-allocated, and an OVERLOAD_TEXT to display if you try to exceed MAX_SUBBLOCKS number of sub blocks. For instance, in my case, I know I would be happy with just showing the first 5 USB devices, and saying " [...] " for when I have more attached. I agree that this might add too much complexity to the code base though and may not be worth it.

from i3blocks.

Multiple colors will likely soon be possible with i3 by using pango markup. See the pending pull request i3/i3#1471

from i3blocks.

Neat! Thanks for the pointer @Airblader.

from i3blocks.

And it's now merged! :) I've already been using it anyway and it's really handy. It allows more than just colors, e.g., font weight and strikethrough and stuff.

from i3blocks.

Since the Pango markup PR, the special HTML characters like &, <, > need to be replaced with corresponding HTML entities, otherwise i3bar will not display the block.

It's maybe out of topic for this issue, but how do you think i3blocks should deal with this? By consequence of i3/i3#1471, i3blocks is currently assuming all blocks output is valid Pango markup. Should I update my blocks to encode special HTML characters? Or maybe a configuration option like pango=true|false is welcome in i3blocks (I would be happy to develop it and make a PR if so)?

from i3blocks.

I'd suggest just encoding your block text. It's the most straight forward way for i3blocks. I guess i3blocks could support a pango property, though. Let's see what Vivien has to say. :)

from i3blocks.

We want to encourage people to come up with inventive use of pango, so I suggest adding a line to the default config

# Use pango markup language for colors and other styling,
# set to false to avoid needing to escaping HTML characters
pango=true

I would opt to say just force people to use pango and don't even give them the option, but this might be too extreme. A newbie might get confused and think i3blocks is broken. Maybe add a default block that is commented out showing how to use escaped characters.

from i3blocks.

I'm going to be honest, I haven't found a decent Pango tutorial so I'm avoiding it. Any good sources?

from i3blocks.

I found this sufficient: https://developer.gnome.org/pango/stable/PangoMarkupFormat.html

from i3blocks.

BTW I have a working implementation of escaping here, for (at least) my personal usage (not yet configurable since I don't need Pango at all for now).

from i3blocks.

I don't get how Pango works with i3bar. Shouldn't this block work?

[test]
full_text=<span foreground="blue" size="x-large">Blue text</span> is <i>cool</i>!

from i3blocks.

@vivien that works for me in my statusline generator

from i3blocks.

Another cool thing you can do is use icon fonts, such as

<span font="FontAwesome">\uf0ea</span>

from i3blocks.

As @acrisci explained me, the font specified in the i3 config has to be pango: prefixed.

Also, concerning i3blocks, it seems like a per-block escape property (defaulting to true) needs to be added in order not to break existing scripts (we add a longer discussion on Gitter).

from i3blocks.

Also, concerning i3blocks, it seems like a per-block escape property (defaulting to true) needs to be added in order not to break existing scripts.

👍 for this.

There's another problem though; the Pango markup was introduced in i3 4.9.1. Before 4.9.1, escaping blocks output would result in raw HTML entities displayed (like Kool & the Gang in my MPD block). But since 4.9.1, not escaping blocks would result in block not being displayed.

Typically, on Debian Wheezy, I have i3 4.8, while I have 4.9.1 on Arch, and if I want proper output everywhere, I need to escape only on the latter.

Is it really i3blocks' responsibility to escape output? The thing is i3bar 4.9.1 broke existing scripts that could output special HTML characters, regardless if we use i3blocks or not.

Maybe it's i3bar that needs to support a pango property (defaulting to false) in the JSON protocol?

from i3blocks.

@valeriangalliat you are right. Ideally, the status_command program doesn't have to care about block texts. It makes sense to have a new is_markup or (pango) key to the i3bar protocol, since i3bar is in the best position to know if a bar is using a pango font and if a block needs to be escaped.

Something like this pseudo code for i3bar: if (bar->font_is_markup && !block->is_markup) { print_escaped(block->full_text); }

@acrisci what do you think?

from i3blocks.

@kb100 about your initial issue, with Pango this is now easy to build a convenient string for each USB device, that might look like this:

I cheated a bit with this static config:

[usb]
full_text=<span foreground="green">[sdd1]</span> "flashdrive" <i>/mnt/flashdrive</i>: 8G | <span foreground="grey">[sde1]</span> | <span foreground="green">[sde2]</span> <i>/mnt/flashdrive2</i>: 4G | <span foreground="green">[sdf1]</span> "other"

Note: alongside an udev rule to trigger a signal to i3blocks when an USB device is plugged/removed, this script is a good candidate for i3blocks!

About dynamic blocks, this feature is unlikely to be implemented, since I would prefer the i3blocks config to be as closed to the i3bar protocol as it can be, meaning a single blocklet matches a single i3bar block.

from i3blocks.

Well we can't fix the problem with different versions not supporting pango markup in any case. That is a good complication to consider in the fix though.

Adding the per-block member for markup and defaulting to no markup I think might be the best idea so far. I'll work on it and see if I can get something simple enough for a dot release.

from i3blocks.

Closed: pango blocklets can have multiple colors.

from i3blocks.