What is the difference between polybar and lemonbar?

[Joe23232]

Just curious to know the difference between polybar and lemonbar? Can lemonbar be configured with a programming language like polybar can?

[domsson]

tl;dr: They both have a very different scope. lemonbar just draws a window with text and doesn't care about anything else. polybar is a fully integrated status bar, batteries included.

lemonbar

Features

• draws a rectangular area (the bar) on the screen, either at the top or bottom of your screen
• the bar can have a custom size and position, and optionally a background color
• the bar can display text (using bitmap fonts) on it, if you pipe said text to it
• each piece of text can be styled to some degree (via special formatting strings):
  • left, center or right aligned
  • font, text color, background color
  • underline and/or overline, line color
• further, each piece of text can be made to react to mouse interactions
  • if the text is clicked, lemonbar spits a user-defined string to stdout
  • this can then be used to start other scripts or programs

Scope

lemonbar follows the UNIX philosophy in that it has a very limited scope. It simply draws a bar with some text on it and doesn't much care about anything else. In order to make it behave like an actual status bar, the user has to somehow pipe a formatted string (containing everything that you want to display) to lemonbar whenever new content should be shown. To make text react to mouse clicks, you need to read from lemonbar's stdout and somehow process that output. In other words, it is up to you to interface with lemonbar via stdin and stdout (pipe text to and from lemonbar). Hence, you probably need to use an additional script or program to make lemonbar behave like a typical statusbar. That's what the polybar authors hint at when they say you need "a black belt in shell scripting". At the same time, this makes lemonbar incredibly flexible and light on system resources (especially memory). You could just as well use lemonbar to display notifications or anything else, really. Because it is somewhat hard to set up, people have come up with lemonbar managers like succade or Captain.

polybar

Features

• dedicated status bar
• many formatting options, including rounded borders
• knows the concept of "modules" (comparable to "piece of text" in lemonbar)
• comes with many modules built-in (date, time, volume, CPU usage, etc)
• can be easily configured via INI-style config file
• updates itself according to the modules / config file
• supports "fancy" things like true type fonts out of the box
• mouse interactivity is also configued via config file
• many more

Scope

polybar is a much more integrated solution. It is a status bar, rather than a multipurpose tool. As such, it brings with it all the functionality that you would expect of a status bar and makes it very easy to setup and use. All you need to do is to write up a config file to your liking and you are up and running. The most common "modules" (where each module is a piece of information to be displayed on the bar) are built-in and many more are available. This ease of use, while still being pretty light on resources, is why we've seen so many users migrate to polybar. "It just works". Fun fact: polybar started out as a lemonbar wrapper itself and was initially called Lemonbuddy. Only later did they decide to integrate lemonbar's functionality right into the project.

lemonbar vs. polybar

If you're now wondering why anyone would possibly still prefer lemonbar over polybar, here are some reasons:

• If you appreciate separation of concerns (see the UNIX philosophy above)
• If you care about resource usage a lot (for example, you're on a Raspberry Pi)
• If you simply don't need the additional features of polybar
• If you might want to use lemonbar in more ways than just a status bar

The first point is the most important one in my opinion. For example, people have forked lemonbar and made it work with TrueType / OpenType fonts. If you want that functionality, grab that version. Likewise, it would be possible for someone to make lemombar work with Wayland (instead of X) and you could still keep your entire workflow (modules, scripts, etc) up and simply swap out the bar.

[Joe23232]

Ah I see, thanks for typing this out all for me :)

[domsson]

If your question is sufficiently answered, feel free to close the issue (if you can, not sure). :)

[Joe23232]

I actually have a few more question mate :)

I am very noob to programming and I am learning more and more so I have a few more questions forgive me if it sounds silly.

So first of all, is it possible at all to configure lemonbar to look like this particular setup of polybar as shown in the image, especially if you look at the top right hand side of the image?

Am I able to use any of my desired languages such as Rust to configure Lemonbar?

I am planning to use bspwm for my window manager, is it possible to integrate bspwm and Lemonbar together if I used something like Rust, for example if I click on a different workspace 2 on the lemonbar, bspwm would know that I want to be in workspace 2?

