summaryrefslogtreecommitdiffhomepage
path: root/samples/xmobar.config
diff options
context:
space:
mode:
authorJose Antonio Ortega Ruiz <jao@gnu.org>2012-09-11 01:54:42 +0200
committerJose Antonio Ortega Ruiz <jao@gnu.org>2012-09-11 01:54:42 +0200
commit3e7c8cf1a4cd9ea86fd7d1dce13e305dd09fb6fe (patch)
tree6bdbb5531b0ea777fd14fded17889083792cf67d /samples/xmobar.config
parentba95216a359acea6a8e41e10d279dbaa85561084 (diff)
downloadxmobar-3e7c8cf1a4cd9ea86fd7d1dce13e305dd09fb6fe.tar.gz
xmobar-3e7c8cf1a4cd9ea86fd7d1dce13e305dd09fb6fe.tar.bz2
Avoiding X server leaks with XftColor cache
This patch is a first complete solution to the long-standing memory leak (on the X server side) caused by repeteadly asking the server to allocate XftColor instances. Despite the fact that we were freeing them, the server didn't seem to care... this was also happening for non-Xft Colors, and solved in the same way we'd done here, i.e., by caching XftColor instances. And additional complication has been that Graphics.X11.Xft doesn't export any function to create and retain an XftColor, nor the necessary datatype constructors to write a compatible version outside the module (there's no way to construct an XftColor instance to pass to the other functions in the library). So, i've created my own lite version of the whole module, until the day it supports XftColor creation.
Diffstat (limited to 'samples/xmobar.config')
0 files changed, 0 insertions, 0 deletions