Yabai: Statusbar Y-Offset to avoid clash with -menubar

[kawtharrr]

Hi, firstly great app, thanks for your effort on this one :) even smoother than chunkwm

Currently, with the system menubar active, the yabai statusbar is hidden/behind it and unusable

(indeed, when I first activated it, it took me a minute to realise that the yabai statusbar feature isn't broken, but incompatible with the on-by-default macOS menubar)

Is it currently possible to offset the statusbar Y co-ordinate?

Couldn't find anything in the docs - so perhaps this is more a feature request? e.g.statusbar_offset on pushes it down by x px, the standard menubar height?

Rationale
Design-improvement - makes config statusbar on unambiguous, per good design principles. Currently, under default macOS config it's not immediately clear that statusbar config on is successful
General feature-request - adds a significant usability & accessibility improvement, removes compromise between menubar or statusbar

As it's an already-existing config for statusbar, this still avoids clashing with its inherently simple and limited-by-design philosophy while making it usable under default macOS config (visible menubar)

[koekeishiya]

Can't be done through config, but you can always edit src/bar.c to change its position.

[FrankLA0203]

@kawtharrr did you figure out a way to edit src/bar.c to achieve that functionality? I want to do the same thing but I have no clue where to edit.

Also just to bring up an issue with the fixed status bar, while using XQuartz application windows like zathura and sxiv, the title bar of the window gets hidden behind the yabai status bar so it becomes impossible to move the windows around. I know from chunkwm that window manages on mac can't handle XQuartz because of API issues but is there a way to solve this problem in another way?

[koekeishiya]

The following edits should be enough to have the statusbar be drawn at the bottom of the screen, instead of at the top.

change https://github.com/koekeishiya/yabai/blob/master/src/bar.c#L273 to
SLSSetWindowShape(g_connection, bar->id, 0.0f, bounds.size.height - 26.0f, frame_region);

change https://github.com/koekeishiya/yabai/blob/master/src/bar.c#L476 to
SLSNewWindow(g_connection, 2, 0.0f, bounds.size.height - 26.0f, frame_region, &bar->id);

remove this line: https://github.com/koekeishiya/yabai/blob/master/src/display.c#L87

[FrankLA0203]

@koekeishiya thank you so much! Sorry it might have been a dumb question because I'm not that fluent in C.

[adinapoli]

Resurrecting this thread out of interest: @koekeishiya , is there any technical showstopper as why this cannot be done via config? I suspect something as simple as a status_bar_position <top|bottom> configwise would cover 99% of the use-cases.

(ps. thank you for your great work on chunkwm before and yabai now 😉 ).

[adinapoli]

I have tentatively opened a PR: https://github.com/koekeishiya/yabai/pull/302

[koekeishiya]

is there any technical showstopper as why this cannot be done via config?

Well, yes and no. As I mentioned in https://github.com/koekeishiya/yabai/pull/287,

I'm not really interested in having changes to the bar upstream. It is meant to be pretty dumb and simple, which is why the code is written as it is. I don't think adding tons of commands such as these is the proper way to design a bar that people can customize. It should be done from scratch in a modular way.

I don't really want to accept changes that just build upon the current design, because it is inherently not a good way to approach this problem. I am currently working on separate side projects and so making a proper extensible bar to go along with yabai is not a priority of mine.

[adinapoli]

Oh, I see. I didn't notice the other open PR, had no clue it was trying to
fix the very same thing.

No harm done, I have compiled a version that works for me so I am OK in
closing my PR. I will wait for your new side project though, as I am also
eager to ditch Ubersicht and not lose changes to my code every time I
update yabai (and I cannot be bothered with maintaining my own fork).

Thanks again!

On Fri, 8 Nov 2019, 12:34 Åsmund Vikane, [e-mail] wrote:

is there any technical showstopper as why this cannot be done via config?

Well, yes and no. As I mentioned in #287
https://github.com/koekeishiya/yabai/pull/287,

I'm not really interested in having changes to the bar upstream. It is
meant to be pretty dumb and simple, which is why the code is written as it
is. I don't think adding tons of commands such as these is the proper way
to design a bar that people can customize. It should be done from scratch
in a modular way.

I don't really want to accept changes that just build upon the current
design, because it is inherently not a good way to approach this problem. I
am currently working on separate side projects and so making a proper
extensible bar to go along with yabai is not a priority of mine.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/koekeishiya/yabai/issues/220?email_source=notifications&email_token=AADL5M6TPB7J5KAJ7BCWRS3QSVFFHA5CNFSM4IPIILMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDQT67I#issuecomment-551632765,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADL5M453SU6HKFYPZJUJTLQSVFFHANCNFSM4IPIILMA
.

[koekeishiya]

The PR I referenced isn't for this exact change, but it is a different kind of change to the statusbar. They both follow the same pattern of simply expanding the set of available commands, which is not the way I want this to develop.

[kawtharrr]

Any chance of convincing you that adding an offset option might actually align with your overall objections i.e. that as more features get added it will eventually become more modular - maybe even a plugin - and so break away from the current limited paradigm (as long as additional PRs are submitted and designed with that endgoal in mind)? 😁

[koekeishiya]

Any chance of convincing you that adding an offset option might actually align with your overall objections i.e. that as more features get added it will eventually become more modular

Not really, as the current design is just flawed in general for that purpose. However, I do agree that the bar should automatically offset if the Apple menubar is visible. This is trivial to fix and should just always happen. For people that run with the Apple menubar hidden there will be no difference.