Taxing Health Care Benefits

I read a NY Times article a few days back about taxing healthcare benefits to pay for some of Obama's healthcare reform plan. I thought, practically and politically, it's a bad idea, but it's one of the best ideas I've heard (and McCain had it first, if we believe the article). The political downside is touched on in the article when they talk about Clinton's attempt (which I should look up) and how people who had and enjoyed healthcare benefits were upset to have them taxed. Really though, to me, that's why this is such a good idea.

The very idea that one's own free or subsidized healthcare should not be taxed to assist in providing others with healthcare comes from the fact that we live in a society where we believe that discrimination based on income is acceptable. This is evidenced by the dearth of socialized services, the state of those services, and the stigma we attach to them and the people who use them. If we didn't think this discrimination were okay, we would be working toward some form of socialism.

This situation reminds me of the guy in Michael Moore's documentary Sicko (I think he's some sort of academic) who is explaining the perspective on healthcare in the UK. According to him, we could think of it as similar to universal suffrage. We think of universal suffrage (overtly, at least) as common sense. When there is a society that doesn't practice it, we call them names like "backward" or "oppressive". But it wasn't always that way. The idea of universal suffrage had to be force-fed over and over and over to Western society. The same is true of universal healthcare systems where they exist. It's common sense.

So if people get upset over a move like this...well, them's the breaks. As long as it's contributing to quality universal healthcare (and I don't imply that it will), then it's worth it. And that's critical: we don't just need healthcare, we need GOOD healthcare. And we're gonna struggle for it, because we also need to change people's minds about universal healthcare (and other socialized, life-affirming services too). We need it such that, if someone can't afford private healthcare on their own or with (taxed) employee assistance, they don't say "man, now I'll have to use universal healthcare;" instead we need them to say "man, good thing there's universal healthcare." It can't just exist. It must exist out of love of people and love of life.

before bed...

I watched Wall tonight while trying to fix my hard drive. It's a documentary about the Israel West-Bank barrier wall.
I don't think that the movie is necessary to point out the absurdity of the project. It's a huge wall. More than that though, it's people who believe that building a huge wall is a good thing to do. And the wall does something, no doubt. Constructing a gated community of that magnitude can't happen without effect.

• Read the Butter Battle Book by Dr. Seuss. It remains one of my favorite pieces of international relations literature.
• The film reminds me of what I've learned about documentaries, and why some folks that I've known consider them more misleading than dramatizations. It's cause documentaries are collections of real "Fakts", as Harvie Krumpet would put it. They're stories told by the people behind the camera (who, in the case of Wall, are never seen).
• It also reminded me of how many stories and fakts there are out there to hear. It reminded me of the places that I want to meet people.
  

Event Handling in OIWL

I've been trying to pull inspiration for the design of the OIWL widget library from a few places. One set of places, of course, is other widget libraries that I use (like wxpython and gtkmm) or admire (like android.widget). For example, many libraries that I'm fond of use semi-automatic placement of widgets within layouts, so I decided to use layouts pretty liberally in my design.

I'm having difficulty deciding how to handle events though. Here's some notes:

• Only Frames (i.e. MIDP Canvas objects) actually receive user events. A frame must then pass information of the event along to its Widget objects.
• Some events should block others. For example, if I'm going to flick a frame, I don't want buttons to think that I'm looking to click them. Likewise, if I'm clicking a button that's on top of another, I want to be clicking the top button and not both of them (notwithstanding the fact that my buttons shouldn't be overlapping).
• I'm thinking a WidgetParent should pass user events down to its direct children. Its children can choose to handle the event and block others from handling the event (return true) or not (return false). If none of its children blocks the event, then the parent can then choose to handle and block or not. Seems reasonable every time I think about it. I think it's simple enough if all the events that one cares about are pointer presses, drags, and releases. However, there are still issues:
• Consider "complex" events like clicking (i.e. a pointer press and release without leaving the widget or without moving from the same spot), double clicking, and flicking (i.e. pointer press followed by drag and a pointer release while the pointer is still moving).
• More concretely, consider the case of a button on a frame or widget that can scroll. There are instances when it's infeasible to require the user to press a portion of the screen where there are no widgets in order to drag the frame -- like in the case of a list frame, in which the entire view is covered by what are essentially buttons (list items). How then would we distinguish the first part of a button tap (pointer down) from the first part of a view scroll (pointer down)?
  But maybe the question answers itself. Both a button tap and a view widget scroll should be assumed to be started by the pointer press. However, when the pointer starts to drag, the view widget should check whether the button wants to handle the drag event. When the view widget learns that the button does not want to handle the drag, it should assume that it should begin scrolling and tell the button (and all of its child widgets) to cancel whatever in-progress events they have.

So I'll try implementing this model: When the Frame receives a pointerPressed, it calls its layout's handleEvent method with the event type (Event.PRESSED) and the location data. The layout will then pass the event and data along to all of its children's handleEvent methods.

The first thing a given widget will do upon receiving the pointer press notification is check whether its children can satisfy an event with it. If one of them can, the widget will tell all of its other children to cancel their in-process events and it will return true.

If none of a widget's children can satisfy an event with a given user input, then the widget has three options. If the widget doesn't care about pointer pressed input, then it will simply and immediately return false. If a widget needs the Event.PRESSED to start an event (like a button tap), then it will mark that event as started, but still return false. If a given widget can complete an event with the Event.PRESSED, then it will cancel all of its children's in-process events and then do whatever it does on that event and return true.

New Blog

This is my blog. At the moment, the only inteded use I have for it is project updates, announcements, and notes. The impetus for me creating it is actually to have a place for posting notes about the OpenSIWL or OIWL or OIL or whatever I'm calling it these days (http://code.google.com/p/opensiwl/).