When configuring lemonbar, am I starting from scratch where I won't see any code inside the config file?

Is there good documentation available for lemonbar?

Last question is it very difficult to configure lemonbar?

[domsson]

lemonbar is language-agnostic. It reads text from stdin (and displays it), and possibly spits text to stdout (if you have configured clickable areas). Therefore, there is no configuration, no scripting language, nothing. The only available documentation is what you see in the README, see OPTIONS and FORMATTING. The Arch Wiki elaborates on that a bit.

You need to somehow feed text into lemonbar. Most people use bash scripts, but you can also write a little Rust program to do that, if you prefer.

Let me show you the basics. Give this a try on your terminal:

echo "Hello Bar" | lemonbar -p

This will start lemonbar with the permanent option (without it, lemonbar would quit immediately after there is no new input coming). It also pipes the text Hello Bar into it (| is the pipe character). Now you should see a black bar at the top of the screen, stretching all across your monitor, and showing "Hello Bar" on the left.

Now, let's try some options:

echo "Hello yellow Bar" | lemonbar -p -F#000000 -B#FFFF00

This does the same, but now the default background color has been set to yellow, the default font color to black.

Now we try formatting:

echo "%{l}Hello%{c}yellow%{r}Bar" | lemonbar -p -F#000000 -B#FFFF00

You should now see Hello on the left, yellow in the center and Bar on the right. In the same fashion, you can change background and foreground color of individual pieces of text:

echo "%{l F#FF0000}red%{c F#00FF00}green%{r F#0000FF}blue" | lemonbar -p

I hope you get the idea. It is all quite simple, but the formatting strings can quickly get out of hand, making it hard to see what you're actually doing. That's why people usually use scripts for it.

Let's assume this simple script (assume the name to be date-test):

#!/bin/bash
while :
do
    echo "%{c}$(date)"
    sleep 1
done

We could then do this:

./date-test | lemonbar -p

With every new line that our little script spits to stdout, lemonbar will read that line and update itself accordingly. We now see the date and time, centered on our bar, updating every second!

Regarding your screenshot, if you're talking about these triangular transitions, then yes, that is possible. You need a font that can display a solid triangle. You then set the background color to that of the section to the left, the foreground color to the same as the background color of the following section. Then print the triangle. Does that make sense? The only difficulty there is that you will probably have to use a different font for the triangle character than for your regular text. That can be done, however. lemonbar can load up to five fonts via the -f option. You can then specify which font you want to use for a specific piece of text via the format switch T.

Example (won't work like this, because I'm making up the fonts):

echo "%{T2}<%{T1}foobar" | lemonbar -p -f"Regular-font" -f"Triangle-font"

This will draw < in the second font (T2) we specified, which is Triangle-font, then draw foobar in the first font (T1), which would be Regular-font.

Regarding a workspace switcher, that's possible as well. For this, you need clickable areas, which we can create with the A formatting option:

echo "%{A:xclock:}$(date)%{A}" | lemonbar -p

The %{A:cmd:} starts a clickable area (where cmd is any string) and %{A} closes it. Now, when you left-click that piece of text, lemonbar will simply spit the string to stdout. You can then pipe that into a script that executes the string, for example.

Piping text to and from lemonbar can be done programmatically. Rust will do fine, as will pretty much any other language.

[Joe23232]

Yes it makes sense. Its very interesting, and it sure is very low level. Thanks for your help :)

[Joe23232]

Hey sorry one other question, is it possible for lemonbar to support images as shown in the example below?

[domsson]

If you're referring to the icons, like the workspace indicators in the top left, or the memory, CPU and volume indicator (among others) in the top right, then yes. If we're talking about actual images (as in JPG, PNG, BMP, etc), then no.

The original lemonbar (this repository) can only display text using bitmap fonts. This still allows you to show bitmap icons as long as you use a suitable font. Probably the most used font for this is Siji. Once installed, you can load that into one of the 5 font slots. Example on how to run lemonbar with two fonts, one of them Siji:

