text: I have not looked at their code - but they'd have to be using the first or third.
  Could you show me some pointers on how to implement number 3? This seems to be the way to go.
  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
  Offline
  That's where I'd start. I have no more knowledge of that than you do.
  OK, actually I know some relevant search terms: Xlib, xrender extension or openGL, opacity
  Last edited by Trilby (2012-11-19 21:57:00)
  Online
  OK, actually I know some relevant search terms: Xlib, xrender extension or openGL, opacity
  That's what I was looking for. Thanks
  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
  Offline
  ^ That's what I tried at first, but this doesn't restore the border when you switch to another layout. I'll play around with it and see if I can fix it.
  EDIT: Done! See the final version here: … fixes.diff
  This one removes the border when in monocle mode and restores it when changing layout (even if there's only one client open) and when you make the client float. (And it also doesn't show the border under the systray anymore
  )
  Last edited by Unia (2012-11-20 11:11:52)
  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
  Offline
  @unia
  I think this is sufficient
  Last edited by ivoarch (2012-11-20 19:00:20)
  Offline
  @unia
  I think this is sufficient
  It is
  Thanks!
  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
  Offline
  Here is a cool binary clock patch for dwm:
  Binary clock
  The only problem I am having is that it is not updating with my statusbar script. Every time something changes on the bar like next song, volume etc. It automatically gets overridden . Then I need to either restart dwm (hopefully I have a patch for that.) or wait for next minute to change.
  Some suggestion would be helpful.
  Thanks
  Offline
  You should be able to speed it up by changing the tv_period values to {1, 0} for example.
  EDIT: sorry, I had answered my own question before posting ... then I forgot to delete the question.
  Last edited by Trilby (2012-11-22 23:23:42)
  Online
  It is at line no 94. [ run ( ) ] in the mentioned patch.
  I have {3, 0} in the patch but in the source I am using, I already have {1, 0}
  Still no luck.
  Last edited by illusionist (2012-11-22 23:25:08)
  Offline
  You could speed it up more with {0, 250000}.
  But as you reduce the time interval you will see an increase in cpu use. I use a 250ms select loop in status and it only takes ~0.1% cpu use of a fairly low end (aka old) cpu. But if you get into the 10s of milliseconds it will eat up the cpu cycles.
  DWM's approach to status info isn't really meant for this, so there is no ideal way to do it. If you could change dwm to only update the status when there is new data from the user's status script this problem would not exist.
  The suckless team's idea to get status info from the root window title was a stroke of creative genius when it was first used - but it often doesn't work as well as it could anymore. And once you implement a select loop to read from fd's in the main loop, there are *much* more efficient ways of syncing up a stream of data.
  Last edited by Trilby (2012-11-22 23:30:21)
  Online
  Thanks for the explanation Trilby,
  It does eat a little cpu. But I think "tv_period" is not the problem here . What ever value i give to that , the text from my status script is sometimes behind the binary clock and sometimes completely overrides it.
  What could that be ?
  EDIT: Does converting my bash status script to C has any benefit ?
  Last edited by illusionist (2012-11-22 23:44:58)
  Offline
  Changing the tv values will only speed up the rate at which this problem is
  corrected hidden - it will not fix the problem.
  The problem is from this patch written in such a way that dwm is taking input from two sources that are not syncronized and there is no shared buffer space to allow for the two steams to do their own things.
  Converting to C always has benefits!
  But I doubt they'd really be relevant here. A good bash script is better than bad C any day, and the event loop implemented by that binary clock patch is just not that well done.
  The best thing to do would be to excise the binclock code out from dwm entirely, have it run within your script, then your script can pass your script stuff along with the binary clock characters to the root window title which is read by dwm. This would allow for much more moderate speed updates to be handled seemlessly.
  Of course if you wanted to, this would create a great opportunity to recode your status script into C to integrate it with the binclock - but what I described above could have the binclock as it's own compiled binary called from your script.
  As an aside this proded me to make an example binary clock for RectaBar (my status tool) which I just put up on github.
  Last edited by Trilby (2012-11-23 00:43:13)
  Online
  Hmm... I got your point . Making a compiled binary of binclock sounds easier. But I will try both the methods and see what works best for me.
  Thank you for your time .
  Offline
  Hmm, did you write the binclock patch yourself? If so I hope you don't take offense at me saying it was not well done. In fact I've been trying to imagine how to improve it, and given the way dwm handles status info, I don't know of any good way to implement this without massive changes to dwm.
  So the fault isn't with the patch as dwm has essentially tied our hands with the approach they took to status information so that this type of creative add on is very difficult to code to work well.
  Online
  I found the patch in the wild, did some minor changes, that's it.
  Since I am already using so many patches, I don't think it is a good idea to play further with the dwm code. The binary clock should have its own code. Do let me know if you get it working. I am curious.
  Offline
  Hi Friends, can anyone give me the patch to remove double borders between two tiled windows and maintain only a single border between them. Many thanks.
  Using Openbox + Tint2 + Idesk
  Offline
  @Trilby
  Here is a binary clock in C. But it has separate hours and minutes. Is there anyway to merge them both in one string like previous one.
  Binary Clock in C
  Offline
  Sorry I can't make heads or tails of what that is supposed to do. When I run it I get loads of gibberish coming out. What do you want it to do? Do you want each binary bit represented by a different character? If so that would be much simpler than that code - see my version below. The creative part would be using box characters to represent multiple-bit portions.
  Here's one with just pipes or dots for hours minutes and seconds with no separators:
  #include <stdio.h> #include <time.h> int main() { time_t now; struct tm *tinfo; int digit,bit,hms[3]; for (;;) { time(&now); tinfo = localtime(&now); hms[0] = tinfo->tm_hour; hms[1] = tinfo->tm_min; hms[2] = tinfo->tm_sec; for (digit = 0; digit < 3; digit++) for (bit = 5; bit >= 0; bit --) { if (hms[digit] & (1 << bit)) putchar('|'); else putchar('.'); } putchar('\n'); fflush(stdout); sleep(1); } return 0; }
  EDIT: for a slightly modified version with only hours and minutes and the possibility of adding separate color codes for each, see here. The shell escape codes for color in the printfs can be replaced with the appropriate character codes for dwm colors if you use statuscolors.
  EDIT: YABC: Yet another binary clock. Now I just have to figure out how to print unicode characters from C...
  Last edited by Trilby (2012-11-23 18:14:28)
  Online
  I've been playing around with dwm a little, and I wanted to replicate the tile-attachment behaviour that catwm and it's various spinoffs were using, and I thought that the attachaside patch from suckless.org would do the trick, as the picture that describes it's function is what i'm after, but the patch dosen't behave like that in reality(it dosen't do what the 3'rd pic suggests).
  What I mean is that I want new windows placed in the stack and below eachother, but the attachaside patch places new windows in the stack above eachother and not below.
  I've searched alot and found a patch called attachbelow, which nearly does what I want, but it's dependant upon which windows currently is focused, and then places new windows below the focused window, but I want new windows placed below in the stack, no matter what window is focused at the time...
  I've tried making various changes to the attachaside patch, but I cannot make it work unfortunetly, and so I wanted to ask if anybody knows of such a patch, or maybe knows what needs to be changed in it?
  Thanks in advance!
  (btw, i'm still primarelly using and loving monsterwm, but just wanted to have a little play with dwm on the side...)
  Offline
  I disected the relevant stuff from dwm-sprinkles, so here's dwm-6.1-attachaslast.diff.
  Last edited by mhertz (2012-12-04 01:23:03)
  Offline
  Crap... I just now discovered that the attachaslast patch I made, has a flaw; the 'zoom' function(mod1+return) dosen't work anymore! Oh well...
  Anyway, i'm finished with playing with dwm now, so I wont be looking into fixing that...
  Last edited by mhertz (2012-12-06 01:52:40)
  Offline
  Couldn't leave it hangin´ like that
  Fixed dwm-6.1-attachaslast.diff.
  Offline
  The focusonclick patch at dwm.suckless.org does not work with resizemouse and the movemouse functions because of the Async changes in the patch. Does anyone have a version of the focusonclick patch the works with resizemouse and movemouse?
  Offline