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

The following notation will be used: [MASTER][STACK]. If you have n tiled windows, i will number them 1,2,...,n . The notation [1][2|3] means window 2 and 3 are in the stack, windows 1 is in master.

I wish for two functions :

1) Move focus between master and stack. Suppose you currently have 3 tiled windows, [1][2|3]. If your current focus is 2, then this function would move you to 1, applciation again would land you at 2. It would never go to 3, only moving between master and stack. If you started at 1, it would be most natural to land at 2, then back again after re-application [some choice would have to be made, but it doesnt really matter]

2) Move focus up and down the stack, never to master. So suppose you had [1][2|3|4]. and you start at 3. Then you'd move 3->4->2->3 [of course the function could take arguments so you could move 3->2->4->3]. Never to 1. Only within the stack.

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

It sounds like going back and forth between *one* window in the stack and master. I did this with ttwm (and now alopex). You could check out of the window() function for "focus alternate" for the implementation. It does require a global window or client pointer to specify which stack window last had the focus.

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

jasonwryan wrote:

How does this differ from Mod-{j,k}? If you are just moving focus; this accomplishes what you are asking. If you want to move a window from master to stack, look at the push patch.

I'm trying to emulate vim like movement in my window management. So horizonal movement would be movement between the master and stack. Vertical movement would be movement within the stack only. This makes sense in the default tiling mode.

Mod--{j,k} cycles your focus between all windows, regardless if the window is in stack or master. I would like the more specific movement as outlined in my previous post.

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

^^ I can appreciate wanting to hold to vim-like muscle memory, but this won't save you any keystrokes, so you'd in effect be writing new code and learning two new keybindings without any improvement in comfort or efficiency. Maybe I'm mistaking your intent (though Trillby's idea seems to make sense), but here's what I'm seeing:

Say you've got three windows on-screen---two in the stack and one in master. Moving to the bottom window in the stack would require either one keystroke moving counter-clockwise, or two keystrokes moving clockwise. The simplest implementation of what you want would require you to perform one keystroke to switch from master to stack (or vice versa), and another to move down to the last window in the stack since, again, this is the simplest implementation (a single "master-stack switch" keybinding to one point in the stack), rather than just cycling to it counter-clockwise. Add a fourth window to the screen (third in the stack), and getting to the middle window would require two keystrokes, and the bottom one three keystrokes. You could of course make it so the switch between master and stack moves either clockwise to the top or counter-clockwise to the bottom depending on your keybinding, but now you're using the same operation as the default tag cycling with the same number of keystrokes, but now those keystrokes are divided between two-to-four different keybindings. Your fingers are doing the same amount of work (or arguably more), while you've added extra mental hurdles to your workflow.

Incidentally, what you're looking for sort of exists in tmux, but again requires keybindings that can occasionally get tedious, especially relative to DWM.

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

ANOKNUSA wrote:

^^ I can appreciate wanting to hold to vim-like muscle memory, but this won't save you any keystrokes, so you'd in effect be writing new code and learning two new keybindings without any improvement in comfort or efficiency. Maybe I'm mistaking your intent (though Trillby's idea seems to make sense), but here's what I'm seeing:

Say you've got three windows on-screen---two in the stack and one in master. Moving to the bottom window in the stack would require either one keystroke moving counter-clockwise, or two keystrokes moving clockwise. The simplest implementation of what you want would require you to perform one keystroke to switch from master to stack (or vice versa), and another to move down to the last window in the stack since, again, this is the simplest implementation (a single "master-stack switch" keybinding to one point in the stack), rather than just cycling to it counter-clockwise. Add a fourth window to the screen (third in the stack), and getting to the middle window would require two keystrokes, and the bottom one three keystrokes. You could of course make it so the switch between master and stack moves either clockwise to the top or counter-clockwise to the bottom depending on your keybinding, but now you're using the same operation as the default tag cycling with the same number of keystrokes, but now those keystrokes are divided between two-to-four different keybindings. Your fingers are doing the same amount of work (or arguably more), while you've added extra mental hurdles to your workflow.

Incidentally, what you're looking for sort of exists in tmux, but again requires keybindings that can occasionally get tedious, especially relative to DWM.

You make a good point!

I guess in most situations [i rarely have more then 3 windows open at a time], thebehavior would be more or less the same as Mod--{j,k} (sry jasonwryan).

However, in the 4 [or more generally, even numberd] window case, you could have thefunction move you to the middle window in the stack and it would be a max of 2keystrokes to get wherever you wanted from master. Thats the same as it is now, butperhaps a tad more elegent in this case?

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

Asking for a bit of help here, recent upgrade to urxvt-unicode-patched made think it's time to ditch it for something with fontconfig. Termite was the option I went with, my issue is that I cannot seem to get scratchpad or mutt working. To be honest I got scratchpad working while using urxvt with some Goolefu and was always pleased with it.

I found this, but I believe I maybe a bit to much of a novice to get it.

I am assuming the '-name' was something exclusive to using urxvt and I think I am missing the 'WM_NAME'

In my Google search I was able to find a config using termite and the work around I am seeing is to still use urxvt for things such as scratchpad and mutt. Which I can do but was hoping to make a full switch. https://bitbucket.org/jasonwryan/dwm-pa … a3fed1789a

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

I tried what you had suggested and it did not work. I am willing to search through this whole thread but is Simon a user name here or the real name to the to vodik? I remember a user by the nick simon.awe Sorry on my confusion as I don't know any of them on a real name basis but I do thank you for the input.

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

Would anyone have a patch, or would be kind enough to write one, to make my tasks have my separator used by my statusbar?I got stumped trying to do this, help would be greatly appreciated. Example screenshotExample 2: tags<task1<task2<task3<statusbar<trayHopefully that makes sense.

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

invisibleman__ wrote:

How do you hide the focused window name from being displayed on the status bar? I know its in dwm.c somewhere.I managed to hide the squares from being added next to tags with open windows by commenting out the drawsquare functions, but how about the focused window title?

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

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

Yes, you're supposed to alter dwm.c and config.h. Find the relevent spot in dwm.c (ivoarch hinted at it) and make the appropriate alterations; then add the "static" bit to config.h. Incidentally, the way that ivoarch wrote the dwm.c instructions is very close to how .diff files look; so if you ever have to manually apply a more complex patch to DWM, this'll be a good bit of practice.