echo "%{T2} %{T1}30%" | lemonbar -p -f"6x13" -f"-wuncon-siji-medium-r-normal--10-100-75-75-c-80-iso10646-1"

This should display a bitmap speaker icon next to "30%":

If you wonder how to copy & paste the appropriate icons, take a look at the succade Wiki.

If you want smoother looking icons, as shown on the picture, you'd need to use one of the available xft forks of lemonbar - for example this one - which enable the rendering of other types of fonts (TrueType, OpenType), including the commonly used Font Awesome icon font. As far as I know, some distros (like Arch) have the xft-fork readily available in their packages.

Also, what's your Twitch handle? ;-)

[Joe23232]

Ah I see that makes sense mate. I would probably stick with the xft forks.

With regards to polybar, am I able to disable the stuff that I don't need through a script or something and only keep the stuff that I need, that way I cam reduce its memory footprint?

---

Also, what's your Twitch handle? ;-)

Sorry mate I am not on Twitch, do you use Reddit?

[domsson]

I'm not too familiar with polybar, so I can't say. However, while lemonbar is definitely more lightweight, I believe the memory footprint of polybar is pretty decent as well. So unless you're running a machine that is significantly low on memory (old computer, Raspberry Pi, something like that?) and have to squeeze out every byte, I wouldn't worry about it. :)

It would actually be interesting to see someone benchmark the two bars in regards to resource usage. Probably not easy to do, though. At least I wouldn't know how to do it.

Ah, I see, I thought it was you on the screen shot. Yeah, I've posted as otacon7000 over there from time to time.

[Joe23232]

I'm not too familiar with polybar, so I can't say. However, while lemonbar is definitely more lightweight, I believe the memory footprint of polybar is pretty decent as well. So unless you're running a machine that is significantly low on memory (old computer, Raspberry Pi, something like that?) and have to squeeze out every byte, I wouldn't worry about it. :)

Yeah I don't really need to worry about memory usage but I love lightweight software :)

Hey sorry I keep asking questions i just want to know what is the right tool to use before I pick it.

So again with the triangle shaped things on the top right hand side, I was wondering what those coloured triangle shaped things are? Are they fonts if you happen to know, the guy in the video is using polybar? Is it easy to create my own triangle like fonts?

---

Ah, I see, I thought it was you on the screen shot. Yeah, I've posted as otacon7000 over there from time to time.

I tried to find your username but coudn't find anything on redit. And nah that is not me in the screenshot, do you know DistroTube?

[domsson]

Like I described above. Example:

echo "%{r F#fbda83}%{F- B#fbda83} hello %{F#7ca6f8}%{F- B#7ca6f8} world " | lemonbar -p -F"#000000" -f"6x13" -f"-wuncon-siji-medium-r-normal--10-100-75-75-c-80-iso10646-1"

Now, I've never done this before and it turns out that when using Siji (a fixed-width bitmap font), it doesn't quite work, because there are small gaps between the triangles and the next text, which destroys the desired illusion. However, I assume it will work with the xft fork and a font like powerline-extra-symbols. Just replace the font and glyph in the above example, respectively.

Let us know if that works.

[Joe23232]

Like I described above. Example:

echo "%{r F#fbda83}%{F- B#fbda83} hello %{F#7ca6f8}%{F- B#7ca6f8} world " | lemonbar -p -F"#000000" -f"6x13" -f"-wuncon-siji-medium-r-normal--10-100-75-75-c-80-iso10646-1"

Now, I've never done this before and it turns out that when using Siji (a fixed-width bitmap font), it doesn't quite work, because there are small gaps between the triangles and the next text, which destroys the desired illusion. However, I assume it will work with the xft fork and a font like powerline-extra-symbols. Just replace the font and glyph in the above example, respectively.

Let us know if that works.

THank you I will give it a try some time :)

[Joe23232]

@domsson It does this.

(I currently am using xfce so like it is going on top of the xfce bar).

---

A person over at reddit told me about how lemonbar could be more inefficient compared to polybar let me quote you his reply.

