Bartabgroups / overlaps dwmblocks when systray is active

[par4m]

When no systray apps are active:

With any systray app: e.g nm-applet

Adding more systray apps pushes dwmblocks further under bartab

Similar behaviour is observed when statuscmd patch is added with systray (no bartabs)

Any workaround for this for statuscmd and bartabgroups ? Something like this OR is the issue with systray not updating the width properly ?

[bakkeby]

I presume this is in the context of a traditional bar with patches applied from the suckless site?

Looking at the bartabgroups patch we have that the calls to bartabcalculate passes the status text width as the x offset. https://dwm.suckless.org/patches/bartabgroups/dwm-bartabgroups-20210802-138b405.diff

This is just a general patch compatibility issue.

The fix would be to pass the status text width + getsystraywidth() when calling these functions.

[par4m]

So something like this right ?

bartabcalculate(selmon, x + getsystraywidth(), TEXTW(stext) - lrpad + 2, ev->x, battabclick);

and

  bartabcalculate(m, x + getsystraywidth(), tw, -1, bartabdraw);

since this function is being called just two times

[par4m]

Just tried it (once with + getsystraywidth() and once - getsystraywidth() ) with vanilla dwm + systray + bartabgroup patch and it didn't work Any other workaround that you might think would work ?

[bakkeby]

Yes in the above example the argument for the x offset is the tw variable, so you would have

bartabcalculate(m, x, tw + getsystraywidth(), -1, bartabdraw);

same for the call in buttonpress.

The parameter name on the function side was xOff or something like that.

[par4m]

argument tw seems to be for int sw and not int offx

so in the buttonpress call it should be this right ?

bartabcalculate(selmon, x, TEXTW(stext) - lrpad + 2 + getsystraywidth(), ev->x, battabclick);

[bakkeby]

Yes you are right, it's the sw (status width) parameter. Should be fine the way you have it.

[par4m]

Well not sure whats going wrong but it's still overlapping, it gets shifted but overlaps too.

[par4m]

Well i changed this and the left overlapping is gone, don't know why as it was a fluke

drw_text(drw, m->ww - tw - stw + getsystraywidth(), 0, tw, bh, lrpad / 2 - 2, stext, 0);

But now the systray overlaps dwmblocks from the right

[bakkeby]

That just suggests that the issue still lies with the bartabgroups patch.

drw_text(drw, m->ww - tw - stw + getsystraywidth(), 0, tw, bh, lrpad / 2 - 2, stext, 0);

The + getsystraywidth() just negates what the stw (systray width) variable subtracts.

The status was shown fine before so it should have something to do with how the bartabgroups patch calculates it's width relative to where it thinks the status text starts.

[par4m]

Played around a bit with the values and it's fixed (i'm guessing) though not sure what exactly happened

if (m == selmon) { /* status is only drawn on selected monitor */
    drw_setscheme(drw, scheme[SchemeNorm]);
    tw = TEXTW(stext) - lrpad / 2 + 2 + getsystraywidth(); /* 2px extra right padding */
    drw_text(drw, m->ww - tw - stw + getsystraywidth(), 0, tw, bh, lrpad / 2 - 2, stext, 0);
}

Reverted every change made to bartabcalculate btw

[bakkeby]

I see what you did there and why it may work. In principle it should be no different from including the systray width when passing the status text width to the bartabgroups calculate function. Something to take into account is that the systray may be pinned to a given monitor in which case this may potentially be off for monitors that doesn't have the systray when focused.

[par4m]

Well I guess I'll cross that bridge when I come to it, though I'm already reconsidering using dwm after this since patching is so time consuming.

[bakkeby]

I'm already reconsidering using dwm after this since patching is so time consuming

I feel you. It is certainly not for everyone.

What is even more time consuming is getting to a level where you no longer depend on pre-made patches and you can make your window manager do practically anything you can think of.

[par4m]

Well the most problematic thing I've found about suckless in general is the lack of support, it's bare minimum unlike the extensive support other wm's or any open source tools have as a community, all of that just to gatekeep it in the name of "elitism". Some YouTubers do cover suckless tools but most of time its just the basic stuff, after that it's more of a dead end as far as I know. You should highly consider starting a YT channel or something considering so many users you've made suckless tools accessible to with flexipatch, it's amazing.

[bakkeby]

As for support they do have some IRC channels (not that I have been there), but yes anything that is made to be more mainstream typically have more support or a bigger community around it. The elitism is kind of a part of the package and comes with the suckless philosophy. It is software by devout C evangelists for devout C evangelists, so if your mother tongue is C or you are at least fluent in it then you shouldn't really need any help in the first place. What is more problematic is the overarching negativity that seems to plague the community (if there is a community).

As for YouTube yes there is very little coverage and what is there is typically very superficial as you say. I suppose there are many reasons for that. Most of them are not really being that into programming (besides maybe doing some shell scripting) and it is a rather niche topic which likely doesn't bring many views or much profit.