Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.


Today I came to realize the difference between 22 and 18. And it's not 4 years, it's the innocence I've lost in those 4 years.

I know it sounds stupid, but I feel somehow less me than I was 4 years ago. God, it seems like an age. The gulf of my years adrift in the same place divides the me now from the me then, and the distance traveled is what separates us. I haven't gone very far (geographically), but I've gone a long way. When I was 18 I had no clue how ignorant I was, and somehow it got me through until life (not so subtly) informed me otherwise. I keep thinking about my "promise", you know, that set of things you think you can do when you are just graduated from HS. You think you can break through walls, you think you can do anything, and the worst part of it is that you're right; and you know it. But what you don't know when you're 18 is that there's a price. You don't quite comprehend (no matter how often you're told) that life has a way of extracting a price and leaving you with less of that enthusiasm than you started.

Somehow I'm still the meandering, unfocused me I was 4 years ago, but somehow I'm not. I still have a motivation "problem" when it comes to school, I'm still kind of a prick, and some good people still seem to call themselves my friends (which I don't understand, really). I'm still not socially adept. I'm not a "people person", unless they are "my" people. I guess the thing that got me thinking about all of this was my realization that part of becoming a craftsman involves seeing deeper into a process (or feeling a need to) or project than I did before. It gives me something in caution that I didn't have before. It keeps me from making expensive mistakes. But sometimes I think that it's not always for the better.

I wish I still had the time to make expensive mistakes and not know it.

Hard Enough

The single most annoying thing about Python is that I expect it to be harder. I know that's totally strange, but I've been conditioned by years of programming other languages to expect to need a man page (or an O'Rielly book) to be able to pick up something new. To understand the API, I've come to expect JavaDoc-type verbose documents that explain every argument in the slightest detail.

But Python makes a good portion of that useless. It meets me where I am and uses what I know in ways that I'm comfortable with. It's the perfect language, the one I've wanted forever, and now that I have it, I don't know what to do with it. I get caught up in trying to find this reference or that book to make sure I'm doing things right. I get hamstrung by the very training that has helped me survive so many other languages.

This is totally maddening. It shouldn't be this easy.

Event Handler Problem Solved

The event handler problem is (more or less) solved.

Instead of the hacked up solutions I was proposing below, I've come up with a (possibly) better hacked up solution. What I'm proposing is that NW should define all event handlers needed to run the environment page for the page writer. No fuss, no ungodly long <body> tags.

But, of course, there's a problem. In IE, when I set an event handler programatically, I'm doing just that, setting it. Not appending to a set of handling functions, no, I'm just setting it. Mozilla's addEventListener function is much nicer, and can work in conjunction with inline definitions on tags, but alas I'm looking for a cross-browser solution here that doesn't suck, and coming up short.

Worst case (for now), we might have to dictate that page writers set handlers on the body function only through methods we define, and never directly on the tags themselves. It's onerous, and I'm not convinced that it's better in the short run, but I think it might be a good thing moving forward.

Time will tell.


So I just got out of a poly-sci exam. Allow me to relate the tale...

I overslept this morning, deftly sleeping through latin (and I wasn't there, making it worse). When I awoke, it was nearly noon. Not a good thing. My class starts at noon. Damnit.

On the upside, the bus doesn't come 'till 12:08 or so, so I've got 2 minutes to find socks, pants, a shirt that doesn't smell or look too bad, and schlep down to the bus stop. I find clothes (after a fashion) and make it down to the bus just in time. Now you see, my class is on the "far" side of campus as far as the bus route is concerned, so despite the fact that I got on the bus at like 12:10, I didn't actually get to class until 12:24. Remeber the exam started at noon. On the dot. I think I'm sunk.

So I arrive to class to find like 4 people left out of the 50 or so who normally attend. The prof hands me the exam and the scantron form. 12 minutes later, I hand them both back to him.

You know, I had expected more from some of my classes. I mean, this is a collage education I'm supposed to be getting, right?

I don't go to that class half the time because I know that if I show up every third class, read a bit, and attend at least one review session, I'll be able to ace the quizes and exams.


Good ideas are rarely convenient.

I've been trying to figure out ways to clean up the requirements that NW places on body tags for pages. Similarly, I've been trying to figure out ways to make keystroke events fire for the "selected" component, and nothing else, and today it hit me.

Instead of writing:

onmousedown=" __NW_env__.selectAndResize(event);

for each body tag, we should be able to something like:

onLoad="__NW_env__.onLoad(event);" //console omitted
onmousedown=" __NW_env__.onMouseDown(event);


and let each of those member functions of the environment core handle the dispatching. Better yet:

onmousedown=" NW_onMouseDown(event);


should also work, again dispatching each event to the proper functions and objects. I think such an approach will clean up environment pages considerably. But the part that's really exciting of my revelation was that for each of these new functions (likely memebers of NW_env), there should be an array of function pointers that widgets and components can add to and remove from at will. Each time said event fires, all of these FPs should also be called. Basically, each event will get it's own "registry" of function pointers. By doing this, we could put a bit of code in the component selection code that will allow us to "register" the selected component's keystroke handlers with the global event handler for keystrokes. The global handler can intercept any environment-level keystrokes, while passing the rest on to the registered FPs.

Modifications required to the core to make this happen:

  1. event specific wrapper functions in __NW_env__, register/unregister functions for FPs to each event.
  2. modifications to the setSelectedComponent() function to support FP registering
  3. modifications to the component class to support keystroke functions and registering with sub-components. Only top-level components should be registering with the environment, so sub-components should be able to register with the top-level comp for inclusion in the chain.
  4. modify earth days to include an extra 12 hours in order to have time to implement this.

The really exciting (I think) part about this approach is that it's going to let us do really neat effects based on events (movement, keystrokes, etc...) that would have required much more elaborate changes previously. In this way, we're exposing infinately extensible "hooks" into each event via the environment core. This way we can keep the environment pages clean and still give ourselves enough flexibility moving forward.

And I just finished the environment page tutorial. Damnit.

Older Posts

Newer Posts