Correct me if I’m wrong, but isn’t Lemonbar one of those bars that refreshes ALL information every second/interval you set? That seems ridiculously inefficient. Polybar to my knowledge allows custom intervals for each module, and some modules don’t even use intervals (like mpd or bspwm).

Is this true if you happen to know about lemonbar?

[domsson]

It looks like it didn't load the font or the font doesn't have the character you wanted, not quite sure to be honest. Someone more familiar with the xft fork might know better.

Regarding the quote, that person isn't wrong but also isn't quite right: it really depends on your setup.

• For polybar, it depends on your configuration, where you can set up the reload interval for each module individually.
• For lemonbar, it entirely depends on your script that feeds lemonbar.

See, most lemonbar feed scripts I've seen are rather simple and update lemonbar in a fixed interval (often 1 second). Now, if you're going to have a clock that displays seconds on your bar, then the performance of both polybar and lemonbar is probably going to be very similar, as both will have to update every second anyway, otherwise they couldn't show the correct current time. And from what little I know about drawing on screen, usually you re-draw the entire contents of a window anyway, meaning that if you have to update the clock, polybar probably re-renders all other modules as well. lemonbar definitely does. If your clock only shows hours and minutes, then you could optimize your feed script, as it would not need to feed lemonbar every second. That's where the "it depends" comes in: a well written script will only feed lemonbar when necessary.

Bottom line, I would guess that lemonbar with a well written feed script doesn't use more CPU (possibly even less) than polybar. In my tests using top, it seemed that they were quite similar in CPU usage.

Here are some pointers for optimizing a feed script:

• Poll information only as often as required (no need to refresh CPU temp every second)
• Generally try to reduce polling and instead find fetch tools that can be kept running
• Only feed lemonbar when the gathered values actually differ from the previous ones

I've actually started writing small fetch programs that query (system) information in a way that make these optimizations easy. See candies. Take, for example, the temp-sensors program:

• Using -m, it keeps running and prints over and over again, eliminating the need to re-run / poll it
• Using -i, you can set the internal interval in which the program queries the temperature values
• The gathered temperature will be printed only if it differs from the previous reading

Using fetch tools like this, you can easily write a very efficient feed script.

Personally, I run lemonbar via succade with a total of 9 modules:

• bspwm workspace indicator
• username
• location
• weather at my location
• volume
• CPU temperature
• CPU usage
• RAM usage
• date and time (minute precision, no seconds)

When checking CPU usage of both programs via top, I see lemonbar come up every now and then with 0.3 to 0.7%. succade shows up too, but quite rarely, usually at 0.3%. If we add that up, we could say that my bar setup is using somewhere between 0.0 and 1.0% CPU, on average probably more in the 0.3% range. Feel free to experiment with a similar polybar setup and see what top has to say on that, I'd be curious.

[Joe23232]

@domsson

Personally, I run lemonbar via succade with a total of 9 modules:

Succade seems like something that makes lemonbar work more like polybar from my understanding?

When checking CPU usage of both programs via top, I see lemonbar come up every now and then with 0.3 to 0.7%. succade shows up too, but quite rarely, usually at 0.3%. If we add that up, we could say that my bar setup is using somewhere between 0.0 and 1.0% CPU, on average probably more in the 0.3% range.

Do you remember what the results were for polybar?

[domsson]

When I started work on succade, I didn't know about the history of polybar (namely, Lemonbuddy). Basically, succade is the same as what Lemonbuddy used to be: a "lemonbar manager". You can think of it as a very sophisticated lemonbar feed script.

