On Tue, Jul 17, 2007 at 06:19:13PM -0500, Spencer Janssen wrote:
BTW, I've been thinking about it, and I do not see any other possible solution for the specific problem of blocking a thread and resuming it in two different cases: an event *or* the elapsed time. You need the real event or another thread that sends a fake event. Am I right?
It is possible, but annoying. It requires a magic version of nextEvent that doesn't block inside foreign calls. Thankfully, this isn't so hard to write with threadWaitRead and XPending. With this magic nextEvent, we can use asynchronous exceptions to interrupt the thread with a timer. I've sent you a patch that implements this.
I thought that having a thread send an XEvent to another thread was hackish, but your solution is the haskeller's way to hackerdom...;-) I think it is going to take me at least a couple of days to grasp your code entirely, but it works perfectly without that 30% increase in memory consumption. Without you I just couldn't do it. Thanks!
The next step, I think, is to remove the 'refresh' configuration entirely -- just have plugins throw exceptions to the event/drawing thread whenever they update.
Well, there is another use of refresh: in the output template you can set unix commands, and have an empty "commands" list, such as: Config { font = "-misc-fixed-*-*-*-*-10-*-*-*-*-*-*-*" , bgColor = "black" , fgColor = "grey" , xPos = 0 , yPos = 0 , width = 1024 , height = 15 , align = "right" , refresh = 10 , commands = [] , sepChar = "%" , template = "<fc=#ee9a00>%date%</fc> %uname%" } In this case we need a global refresh option otherwise I need to hard code a default value deep in the parsing routines. I don't think this is a good idea. Moreover, I think to have even monitors as plugins (enabled by default, though), this way the user can build a very small xmobar, with monitors disabled, just to run external unix commands. Thanks for your help! Andrea