Possibility to position text absolutely or to set paddings?

[ghost]

Hi,

is there a possibility to position things absolutely like one can do with dzen's ^pa()?

I know a can align text to the left/center/right, but I don't see how to get text to start at for example 123px…

Alternative: Is there an option to set CSS-like paddings?

I've read the man page carefully, but I couldn't find anything like this…

[CamilleScholtz]

You can use spaces to align the text maybe?

[ghost]

Well, I also could use a second instance of lemonbar in the background to simulate left an right paddings, but imho, that would all be quite inelegant, imprecise workarounds…

[vyp]

@onodera-punpun Spaces won't work because they are still text, and therefore the alignment of everything else will still depend on the width of everything before/after it.

[neeasade]

@vyp true, but this can be made manageable with something like https://github.com/baskerville/txtw

[vyp]

@neeasade Thanks, I know about txtw, but am I missing something, there's still no way to specify alignment by number of pixels, only by left, center or right?

[neeasade]

@vyp I guess what I had in mind was if you were to go that route, have a fallback font with a space the width of one char and script print that many spaces and then... ugh maybe not

[vyp]

width of one char

Wouldn't work for variable width fonts though.

I remember quite a while ago I solved this by putting two texts at the right/left of the panel. Basically one was the actual text I wanted to see in normal colours. The other was the 'widest' possible version of the text you could expect, but all in the same colour as the background colour of the panel, so it seems invisible, but it aligned the rest of the text that remained to the right/left properly. If that makes any sense. However, I consider this an ugly workaround, not ideal.

So by widest, if you can expect letters like the alphabet a-z/A-Z, you would usually go for filling in with W's because that's usually the widest glyph in a-z/A-Z. And you would do this for the biggest expected number of characters. The result can have some weird spacing between sections when one part is not taking as much width as it can. (And this adds up with the more sections you have, possibly making it even uglier.) But I think this is the only way right now to ensure a changing width of one section doesn't offset the position of another section, not sure.

Remember though, if you're using a variable width font, but in one section you can expect the same number of characters, you could possibly try and use the fallback font feature (thankfully lemonbar supports up to 4 fallback fonts by default) to use a monospace font just for that part. (if it doesn't make it look too ugly)

EDIT: I admit the above is not the best worded explanation, so perhaps some really ugly code of it in use will help. (Notice the two %{r}'s at near the end of the line.)

[Stebalien]

FYI, I maintain a fork that allows pixel offsets (padding).

[ghost]

@Stebalien: That's very nice and exactly what I was looking for! But why did you (have to) fork it instead of making a pull request?

Btw.: Your fork doesn't seem to have XFT-support, does it?

[Stebalien]

@cju. I did make a pull request (https://github.com/LemonBoy/bar/pull/48). And no, it doesn't have XFT support (it only adds the one feature).

[ghost]

@Stebalien: Ok thanks, I decided to ask @krypt-n to implement your formatting command into his XFT-fork, if that's all right with you.

[Stebalien]

@cju fine by me.

[LemonBoy]

@Stebalien if I remember correctly the original PR added more than that, and that's the reason why it was rejected. A command to insert spaces with pixel granularity is very welcome.

[Stebalien]

@LemonBoy That's all it ever did (although the original PR appears to have collected a bunch of unrelated commits, probably do to some rebaseing). I've submitted a new PR (#170).

[LemonBoy]

The aforementioned PR has been merged, sorry for the delay :)