It acts as the middle man between lemonbar and the scripts/programs that fetch information to be displayed on the bar. It takes care of all the piping to and from lemonbar and enables you to configure lemonbar with a simple config file, not unlike polybar. Of course, a very valid question then is: why not just use polybar? Personally, I prefer this setup because of separation of concerns and resource usage / minimalism, but polybar certainly is easier to install (because it is available via most distro's package managers) and brings a lot more features with it, especially when it comes to fancy styling.

Regarding CPU, I don't quite know how to properly benchmark the two solutions, but from a quick glance at top, it seems like they are very similar.

Regarding RAM, you got me curious, so I actually did a test real quick. According to pmap, here is the memory consumption of my current succade+lemonbar setup, plus a somewhat comparable polybar setup (I only had 4 modules running on polybar, so actually a simpler setup):

• succade + lemonbar: 304748K
• polybar: 769880K

Regarding the succade + lemonbar, here is the exact break-down of all involved processes:

• succade: 2380K
• lemonbar: 6820K
• bspc: 6704K
• volume-pulse: 277864K
• temp-sensors: 3780K
• cpu-proc: 3600K
• mem-proc: 3600K
• datetime: 2288K

Note how the majority of my setup's RAM goes to the volume module. Without that, I'd be looking at only 26884K (vs. polybar's 769880K). According to pmap, the vast majority of that comes from libpulse. That's an interesting finding which I didn't know about. It certainly makes me want to write another volume module that doesn't require libpulse. Then again, that's a shared library and whether my module uses it or not, the library is most likely loaded anyway.

[domsson]

Update: after a quick research, it seems that a more accurate representation of memory usage can be acquired by looking at the PSS value as reported by smem -k. So, here goes the same test as above, but with smem instead of pmap:

• succade + lemonbar: 2261.0K (about 2.3M)
• polybar: 7.0M

Break-down for the first setup, as above:

• succade: 269.0K
• lemonbar: 263.0K
• bspc: 171.0K
• volume-pulse: 819.0K
• temp-sensors: 326.0K
• cpu-proc: 146.0K
• mem-proc: 144.0K
• datetime: 123.0K

[Joe23232]

@domsson

When I started work on succade, I didn't know about the history of polybar (namely, Lemonbuddy). Basically, succade is the same as what Lemonbuddy used to be: a "lemonbar manager". You can think of it as a very sophisticated lemonbar feed script.

Does Polybar still do similar things when it used to named Lemonbuddy?

• succade + lemonbar: 2261.0K (about 2.3M)
• polybar: 7.0M

Break-down for the first setup, as above:

• succade: 269.0K
• lemonbar: 263.0K
• bspc: 171.0K
• volume-pulse: 819.0K
• temp-sensors: 326.0K
• cpu-proc: 146.0K
• mem-proc: 144.0K
• datetime: 123.0K

With this test, with polybar were you running very similar things without running extra stuff?

---

Have you heard of Lemonblocks. it seems similar to succade. If I were to use succade, I have to still use some external script if I understood correctly? Should I use a compiled language over a shell scripting language for outputting stuff to succade to improve performance?

[domsson]

polybar still does similar things to Lemonbuddy; after all, it grew out of Lemonbuddy. Basically, polybar is the same as Lemonbuddy or succade, just that it has the functionality of lemonbar, as well as some modules built-in.

In my tests, I ran somewhat similar setups, but since I didn't want to spend too much time on the config, I had less modules running on polybar.

I had not heard of Lemonblocks yet, thanks for pointing it out. It looks interesting. I'm not quite sure how it works (where or how do you dispatch the signals?), but it does look indeed as if it does something similar to succade.

Good question on compiled vs. scripts. I wonder about that myself. I would imagine that compiled is faster, at least, but that's just a guess.

[Joe23232]

polybar still does similar things to Lemonbuddy; after all, it grew out of Lemonbuddy. Basically, polybar is the same as Lemonbuddy or succade, just that it has the functionality of lemonbar, as well as some modules built-in.

Ah I see thanks for that mate :)

In my tests, I ran somewhat similar setups, but since I didn't want to spend too much time on the config, I had less modules running on polybar.

Wow I can't believe Polybar is actually so much more bloated compared to lemonbar. But in your tests, did you also add up the external script that you used to feed the information to succade? I belive that if I understood it correctly, the script feeds information to succade and then succade passes it on to lemonbar?

I had not heard of Lemonblocks yet, thanks for pointing it out. It looks interesting. I'm not quite sure how it works (where or how do you dispatch the signals?), but it does look indeed as if it does something similar to succade.

I wonder what is the difference :thinking:

Good question on compiled vs. scripts. I wonder about that myself. I would imagine that compiled is faster, at least, but that's just a guess.

I actually had somebody tell me that generally polybar consumes less CPU resources than lemonbar as often times people uses the shell scripting language to pass information to lemonbar wheras on polybar, the preconfigured modules don't use such slow languages. But it can be less than polybar if the user uses a compiled low level language. So yeah I might just use Rust.

Having said that do you know how with any low level language I should pass the information?

[domsson]

did you also add up the external script that you used to feed the information to succade?

Yup, I added up all the memory used by all scripts/modules that fetch information, see the detailed bullet point list above. For polybar, there was only one process to check, as I was using internal modules only.

if I understood it correctly, the script feeds information to succade and then succade passes it on to lemonbar?

Exactly. Plus, succade takes care of formatting the script's output according to your config file.

I wonder what is the difference

Not sure regarding the difference, as I'm not quite sure how Lemonblocks would be used, exactly. It sounds like you need to have at least one additional script that, based on some condition, sends a signal to Lemonblocks, whenever a module should be updated. But I'm not certain.

often times people uses the shell scripting language to pass information to lemonbar wheras on polybar, the preconfigured modules don't use such slow languages.

If you only use polybar's internal modules, then that's basically the fastest you can get. That's because compiled C/C++ code is usually very efficient (if written well, of course), plus there is absolutely no need to fork a new process and therefore also no need for any type of IPC (inter process communication). If you use external modules (and this is true for polybar, succade, lemonblocks, etc), I assume that compiled programs are also faster to execute than bash scripts. I'm not sure about the memory usage of bash scripts, however. If a new instance of a shell interpreter (or whatever it is called) is being started and run for every script, then they probably do worse; if they all share one interpreter, then they might actually do similar or better. I really can't say, don't know enough about how that works. Personally, I prefer compiled (because I guess they are lower on resources), which is part of why I started the candies project (all of them are written in C).

how with any low level language I should pass the information?

There are two ways that I know of (succade is using the second):

• use | to pipe input to lemonbar on the command line or via a bash script
• write code that can open a child process (lemonbar), then open a pipe to the child process, then write data to the pipe

I can't believe Polybar is actually so much more bloated

Sure, in my quick (and probably not horribly accurate) tests, the polybar setup used more than twice as much memory as my succade + lemonbar setup. However, with about 2 and 7 MB respectively, both are pretty lightweight for what they do, really. Just to compare it to something entirely different, Skype is using about 400 MB on my system - and that's for idling. ;-)

In other words, we're very much talking about the often quoted micro optimizations here.

[Joe23232]

Yup, I added up all the memory used by all scripts/modules that fetch information, see the detailed bullet point list above. For polybar, there was only one process to check, as I was using internal modules only.

Ah I see mate my bad.

If you only use polybar's internal modules, then that's basically the fastest you can get. That's because compiled C/C++ code is usually very efficient (if written well, of course), plus there is absolutely no need to fork a new process and therefore also no need for any type of IPC (inter process communication). If you use external modules (and this is true for polybar, succade, lemonblocks, etc), I assume that compiled modules are also faster to execute than bash scripts. I'm not sure about the memory usage of bash scripts, however. If a new instance of a shell interpreter (or whatever it is called) is being started and run for every script, then they probably do worse; if they all share one interpreter, then they might actually fare better. I really can't say, don't know enough about how that works. Personally, I prefer compiled (because I guess they are lower on resources), which is part of why I started the candies project (all of them are written in C).

I thought it was written in Python the polybar modules. Anyways with your candies project, these are just preconfigured modules, right?

There are two ways that I know of (succade is using the second):

Ah I see. So is succade written in a shell script or in a compiled language?

Sure, in my quick (and probably not horribly accurate) tests, the polybar setup used more than twice as much memory as my succade + lemonbar setup. However, with about 2 and 7 MB respectively, both are pretty lightweight for what they do, really. Just to compare it to something entirely different, Skype is using about 400 MB on my system - just for idling. ;-)

