« I had a big history exam the next day and the only copy of the Fedaralist Papers that I had was *abridged*! | Main | I'm just not white like you Dave »

Jimmy has fear? A thousand times no!

Yesterday, I sent the following e-mail to the xwrits author (xwrits is a program that periodically pops open a "take a break" window on my screen to give my wrists a rest) with the following suggestion for his excellent program:

Thanks for xwrits! I think it has saved me much pain... literally.

I have a suggestion.

I have found it convenient to schedule breaks with xwrits, not just for my wrists, but also for taking care of non-computer-related stuff (take out the trash, feed the cat, make sure that the laundered money showed up in my swiss bank account, etc.).

As such, it would be convenient to know (at least approximately) when the next xwrits break is coming.

So when one of my henchmen says, "Hey boss, we got a big player on table 6; you wanna fix a 'special' deck for the next shuffle?" I can say, "Yeah, sure -- I'll do it in about 7 minutes when I have to take a break, anyway."

Here's some random idea on how it could work -- any one of the following methods of showing the time left until the next break would be great (or something even better / easier to implement would be fine as well!):

  • a dockable toolbar app (for KDE or Gnome or whatever)

  • a small window that could sit in the corner of my desktop somewhere -- independent of the main xwrits popup window

  • a specific keystroke (in any context, which could be kinda hard) could bring up a window for 2-5 seconds before automatically closing

Such functionality would be most useful, if possible.


A helpful LAM user found a really obscure name clash with LAM's tputs() function and the termcap/ncurses tputs(). Kudos to Glenn!

I mentioned a few days ago about a LAM user having a problem that I couldn't duplicate. It turns out that this might be due to linux's implementation of TCP/IP -- it seems that after long periods of inactivity when there is data ready to be read on the receiver side, the sender will declare "timeout" and kill the socket. Doh! It's not clear if this is Linux's fault, or is part of the design of TCP/IP, or if Linux's timeout value is just short. Either way, it would be a real pain for us to put in proper heartbeats on the TCP RPI. Arf. I'm hoping that TCP/IP has a "stayalive" functionality that will do its own low-level heartbeats, but I'm not hopeful. Gotta check Stevens sometime soon about this...

2 level decomposition of my dissertation code seems to work, but I think there's a minor memory leak in the RelayOut class. Should be easy to fix, but it's late and I'm tired.

804 xmms's running, out of 876 total, 92%.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on April 24, 2001 12:56 PM.

The previous post in this blog was I had a big history exam the next day and the only copy of the Fedaralist Papers that I had was *abridged*!.

The next post in this blog is I'm just not white like you Dave.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34