Wandering Thoughts archives

An irritating X Windows limitation with wheel mice

I use what I call 'lazy focus follows mouse' in my window manager (fvwm2 calls it SloppyFocus): the last window that the mouse touched has focus, but the mouse doesn't have to actually stay inside the window. I like this because it means that I don't have to have the mouse cursor obscuring some of the window contents.

(I am not a fan of click to focus, but that's another entry.)

Unfortunately, this exposes an X limitation in how it handles wheel mice. The problem is in two parts; first, turning the wheel produces mouse button events, and second, X sends mouse button events to the focused window only if the mouse cursor is actually over it. Thus I can't touch a window, move my cursor away, and still use the mouse wheel.

(I believe you would see the same issue with click to focus, although I'm not sure.)

How it should work is that mouse wheel events should be like keyboard events, and thus get delivered to the focused window regardless of where the mouse is. I tend to believe that this is actually how people see the mouse wheel; it's less like clicking a mouse button and more like hitting a key on the keyboard.

This issue is one significant reason that I don't like wheel mice. (Another is that the wheel generally steals the middle mouse button position, so that actually clicking the middle mouse button requires more force and is more error-prone; I use my middle mouse button a lot more than I would use a wheel. I would probably like a three button wheel mouse that put the wheel under my thumb and left the middle mouse button alone, but I have no idea if they make such a thing.)

Link: Serif vs. Sans Serif Legibility

Which Are More Legible: Serif or Sans Serif Typefaces? by Alex Poole is a review and summary of a whole pile of writing about this. I'll cut to the conclusion (don't worry, it's not a spoiler since Alex Poole puts it in the first paragraph of the introduction):

To date, no one has managed to provide a conclusive answer to this issue.

Alas, none of this helps me configure liferea to improve its legibility on a 17" CRT monitor. (I would be happy if I could just clone a Firefox setup, but this is stupidly difficult and/or impossible for no good reason.)

(From someone I chat with online, when I was asking around about this.)

Weekly spam summary on November 25th, 2006

This week, we:

• got 13,435 messages from 269 different IP addresses.
• handled 21,900 sessions from 1,620 different IP addresses.
• received 197,361 connections from at least 50,069 different IP addresses.
• hit a highwater of 8 connections being checked at once.

This is down from last week, although the connection numbers are still up a bit compared to two weeks ago.

This shows no signs of any lingering surge from last week's huge wave; the fluctuations are pretty typical.

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes
213.29.7.0/24         21761   1306K
207.235.5.169         13648    819K
213.4.149.12           9110    474K
208.99.198.92          7501    450K
208.99.198.71          6627    398K
208.99.198.93          6601    396K
64.65.197.93           6484    303K
208.99.198.94          6235    374K
64.166.14.222          5667    272K
208.99.198.66          5393    324K

This is a rather different week:

• 213.29.7.0/24 is where centrum.cz's outgoing mail servers live. We've received too much advance fee fraud spam from them to be interested in talking to them, and I've moved up to blocking their /24 rather than play whack-a-mole with individual active IPs there.
• 207.235.5.169 is 'potter.aper.net' and kept trying to send us stuff with an origin address that had already tripped our spamtraps.
• 213.4.149.12 is terra.es, returning from last week and many, many times before.
• all of 208.99.198.64/27 is that rarity, an active SBL listed spammer; they are SBL48200, aka 'totallyfreeld.net', aka 'The Client Store'. They get upstream connectivity and their IP address space from 'Swift Ventures Inc', aka swiftco.net, which currently has a number of SBL listings, one for a ROKSO spammer dating back to June 3rd.
• 64.65.197.93 kept trying with a bad HELO name.
• 64.166.14.222 also reappears from last week; it is a PacBell DSL line.

If all of SBL48200 was counted together, it would be the leader at 58061 packets or so. (We blocked them one by one this week, so that's how they get counted up here.)

This is clearly up from last week, with multiple highly active would-be senders, some of them repeats (especially the terra.es machine, which just keeps trying like a certain commercialized rabbit).

Connection time rejection stats:

  42352 total
  24394 dynamic IP
  13850 bad or no reverse DNS
   2504 class bl-cbl
    332 class bl-dsbl
    228 class bl-sdul
    156 class bl-sbl
     99 class bl-njabl
     62 class bl-spews
     37 class bl-ordb
     22 cuttingedgemedia.com

Evidently we caught SBL48200 early enough that they didn't make a big dent in the SBL numbers.

Four of the top 30 most rejected IP addresses were rejected 100 times or more; the leader is our friend 64.166.14.222 (at 452 times, which right away means that it has some problems), followed by an internal IP address, 211.52.83.131 (177 times) and 70.68.66.159 (110 times). 19 of the top 30 are currently in the CBL, and 3 are currently in bl.spamcop.net.

This week's Hotmail numbers:

• 4 messages accepted; at least two of them were spam.
• no messages rejected because they came from non-Hotmail email addresses.
• 31 messages sent to our spamtraps.
• 2 messages refused because their sender addresses had already hit our spamtraps.
• 3 messages refused due to their origin IP address (two from Nigeria, one for being in the SBL (and also located in Nigeria, apparently)).

And the final numbers:

Despite the change in accounting from last week, the bad bounce stats haven't particularly jumped; I guess that most places already weren't trying to send us multiple bad bounces in one SMTP transaction.

This week's champion bad bounce target was 'kiseleeva_margarita', at 24 tries. My friend 3E4B made a return, and first_last stuff seems to be up from last week. The top two sources of bad bounces are it.valmi.com.ua (217.25.199.249) and verify-sender.lucky.net (193.193.193.135), along with a pile of similarly located servers, so it seems that we're a popular forgery target with spammers targeting Eastern Europe.