Re: DWM Hackers Unite! Share (or request) dwm patches.

Army wrote:

mkaito wrote:

It correctly removes the border when a window is displayed alone, but restores it when I view a tag on another monitor. Strange as hell...

Do you mean, that the borders are there, if you e.g. move a client to an empty tag on another monitor? Because in that case the border reappears too on my machine. I hardly move windows, so I never looked into it..

I suppose that would trigger the same kind of event. There's only three places in the code where border size is changed, and after fiddling with all 3 of them, I just have no idea where else to hack around. I'll have to try and figure out how windows are moved across monitors, I guess. Or why changing a to a tag with clients on another monitor A changes border size of clients on monitor B...

Re: DWM Hackers Unite! Share (or request) dwm patches.

c00kiemon5ter told me I could fix the floating clients issue with my singularborders patch by using XRestackWindows() instead of XRaiseWindow(). To do so, I need to create an array of all the clients but I'm failing to create this. I looked at monsterwm's code and adapted it to work with DWM, but something is wrong and DWM crashes.

I already sent c00kie an email, but he's not responding (and I never expected any help from him, since his WM is monsterwm and I'm asking for DWM hacking - no hard feelings c00kie) so now I ask here. Here's monsterwm's relevant lines:

Re: DWM Hackers Unite! Share (or request) dwm patches.

Trilby wrote:

Personally, though, I find it much easier, and more efficient to loop through all the clients and call XRaiseWindow on any that need to be raised.

Well, my issue is that to when I firstly created singularborders, some inactive borders would overlap the active borders. I fixed that by adding XRaiseWindow() into focus, but that caused floating clients dissapear behind tiled clients when I change focus to those. It does sound easier, but I'm not sure how I could do this. Would it be something like this? Also, would this cause much overhead when changing focus? Otherwise I might rather stick with this issue.

Re: DWM Hackers Unite! Share (or request) dwm patches.

I had a similar issue in ttwm. As the ttwm stacking mode requires rasing the focused window in the stack, it would raise above floating windows. I raise the floating window, then loop through all the windows and raise any floaters.

This will cost less than creating an array, filling it, and raising all those windows anyways. And it is only done when the tile function is called (right?)

I'm not on the system with the code right now, but I can give a specifc example in a bit unless you beat me to it and find it on github (it should be at the very end of the tile_mode function if I remember right).

Re: DWM Hackers Unite! Share (or request) dwm patches.

This will cost less than creating an array, filling it, and raising all those windows anyways. And it is only done when the tile function is called (right?)

Ah, yes. I was thinking this replacement for my XRaiseWindow() fix should also be put in focus(), but that might not be necessary..

Trilby wrote:

I'm not on the system with the code right now, but I can give a specifc example in a bit unless you beat me to it and find it on github (it should be at the very end of the tile_mode function if I remember right).

EDIT: This does work, but only when a new client appears I get the floating client back on top: as soon as I focus anything, it dissapears to the background again. It seems indeed that tile() might be the required function, but then again changing focus has nothing to do with tile() so it might not work at all.EDIT2: This isn't going to work. DWM handles this differently than TTWM. The tile() function has nothing to do with focusing clients, so putting it there has no effect. When putting it in focus, still have this issue. I guess I will have to stick with XRestackWindows and the array of clients...EDIT3: Putting the loop in restack() and calling restack() from focus() works, albeit with a brief flash where the floating client is. I'll see if I can remove the flash now, but at least this is a start.EDIT4: Adding a new function works without flashing:

Re: DWM Hackers Unite! Share (or request) dwm patches.

Your welcome - glad it got you somewhere. Indeed the differences from dwm would not allow it to work in the tile function - just just wherever the tiled window is raised one could loop through floating windows and raise each of them.

Re: DWM Hackers Unite! Share (or request) dwm patches.

i am trying to accomplish that when I press certian key it moves me from curtag to bgtag, and if i press it once more revert me back to prev tag. So far this is working for fist and seccond tag, for others 3 tags when I am in bgtag reverting to prevtag toggle first and second tag. So prevtag is messed with some bits. If I initialized prevtag to be 0, same thing happens, I am lost and will be glad to infom me litlebit and of course help me.

