label= directive crops text after a certain limit

[Rahtgaz]

The label directive is cropping text after a certain limit, which makes it very hard to use with pango markup.

The following results in a failed blocklet

[cpu_usage]
markup=pango
label=<span color="#73A0D9">foobar</span>

If I remove the markup=pango directive, the text gets printed and it can clearly be seen where it was cropped.

I'm using the string foobar above. But even in the presence of a single character label, it can get cropped with certain characters and fonts: For example, many of the characters in Font Awesome will result in a failed label.

[Rahtgaz]

Although it is nice to know, this does not really fix the bug. It only propels it to fire on a different string size and forces me to fork the project. The fix must be something else: How can the pango markup feature coexist with a byte-limited string?

Unfortunately I can't code in C, so I can't contribute other than reporting the bug.

[Rahtgaz]

I'm not sure I understand your argumentation. Forking the project is really not the best way to do this. On the other hand, I cannot understand why is there a hardcoded limit. If the "fix" suggestion is to increase this limit, then this is obviously an arbitrary hard limit and a wrong decision.

Neither can I understand the argumentation that I should instead put my label in the block script. Again this does not address the bug. It merely assumes the any user confronted with this situation is a developer capable of building their own scripts or changing other people's scripts (which could mean forking their projects too).

I'm just reporting the bug and hoping for it to be fixed. I am not however receptive (at all!) to the idea that I should fix the bug myself. Personally, I'd prefer if the restriction just be removed. It makes no sense to have this kind if stuff hardcoded to the program. Users understand screen size limitations. They don't need to be spoon fed arbitrary restrictions.

Over and Out,
Mario Figueiredo

[Rahtgaz]

@kb100

The type of variable limits you are talking about are set by the programming language standard. Not arbitrary programmer decision. Or are you telling me you always hardcode a limit to all your variables, just because? Of course you don't. So please don't compare https://github.com/vivien/i3blocks/blob/master/include/block.h#L60 with system or programming language limitations.

If there is an actual reason for that limit, that is fine. I'd like to know. This conversation would be over a long time ago. Otherwise, stop dodging and agree that limit makes no sense whatsoever. Since you have done neither, I'm pretty sure you just have no idea why that limit is there and are just wasting my time. And please do not make assumptions about my programming experience (which you would be surprised, since it happens to be my profession for the past 35 years).

As for github I already explained to you I don't program in C. So I cannot help. It's impossible for me to do that, unless I relearn a language I dropped 17 years ago. This is the only reason why I am not contributing with code.

[4nt1m0n]

@Rahtgaz Out of curiosity, in which languages do you mainly program?

[Rahtgaz]

@kb100, now you call me a liar. This is getting more and more interesting as it progresses. As I have explained before, changing the limit from 32 to something else does not fix the bug. It merely circumvents the problem. If I change it to 64, I now will have to face the bug if my string is 65 bytes long. If I change it to 2 million, now I need to answer why then I have a hardcoded limit in the first place and why isn't this an option on a config file.

On the other hand I have already explained to you, I can certainly change the value to, say 1024, Compile and be done with it. But that means I HAVE FORKED THE PROJECT. I don't want to do that, because now I WILL BECOME THE MAINTAINER of a project in a language I am no longer familiar with. Every time an update happens here, I will need to go and repeat the same thing on my fork, if I wish to integrate your changes with mine. I cannot afford to fork this project on those premises. Maybe if the bug was more serious and the application more critical to my daily usage. You just don't fork projects over non critical bugs. It's madness!

Do you even understand the things I have been telling you all this time? Or will you keep trying to measure dicks with me?

@4nt1m0n
I program mostly in C# these days as part of my job. But I also do python and bash as a hobby.

[vivien]

Hi @Rahtgaz

Sorry for the delay. That is true, there was a subjective limit on the label string size. I've brought some changes to i3blocks to get rid of the static properties, so that any property of any length can now be supported. If you don't mind giving the next branch a try, your issue must be solved there.

If everything goes well, I'll merge it soon into master.

[vivien]

Properties of any length are now supported in the master branch.