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

Thanks for the quick replies guys.

Bohoomil - this is the approach I was thinking about. I was going to use xrandr to get the resolutions and calculate the centre in a wrapper script, but I'm not sure how the script would know which monitor the xterm window will be displayed on.

JokerBoy - I was initially hoping to avoid patching dwm.c, but its probably not a bad idea for me to start looking at this. So I think I'll try out your patch. Multumesc!

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

Thanks for the other suggestions.

@OK100 - I installed this, but it's not really the look I was after, and there were quite a few gtk dependencies I had to install. Also, my issue really was around displaying the shutdown window centered, which this doesn't address. But thanks for the suggestion - it's still good to know about it.

@Army - Using dmenu is a great idea, I hadn't thought about that option. But even so I'm gonna stick with the window for now since I spent a while getting it to look right. The keycode works for my shutdown button too - so thank you for sharing that - it's ideal. In my script I've used ConsoleKit and dbus to trigger the shutdown/restart (I added suspend and hibernate too), but I think I'm going to go back to using sudo shutdown like your script - it's much simpler - then I can uninstall ConsoleKit.

@JokerBoy - I got your patch working perfectly. It works great with multiple monitors too. I had to patch it manually because it looks like it has dependencies on some of your other patches. Your other patches look really useful too though, so I think I'll be borrowing a few of those too :-) I'm guessing that the numbering of each diff file is for the dependencies?

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

madders wrote:

@JokerBoy - I got your patch working perfectly. It works great with multiple monitors too. I had to patch it manually because it looks like it has dependencies on some of your other patches. Your other patches look really useful too though, so I think I'll be borrowing a few of those too :-) I'm guessing that the numbering of each diff file is for the dependencies?

I know it does I was using a dual-monitor setup till a few days ago.. The numbering is for keeping track in which order they can be applied. Cu placere.

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

Hey I'm trying to bind Mod + Tab to go to the next tag, and Mod + Tilde to go to the previous tag, but now that I think about it, I'm going about this the wrong way.

I've heard that tags are used differently than workspaces, and I read an article shared on this thread, but I still don't understand the workflow of pulling in tags and sending them out again, vs simply switching to # tag.

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

Hey I'm trying to bind Mod + Tab to go to the next tag, and Mod + Tilde to go to the previous tag, but now that I think about it, I'm going about this the wrong way.

The cycle patch does this.

I've heard that tags are used differently than workspaces, and I read an article shared on this thread, but I still don't understand the workflow of pulling in tags and sending them out again, vs simply switching to # tag.

Can someone enlighten me?

Just forget the workspace analogy and think in terms of pulling sets of different apps into view at any one time. I work from my first tag "base" and if I want to check mail, I just pull in that tag, do what I need and then togle it back out of view. Same with the other tags.

The one hack I would like to see to make this work seamlessly for me is to be able to pull the new tag to master, rather than into the stack.

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

wolfcore wrote:

I've heard that tags are used differently than workspaces, and I read an article shared on this thread, but I still don't understand the workflow of pulling in tags and sending them out again, vs simply switching to # tag.

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

Hey I'm trying to bind Mod + Tab to go to the next tag, and Mod + Tilde to go to the previous tag, but now that I think about it, I'm going about this the wrong way.

The cycle patch does this.

I've heard that tags are used differently than workspaces, and I read an article shared on this thread, but I still don't understand the workflow of pulling in tags and sending them out again, vs simply switching to # tag.

Can someone enlighten me?

Just forget the workspace analogy and think in terms of pulling sets of different apps into view at any one time. I work from my first tag "base" and if I want to check mail, I just pull in that tag, do what I need and then togle it back out of view. Same with the other tags.

The one hack I would like to see to make this work seamlessly for me is to be able to pull the new tag to master, rather than into the stack.

steve___ wrote:

wolfcore wrote:

I've heard that tags are used differently than workspaces, and I read an article shared on this thread, but I still don't understand the workflow of pulling in tags and sending them out again, vs simply switching to # tag.

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

Hello,