Of course 7 MB is quite light but lemonbar's resource foot print is quite a big difference. So yeah I will stick with lemonbar.

Yeah modern programs are so bloated these days. I am surprised Skype even exists for Linux :-)

[domsson]

I thought it was written in Python the polybar modules. Anyways with your candies project, these are just preconfigured modules, right?

The programs in the candies project all do the same thing: they fetch some information (mostly system stats, like CPU usage or temperature) and print it to stdout. You could simply use them on the console, to get the current CPU temperature etc. However, they are made with statusbars like lemonbar in mind. For example, almost all of them have the -m switch that puts them in monitoring mode, where they keep running and printing. This makes it more efficient to use them with lemonbar, compared to running them over and over again from scratch.

The internal polybar modules (the ones that come built-in) are written in C++, just like the rest of polybar. Most of the user-provided / external modules seem to be bash scripts, some are Python scripts (about 65 to 35% split, according to GitHub's statistics).

Ah I see. So is succade written in a shell script or in a compiled language?

succade is written in C.

[Joe23232]

Ah I see. I guess I would use candies as well. With candies, can I easily change the font to make it look like this on the top right hand side:

[domsson]

Ah I see. I guess I would use candies as well. With candies, can I easily change the font to make it look like this on the top right hand side:

candies, just like fetchutils and polybar-scripts (and many others) fetch and print (system) information. Nothing more. Even though they might have been written with a certain use case in mind, they aren't strictly tied to a status bar or anything else. There is no styling coming from them.

In case of polybar, the styling happens in the config. In case of lemonbar, the styling happens via the format strings. In case of lemonbar managers, like succade, it again happens in a config (and the manager then turns that into a format string for you).

Maybe you should just go give it a shot, try different tools, see what's what.

[domsson]

I've spent a bit of time trying to throw together a setup that somewhat resembles the one in your screenshot. Check it out:

I'm using bitmap fonts here, so it does look different. With the xft fork of lemonbar, you should be able to faithfully recreate your example. You can check the succade config I used to get this going. However, you can do the same without succade, as it is just a helper tool that creates the required format string for you.

Here is another example of someone doing a similar setup with vanilla lemonbar.

[Joe23232]

@domsson That looks pretty good. I really appreciate how you helped me out, thanks a lot mate :)

