When I enter this:
echo "☢☢☢" | lemonbar -f "hack:size=8" -p
It shows nothing. My font (hack) has the glyph.

Is it something related to multibyte utf8?

I opened a new issue on your fork as I suspect it is associated with XFT. If, not, I'll report it in the original repo too.

It was mentioned in issue #6, but the foreground transparency (font transparency) is broken in this fork.
Transparency in lemonbar-xdg:

Versus transparency in base lemonbar:

(It is worth noting that lemonbar-xdg does correctly recognise the #RRGGBB value from a #AARRGGBB, theyre just different in those screenshots).

So I emerged lemonbar-xft, and attempted to try out the last example on the arch linux lemonbar page:

https://wiki.archlinux.org/index.php/lemonbar#Font_Awesome_icons

Unfortunately, for some reason it's not working - the Font Awesome glyph won't display - and lemonbar-xft doesn't report failure or give me any information to help me debug this problem. Looking around the lemonbar-xft issues tracker, I found a link to this page, which explains why:

http://www.freedesktop.org/software/fontconfig/fontconfig-user.html

Fontconfig never fails to select a font, it always just selects a closest match. So fontconfig will never return an error if it can't give you the font you want. On the surface, this is pretty terrible behavior. Luckily, there's an easy fix. Every time lemonbar-xft loads a font, it should report the name of the font it loads on STDERR. Then, in sort of an inversion of the usual pattern on unix, not reporting anything on STDERR while attempting to load a font would ALWAYS indicate an error, whereas reporting something on STDERR while attempting to load a font COULD be an error (user error or program error) depending on whether the user got the font they want.

It might be a little weird, but I think this is the only real solution. Because failing to give the user their preferred font and also not giving them any sort of explanation at all is really unacceptable. The linked document seems to say that the environment variable FC_DEBUG controls this behavior, but unfortunately I can't seem to pass this variable to fontconfig via lemonbar-xft by way of the commandline. It seems like lemonbar-xft should set this to something sensible by default (like 1 or 2 perhaps), and also make it configurable with a verbosity switch, and also allow the internal variable to be set directly by passing a commandline variable.

I try to display a progressbar using █ characters like this: ███(change color)███.

However, it's rendered weird no matter what font or size I use:

Note how it works in urxvt properly, while it's rendered with blue tint in lemonbar. Here's my font config:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <match target="font" >
        <edit mode="assign" name="rgba" >
            <const>rgb</const>
        </edit>
    </match>
    <match target="font" >
        <edit mode="assign" name="hinting" >
            <bool>true</bool>
        </edit>
    </match>
    <match target="font" >
        <edit mode="assign" name="hintstyle" >
            <const>hintslight</const>
        </edit>
    </match>
    <match target="font" >
        <edit mode="assign" name="antialias" >
            <bool>true</bool>
        </edit>
    </match>
    <match target="font">
        <edit mode="assign" name="lcdfilter">
            <const>lcddefault</const>
        </edit>
    </match>

    <!-- Reject bitmap fonts -->
    <selectfont>
        <rejectfont>
            <pattern>
                <patelt name="scalable"><bool>false</bool></patelt>
            </pattern>
        </rejectfont>
    </selectfont>
</fontconfig>

For some reason I cannot display characters with hex code point greater than FFFF, instead a "?" glyph (clearly fallback) is printed on the bar, is this possible?

I think it would be good to document xft related options, like how to pass fonts in xft form or how to turn on antialiasing. I had to google the former from other places, and still have no idea how to do latter.

I could be doing something wrong when I build, but this branch appears to only read RRGGBB colors instead of RRGGBBAA like the master.

I'm on Arch Linux x86_64, Linux 3.16.4-1-ARCH, and built with gcc 4.9.1 20140903.

Otherwise, I would like to give my deepest thanks for this port— I have been missing my xft fonts in my statusbar.

Here is an example of the same font (TeX Gyre Heros) rendered in a Firefox tab and in lemonbar (top). You can see that in Firefox (and its GTK menus), kerning has been applied to close the gap between the "T" and "w" which is not present in lemonbar. I'm using the infinality-bundle package for Arch Linux to handle my font rendering. I'm not really sure what's responsible for the discrepancy but I thought I should make a post in case there's a bug with the xft patch.

Bound actions to buttons A1-3 are as expected but A4 and A5 are unresponsive, xev returns A4 and A5 button presses as expected. Tested with synaptics touch pad, logitech g300 and g402.

The branch seems to work great and reduce SLOC, why not merge it? It's running for me quite well and other people also seem to be using it without issues.

make fails with this error:

/bar>make
cc -Wall -std=c99 -Os -DVERSION="\"020a3e1\"" -I/usr/include/freetype2 -o lemonbar.o -c lemonbar.c
lemonbar.c:19:26: fatal error: X11/Xlib-xcb.h: No such file or directory
 #include <X11/Xlib-xcb.h>
                          ^
compilation terminated.
make: *** [lemonbar.o] Error 1

Lemonbar is already installed, so what additional dependencies does this fork need?

It skips pieces of data I send in, so sometimes I see nothing, or only parts of the bar I wanted to see... So in the end I solved by recompiling an older revision.

launching with:
echo " some text" | lemonbar -fn "Droid Sans-10:sylte=bold" -p

LemonBoy's master:

Yours (built few minutes ago):

Hello,

I'm using i3 on Ubuntu and recently, I tried the lemonbar status bar (with the xft version). But when I run my script, I get the error "Invalid geometry for the clickable area".

Here is the command I use to run the script:

$HOME/.config/i3/lemonbarshow.sh | lemonbar -a 33 -B "#3B4252" -F "#E5E9F0" -f "Liberation Mono for Powerline-11" -g x18 -p | sh
(The script)

It seems to dysfunction due to some lemonbar-xft problem, because, when I use the normal xft package, it works perfectly (except for the fonts)

When I run the command with the lemonbar-xft command, i get this

Do you know how I could solve my problem?

Thank you for your answer!

Hey.
I try to use the actions for a section in the bar. But unfortunately I can't get it work.
A minimal example would be the following: echo "%{A1:notify-send 'Test'} Test %{A}" | lemonbar -p.
When I click: nothing. What am I doing wrong?

Hey just upgraded lemonbar-xft-git - Now fonts don't load as they used to.
Before the upgrade loading fonts like this worked, but not anymore.

lemonbar -p -f "Oxygen Mono-15","Icons-17","FontAwesome-17"

I tried reading the code but couldn't find anything after a quick glance, did I miss something or is this a new bug?

The following would usually output hi with a speaker icon:

echo "hi" | lemonbar -p -f "Oxygen Mono-15","Icons-17","FontAwesome-17"

EDIT: Added example with glyph

Default amount of fonts allowed is 5, correct? saw that it was set to that in source. If I have my font set as "Dejavu Sans-8,FontAwesome-8", only the Dejavu text renders, and if I set my font as "FontAwesome-8", the icons render fine( though no text of course ). This is as of a pull of the lemonbar-xft-git aur package today.

Hey folks,

this repository has been dead for ages and I stopped using lemonbar some years ago. The code only works by accident and the approach is questionable at best.

While I think that it's great that so many people found some use in my attempt at making this work, I recommend using a different statusbar implementation or implementing this again from scratch on top of a newer lemonbar version.

Hi,

is there any chance that you could implement Stebalien's Owidth formatting command for paddings?

I think that's a pretty elegant possibility to position blocks more freely than lemonbar allows you to ootb (and I quite don't like using workarounds like using spaces etc.).