Somehow I can not get DWM to start after (succesfully) having applied statuscolor patch. There are no errors during patching and no errors uring compiling, but when X starts with my DWM session, no bar is showing and none of my keybindings work. All I see is my dzen2 and conky. I start DWM with a startdwm script as found in the Wiki but there is nothing at all in the ~/.dwm.log file.

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

Unia wrote:

Hello,

Somehow I can not get DWM to start after (succesfully) having applied statuscolor patch. There are no errors during patching and no errors uring compiling, but when X starts with my DWM session, no bar is showing and none of my keybindings work. All I see is my dzen2 and conky. I start DWM with a startdwm script as found in the Wiki but there is nothing at all in the ~/.dwm.log file.

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

stlarch wrote:

Unia wrote:

Hello,

Somehow I can not get DWM to start after (succesfully) having applied statuscolor patch. There are no errors during patching and no errors uring compiling, but when X starts with my DWM session, no bar is showing and none of my keybindings work. All I see is my dzen2 and conky. I start DWM with a startdwm script as found in the Wiki but there is nothing at all in the ~/.dwm.log file.

I took the config.h and patch from OK100's GitHub, but after his patch didn't work I picked Jokerboy's. They both patched without errors, so I don't think/suspect anything is wrong with either the patch or the config.h. You have more experience than I have though, so I'll try JWR's now

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.

How can I check if there are any clients associated with a tag? I want to have a keybinding that either opens a program in a specified tag if there is no program with that tag, or execs toggleview to that tag if the program is already running.

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

is there a way i can move a floating window behind one that is maximized? It seems that even if focus is on a window in the background and there is a non-tiled window open, it has to be open in the forground.Thanks for any tips.

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

I have yet to catch up on this thread; I'm up to page 16 and I plan to skim it all for good ideas, but I have one "patch" of my own which isn't worth a patch file but I like:

Make the layout symbol (or icon, thanks to termsyn font) a different color (with colorstatus patch) by changing line 472 of dwm.c in function drawbar

drawtext(m->ltsymbol, dc.colors[4], False); // changed [4] from [0]

This may seem simple, but as I had to look for the right line to change, this might speed/ease the process for someone else.

EDIT: It's line 472 after the color status patch has been applied to an otherwise "vanilla" dwm 6.0

AFTER-THOUGHT: If others find this useful, and given this line is already changed by the color status patch, perhaps the patched line could be adjusted to include a constant that would be placed in the config.h. In other words

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

REQUEST: hide unfocused windows in monocle layout

Coming from xmonad this is a behavior I took for granted. In dwm's monocle mode if I have a semi-transparent terminal ("true" transparency w/ xcompmgr) focused in monocle mode, I end up seeing other clients behind the terminal rather than the desktop.

While I know I could switch to pseudo-transparency, it ends up a bit choppy and ugly (when urxvt is resized it takes a moment to redraw the background).

If anyone has already implemented this please let me know. Alternately if you know a good place to start, hints would be appreciated. Otherwise, when I get some time, my plan is to look at the transparency patch to get hints on where to start. I figure this is a good start as if I can get dwm to set all non-focused clients to fully transparent in moncle mode only I'd have the behavior I want.

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

I need some help "creating" a patch. In the March screenshot thread, I saw a scrot of Kaptenen's DWM which had colors bars on the tags instead of the squares. He linked me to a January screenshot topic post that explained how to do so and so I am getting those bits together in a patch. The first half works, but the second doesn't. As soon as I add the ltcol stuff, I get

dwm.c:773:9: fout: ‘ltcol’ undeclared (first use in this function)
dwm.c:773:9: note: each undeclared identifier is reported only once for each function it appears in

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

Hm, I took the parts from that patch that mine didn't have and integrated them, but now the lines above tag names look "off center" in regarding to the tag names. You can see here in the scrot:

The only part I didn't integrate from yours is the last, because I couldn't find any lines in my dwm.c that looked like that. Perhaps this is the cause?

EDIT: I took a second look, and it's not the lines that're off - it's the tag names. Without the patch, there's a little whitespace between the left edge of my screen and the first tag name. With the patch, there's none. Here's a normal one to compare:

Last edited by Unia (2012-04-08 20:00:26)

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