port lemonboy/bar to dwm-win32 for customizing status bar easily

[prabirshrestha]

Currently it is very difficult and cumbersome to change the status bar.

Might be good to port a simple status bar such as LemonBoy's bar to dwm-win32 so makes it easier to change status code.

Also another possibility is to add lua for customization similar to AwesomeWM but would be a bit overkill for now.

[gluonman]

The one adjustment that would be pretty handy would be if dwm-win32 allowed for the option of disabling the standard bar, but while still leaving a user-adjustable space for a bar. Right now, the standard bar can be disabled, but maximized windows will be drawn where the bar previously was. Adding this feature to leave a space for a bar even while dwm bar is disabled would seem to be a better solution than specifically porting in alternative bars to dwm-win32, as this would free up the user to try out any alternative bar they could find, and would be less work for you.

I am currently experimenting with a dwm-win32 + polybar setup that I have configured into a near-full solution (just working out one remaining issue). Here's how I've accomplished it:

1. Install rainmeter and run it. A handful of default desktop widgets (called modules) will appear on the desktop, and you can unload any of them that you don't wish to use, but make sure to leave at least one of them still loaded for now.

2. Now clone the khanhas/polybar repository somewhere, build it, and everything going well you should now have Polybar as an available rainmeter module. You may have to refresh or restart rainmeter to view the polybar module and be able to load it onto your desktop.

3. Once you have your polybar module loaded, feel free to unload any other remaining module you aren't interested in using, but be sure to disable the default shadow feature of the polybar, as this does not play nicely with dwm-win32 at all. Do this by right-clicking on the polybar and selecting "Edit Style" which opens a separate config module with an option at the bottom saying to "Open config file" which opens a textfile in something like Notepad. There make the following change:

# Change this:
Shadow=1

# to this:
Shadow=0

Then save the config file, right-click the polybar again and select "Refresh skin" and the shadow will be eliminated.

4. While the "Edit style" module is still open, feel free to pick a theme for the polybar, and adjust color scheme, size and position. Whatever you do to customize your polybar, of importance is to note the height you select for your polybar. In my case, I went with a height of 25. We'll call this {BARHEIGHT}. When you're finished with the styling, you can also click "Edit module ->" in the upper right to then select which items you want to have in your polybar and their placement, but that's for you to play around with on your own later.

5. Right click on the polybar, hover over the Rainmeter sub-menu, and click on "Edit settings" which will open a textfile once again, except this time the master config file for Rainmeter and not just the polybar module. Under the top-most [Rainmeter] section, beneath the "SkinPath=..." setting, add the following:

DesktopWorkAreaType=1
DesktopWorkArea=0,{BARHEIGHT},0,0

Just replace {BARHEIGHT} with the height you set for your polybar, which in my case is 25. So with a {BARHEIGHT} of 25, you would have DesktopWorkArea=0,25,0,0.

6. Now save the config and right-click on the polybar again and then hover the Rainmeter sub-menu and select "Refresh all." Then restart dwm-win32 and you'll find that dwm-win32 now treats the top of the desktop as {BARHEIGHT} greater than y=0, or as y=25 in this example.

And that's your basic dwm-win32 with khanhas/polybar solution, though it has a couple issues:

A) The first issue is that from what I can currently tell so far, you're generally limited to using a bar that rainmeter can treat as a module, which is why this khanhas/polybar solution works, since it is a rainmeter module. This is because you can place the module in the space between y=0 and y={BARHEIGHT} but you can't really put anything else there, including likely other bars that would just get pushed down to y={BARHEIGHT} like everything else. I haven't entirely figured out if rainmeter has an ignore list for windows that are immune to its rules, which would allow you to run any other bar that isn't a rainmeter module and put it in the ignore list. That would be nice. So I would call this a limitation in the sense that it requires rainmeter, which is not as desirable of a solution as being able to run an alternative bar without depending on additional software. Adding a topbar space-reserving feature to dwm-win32 even while the standard bar is disabled would solve this limitation and open the door to use any bar without needing rainmeter to redefine the top of the desktop area.