[domsson]

lemonbar has no dependencies (or more precisely, if you're running X, then you can be sure that the dependencies are fulfilled anyway). succade currently has two dependencies, inih and libkita, the first which you can find in many distribution's repositories, the latter I will resolve shortly (hopefully tomorrow).

[Joe23232]

@domsson I know mate, I accidently said that over here I deleted the comment, thanks anyways :)

[Joe23232]

@domsson Hey man one thing, is it possible for me to configure my tags to have its own unique colour and if I click on the tag, the entire tag becomes a filled colour, is that possible with succade and with the candies project?

[domsson]

@Joe23232 by tags, do you mean your bspwm workspace indicators? If so, let me copy you a paragraph from the succade wiki:

How to style only parts of a block?

You can't. succade treats every block (script, program) as one atomic unit that will be styled the same throughout. An underline will always underline all of the block's output, not only part.

This is an issue for some scenarios. For example, if you want a workspace indicator that shows all of your workspaces, but underlines only the active one. A possible workaround would be to either have your workspace block print a different icon for the active workspace than for inactive workspaces (full vs. empty circle, maybe) and not rely on succade's styling options. Another solution is to split your workspace indicator into three separate blocks: the first showing the inactive workspaces before the active one, the second block showing only the active workspace; the third showing the inactive workspaces after the active one -- this way, you can apply different styles to all three of them but make them look like one.

[Joe23232]

Through succade, can I connect external scripts that will automatically style based on what workspace I am in?

[domsson]

@Joe23232 for questions on succade, I suggest you open up an issue over there. This is the lemonbar repository after all. :)

[Joe23232]

@domsson Oh lol sure mate :)