While I'd like to use a Powerline font for the cool triangles, I'd like to be able to use regular (unpatched) font for the text. Since these fonts have very different baselines, it would make sense to make -o able to handle them separately.

What's the syntax, will spaces throw it off, how do I give the size, etc... I'm recovering from XFLDs, heh

thanks!

This is what it looks like:

I specify the font with

-f "Source Code Pro for Powerline-9"

other sizes are no better.

The same font looks alright in urxvt though:

*font: xft:Source Code Pro For Powerline:pixelsize=10
URxvt*.letterSpace: -2

maybe I can specify letterSpace for bar-aint-recursive too somehow?

im getting a segfault when i set the background or the foreground

gdb output:

Program received signal SIGSEGV, Segmentation fault.
parse_color (str=0x7fffffffdcc3 "#222222", end=end@entry=0x0, def=16777215)
at bar.c:293
293 ptrdiff_t len = *end - str;

The latest version (pulled yesterday) does not seem to support formatting. The problem seems to be that % isn't caught (As I don't have to use %% to get a literal percent sign as the man page states you should).

It should be reproduce-able with this command:
echo "test" | lemonbar %{c} -g 2550x14 -B #ff00ff -F #FFFFFF -p

The %{c} should center the text, however it does not seem to do that.

Using the original lemonbar repository, a bar launched with -n BAR_NAME can be rendered below fullscreen windows using xdo below -t $(xdo id -n root) $(xdo id -a BAR_NAME).

Unfortunately, this doesn't seem to work with this fork.

Do you have any idea how to fix this?