B) The other limitation arises when you seek to visually represent tag switching the way you can do natively with the dwm standard bar. The polybar is impervious to dwm-win32 tags. You can still switch tags because dwm-win32 is still working just fine, but you simply do not have the ability to manage your tags and see them represented visually via a workspace switcher in the bar. Polybar does have its own workspace manager built in, and you'll see that it's enabled by default on the polybar, but it uses a program called WorkspaceManager.exe. So if you change workspaces using polybar, you're not necessarily switching tags in dwm-win32. With the mix of the two workspace programs, it seems possible to have a window open on dwm tag # 1 in polybar workspace #3, but if you switch to polybar workspace #1 you'll find your window is nowhere to be found in dwm tag #1, or any dwm tag within that polybar workspace. It unintentionally creates a situation where you could have groups of workspaces inside of superworkspaces, which might actually be a neat feature for some people. The thing missing from it is a way to manage both tag and workspace switching from a single interface instead of two separate interfaces (MOD + # for tag switching and clicking on polybar workspace numbers for workspace switching). However, this really isn't what I want or imagine many others would want. I would prefer the polybar workspace switching to correspond to dwm tag switching, so that whether I use the dwm keybinding to switch tags or use a mouse left-click to switch workspaces on the polybar, I want the overall effect to be the same. As such, I am currently looking into whether I can control workspace switching with WorkspaceManager.exe with keybindings so that I can match its keybindings to the ones that dwm-win32 uses and thus sync the two actions. Alternatively, I'm looking into a way to hack the polybar workspacemanager module to instead trigger dwm-win32 events for tag switching and not even bother with WorkspaceManager.exe at all (I actually like that better). But of course, none of this would be an issue at all if you are happy to just opt out of having a visual workspace switcher in your bar to begin with.

Other than those two issues, khanhas/polybar with rainmeter plays very nicely with dwm-win32 and could work very well for a user as an alternative bar that's more configurable than dwm's default. But once again, if we could reserve space using dwm-win32 while the default bar is disabled, then it would allow for even more solutions, including a lemonbar solution, and you wouldn't necessarily be dependent on rainmeter or something else like it.

Although, if I wanted to try to make an external program call a dwm-win32 event programmatically such as a tag switch, how would I go about doing that? For example, if I want the program that gets triggered by rainmeter when I click on workspace 2 in my polybar to essentially call the same event that the keybinding MOD + 2 does in dwm-win32, what's a solution that you recommend I try?

[prabirshrestha]

My hope is to expose lua bindings so one can hook into anything similar to awesomewm where you get full control but we provide some helper apis to so you don't need to write everything from scratch.

In lua you get full control with with padding or custom layout. I also plan to ship a custom render where you can draw 2d on own without any third party deps. With something like microui you can build anything. A good showcase of lua with microui is https://github.com/rxi/lite. Other one I have thought of is https://github.com/Immediate-Mode-UI/Nuklear.

Communications across process can be done in many ways such as stdout/stdin which means I need to get some sort of api to control a process and read and write to stdin/stdout. I do plan to add others like socket, http. You can see awesomewm docs on the lua apis it exposes. https://awesomewm.org/doc/api/.

There are lot of great possibilities once we have complete lua api working.

[gluonman]

Okay, this all sounds great. I don't personally know lua yet, other than having simply toyed with some lua config files in the past, but however it is accomplished, having the ability to configure custom layouts, keybindings, etc. is absolutely required for a Windows port of dwm to claim to offer a legitimate dwm experience. I've just been a tad skeptical about doing things in this lua way, and a part of that is my bias toward how I am used to configuring dwm by just patching the C itself or editing config.h and recompiling, and also my desire to be able to just port my own dwm customizations from Linux into this project and test them out. Users who want awesomewm compatibility will probably love this. I'm just an old guy that wants to keep doing things in C lol. I already have custom layouts and keybindings in C that I want to just add here and try to mimic my Linux workflow on my Windows machine as closely as I can. Of course, though I haven't really played with it yet, I don't see any reason I can't just play with the source the way I want to and make changes in C anyway. Though I'm sure I'm going to have issues with the git pull.

[ysl2]

@gluonman Hi, have you tried this? I want to let this topbar cooperate with dwm-win32, but don't know how to do.

https://github.com/denBot/yasb