if I get it correctly i dont have TAGMASK passed to function, but I have arg as 0, so i dont get why if (arg == 0) isn't true, above solution only works. Better soulution would be with two if statements, for example: If i am on bgtag revert me beack to prevtag, if i am not then go to bgtag

NOTE: bgtag is not visible, it's 6 tag. I hide it in drawbar function with LENGHT(tags) - 1

Re: DWM Hackers Unite! Share (or request) dwm patches.

Here's another tiling layout I whipped up quickly (inspired by Trilby's TTWM). It basically is like tile(), but with monocle() in the stack. That means that there is a master client (complete with nmaster et all) and where normally the stack would be, you now see only one client. If you open a new client, it will be overlapping the previous stacked client and so forth. In the statusbar, it will display the numbers of clients in the stack, as well. Here's a diff against a vanilla dwm.c:

Re: DWM Hackers Unite! Share (or request) dwm patches.

Unia wrote:

Here's another tiling layout I whipped up quickly (inspired by Trilby's TTWM). It basically is like tile(), but with monocle() in the stack. That means that there is a master client (complete with nmaster et all) and where normally the stack would be, you now see only one client. If you open a new client, it will be overlapping the previous stacked client and so forth. In the statusbar, it will display the numbers of clients in the stack, as well. Here's a diff against a vanilla dwm.c:

Re: DWM Hackers Unite! Share (or request) dwm patches.

The nmasters and mfacts are something from the pertag patch, which I don't use (also, curtag is not part of the monitor struct outside of pertag.)

EDIT: Also, unia, you should think about just using git to manage your patches instead of keeping patches in a version control system.

You're right, I diffed it against vanilla but forgot to actually test it. About Git, I have no idea how it works. Plus, I feel this gives me more control.

This actually is a really cool patch. I'm thinking about editing it into another layout that has a configurable max amount of master and stack windows (so for gimp you could limit it to two in the stack and concentrate on a single image in the master area).

The Pro Git Book from the git website is a great resource if you're just starting out with git.

Re: DWM Hackers Unite! Share (or request) dwm patches.

I was thinking of modifying the tile() function so that we can (with shortcuts) enable deck layout or regular tile

I've combined these in ttwm-git in the rstack (or bstack) functions.

I have a stackcount variable (nstack might follow the dwm naming pattern) and maximum stackable variable - the latter changes as clients are mapped or closed.

I then have keybindings that increase or decrease stackcount to make the stack include more or less windows - and I have other keybindings that set stackcount to 1 or maxstack. which acts a lot like i3wm's toggling between a full stack of windows or a single window in tabbed mode. Toggling between 1 or maxstack would acheive the deck/stack change you are describing, if I'm understanding it right.

Inspiration for this design came from a request my HalosGhost in the forums. Feel free to check out the rstack() function if you think it may help.

Re: DWM Hackers Unite! Share (or request) dwm patches.

Doesn't it do that? I use dn = n -1. So when we have only one client (e.g. no stack) n is 1 thus dn is zero, thus it will not display anything.

EDIT: We could also implement something like monoclecount. That shows the total number of clients in the stack and the number of the client you currently have on top, like so: [5/16]EDIT2: Another small issue is that when we increment nmaster, the number of clients in the stack stays the same.EDIT3:

Solves the issue with nmasters. However, if nmaster is bigger than the amount of clients in the stack, it'll display a negative number (even though I still use if(dn > 0)). What's up with that?EDIT4: dn should be declared as a regular int, not an unsigned one.

Last edited by Unia (2013-03-23 22:28:30)

If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres

Re: DWM Hackers Unite! Share (or request) dwm patches.

Unia wrote:

Doesn't it do that? I use dn = n -1. So when we have only one client (e.g. no stack) n is 1 thus dn is zero, thus it will not display anything.

EDIT: We could also implement something like monoclecount. That shows the total number of clients in the stack and the number of the client you currently have on top, like so: [5/16]EDIT2: Another small issue is that when we increment nmaster, the number of clients in the stack stays the same.EDIT3:

Solves the issue with nmasters. However, if nmaster is bigger than the amount of clients in the stack, it'll display a negative number (even though I still use if(dn > 0)). What's up with that?EDIT4: dn should be declared as a regular int, not an unsigned one.

And it would display the number you have in nmaster as well, which could be useful if you're spawning a window and don't want to mess with something. (I realize it could be put somewhere else, but it makes sense to me.)