Too few areas available by default

[rr-]

After starting serious tinkering, lemonbar gave me tons of "astack overflow" errors. The default number of maximum 20 clickable areas is too little: consider 10 workspaces with actions for left click and right click - there's no room left for anything else...

Increasing N to 100 would relief the necessity to compile lemonbar ourselves and wouldn't impact memory usage at all.

[Chrysostomus]

I second the opinion. Just 5 workspaces with scroll support takes 15 clickable areas. Volumeicon takes further 4. 20 areas is really little.

[Slabity]

Should it even be constant at all? I wouldn't mind for the user to be able to specify the number of sections, or even dynamically allocate them as necessary.

[ghost]

It's a stack, right? Have a linked list! Also, surely only the nesting should be stored? So, left click and right click would only be 2 slots? Not sure, haven't really read code. Any opinions on this?

[otommod]

While dynamic memory allocation (or a linked list) would allow for an arbitrary number of areas, it would complicate the code.

Since less is more, I think the "better" solution is to just raise N to 100.

[ghost]

A linked list wouldn't complicate the code too much at all. Replace the slot member with head and tail. Adjust the iterations and the push, pop code. Et voila. But still, #define N 100 is a good solution

[ghost]

Anyway, I don't care as area_t is 32B on my system (YMMV), so #define N 200 yields 6.25KiB, IOW 5.625KiB more than #define N 20. Simple.

[Ferdi265]

Because I had some time on my hands, I made a quick and dirty fork of lemonbar that implements area_stack_t with a dynamically allocated (in the sense that it isn't a compile time config) length for slots.

In my fork, invoking lemonbar with -S <number-here> will raise the limit to <number-here>. The changes are trivial, but as I said, it was a quick and dirty solution, so the code is not quite clean and nice (for example I just used atoi() for the integer parsing for the parameter).

Here's the fork: Repo

[ghost]

You used strtoul() instead of atoi() 😄. IMHO the code is pretty clean

[Ferdi265]

That's because I cleaned it up immediately after writing this 😄

[LemonBoy]

Cool, mind submitting a PR ?

[ghost]

The problem would be that it is based on krypt-n's which causes it to yield some extra commits (e.g. merge commits)

[LemonBoy]

Please check out the latest commit.

[Ferdi265]

Latest commit looks fine. I don't mind my fork not being merged in as long as the issue is fixed.

My fork will exist a while longer until krypt-n merged the changes into his xft-branch, which I lack the knowledge to merge correctly, so that it doesn't segfault.