
Hi. I recently changed from using xterm to sakura: * https://code.launchpad.net/sakura (primarily because the fonts in xterm look bad when scaled x1.5, and I have to do that on my stationary monitor...) The sakura windows automatically get a thin transparent border with XMonad, through which my desktop background image shows. I would like for this to not happen - as it is distracting. You can see the unwanted effect here: * http://koldfront.dk/misc/xmonad/sakura-xmonad.png compared to what it looks like with xterm: * http://koldfront.dk/misc/xmonad/uxterm-xmonad.png I have tried searching the sakura code and changing random things related to border, rgba, and transparent, but my wild guesses have not been fruitful. Does anyone have any good ideas? I am using running compton (I like the pretty, transparent notifications), in case that matters. OH! I just tried killing compton, and that removed the problem! I guess I should bark up another, uhm, mailing list? Hm, I found this: https://github.com/chjj/compton/issues/139 which is the same problem with another wm, compton, and sakura, and it seems the wm was fixed - so maybe I am in the right place after all? There are some hints here: https://github.com/chjj/compton/issues/240 about what might be the same issue in xmonad. Best regards, Adam -- "Hackers are lazy, in the same way that Adam Sjøgren mathematicians and modernist architects are lazy: asjo@koldfront.dk they hate anything extraneous."

On Wed, Jun 3, 2015 at 5:06 PM, Adam Sjøgren
The sakura windows automatically get a thin transparent border with XMonad, through which my desktop background image shows.
https://code.google.com/p/xmonad/issues/detail?id=581 -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Brandon writes:
On Wed, Jun 3, 2015 at 5:06 PM, Adam Sjøgren wrote:
The sakura windows automatically get a thin transparent border with XMonad, through which my desktop background image shows.
So I tried looking into this, being a newbie at Haskell and X11 programming. What it looks like to me, from the C-code needed in dwm in the issue above, is to try and look up the normal border color and the focused border color in the colormap of the window, instead of using the values found in the default color map. Ok, so how to do this? It looks like I can just change the two lines in the windows function in Operations.hs that set the border: whenJust (W.peek old) $ \otherw -> io $ setWindowBorder d otherw nbc [...] whenJust (W.peek ws) $ \w -> io $ setWindowBorder d w fbc Now, nbc and fbc are Pixels that are looked up in the default color map once, so they need to be replaced with Pixels looked up in the color map of the window (otherw or w). Good, so looking at the C-code, the color map of the window is found by asking the window's attributes, and grabbing it from there, and allocNamedColor then can be called with that color map and the name of the color, getting back an XColor, from which a pixel can be extracted. But, hm, when I look at getWindowAttributes: * http://hackage.haskell.org/package/X11-1.4.0/docs/Graphics-X11-Xlib-Extras.h... it returns IO WindowAttributes, but they do not include a color map entry: * http://hackage.haskell.org/package/X11-1.4.0/docs/Graphics-X11-Xlib-Extras.h... Hm. So, this is where I got to. Any tips? Best regards, Adam -- "I'm a driver, I'm a winner, things are gonna change, Adam Sjøgren I can feel it." asjo@koldfront.dk

Adam writes:
But, hm, when I look at getWindowAttributes:
* http://hackage.haskell.org/package/X11-1.4.0/docs/Graphics-X11-Xlib-Extras.h...
it returns IO WindowAttributes, but they do not include a color map entry:
* http://hackage.haskell.org/package/X11-1.4.0/docs/Graphics-X11-Xlib-Extras.h...
I have tried to make a pull request for adding this field now: * https://github.com/xmonad/X11/pull/35 Not quite sure it is correct, as I am just mimicking the existing code... Best regards, Adam -- "It made me nostalgic for Solaris 2, as I was power Adam Sjøgren cycling it for the fourth time." asjo@koldfront.dk

Adam writes:
it returns IO WindowAttributes, but they do not include a color map entry:
[...]
I have tried to make a pull request for adding this field now:
From testing it a couple of minutes, it works on my machine - the
It turns out that to make use of the new wa_colormap field, I need to change getWindowAttributes to throw an exception if XGetWindowAttributes() fails. So: * https://github.com/asjo/X11/commit/e5421307a02ea0cadcb381d282615d56a0e848c0 Then, to make xmonad-contrib compile, XMonad/Util/DebugWindow.hs needs adjusting: * https://github.com/asjo/xmonad-contrib/commit/e775872ac34c81e070e530a89f591e... And finally, I can change XMonad/Operations.hs to grab the color from the window's color map if available (it isn't when closing a window, so it is important to check the return value of XGetWindowAttributes() to avoid a crash - I had fun logging myself out when closing a window for a while!): * https://github.com/asjo/xmonad/commit/e7d0e004d0a1acfd1ff149eaabf274fe2519c4... ... mimicking the change done to dwm¹. transparent borders are gone from my Sakura windows, and the solid colour I configured in XMonad is used instead. Note thet especially the changes to XMonad/Operations.hs are in "try and try pounding at it again until it works"-style code, and any tips on how to write it better will be much appreciated. Best regards, Adam ¹ https://github.com/chjj/compton/issues/240#issuecomment-62245919 -- "God must've been punting angels left and right." Adam Sjøgren asjo@koldfront.dk

asjo@koldfront.dk (Adam Sjøgren) writes:
I recently changed from using xterm to sakura:
* https://code.launchpad.net/sakura
(primarily because the fonts in xterm look bad when scaled x1.5, and I have to do that on my stationary monitor...)
FWIW I tried out a bunch of terminal emulators last year and ended back on urxvt. Using xft fonts and the following plugin, font scaling works great: https://github.com/majutsushi/urxvt-font-size -- Peter Jones, Founder, Devalot.com Defending the honor of good code
participants (3)
-
asjo@koldfront.dk
-
Brandon Allbery
-
Peter Jones