Infrequently Noted

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


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.


It occured to me yesterday that the netWindows site doesn't practice what it preaches. It's more or less a static site with a NW toolbar at the top. How utterly dull.

I think that moving to an XML or database backend with some python or PHP in the middle talking to a netWindows component really is the better way to make the site work if I'm going to continue to keep hacking on this thing. I mean, why save the "good stuff" for the sample environment page? I think I started thinking about all of this after tripping over yesterday and being struck by the sheer simplcity of it.

But I don't have any idea what the NW component should look like or how it should behave. I think the behaviour is simpler than the look. I'm a back-end coder by habit and I like mucking in the bowels of an application/site. I'm good at it. Making it look nice? I wish I were good at that, but the harsh reality of life is that I'm not. So I'm open to suggestion on this one. Little boxes that you click and expand into things seem like a good idea. And they should get the content when requested. Not before. The whole site should be able to live on a single page (more or less). Not sure what to do about the help pages. They've got their own style sheet, and I think I'd have to write an addition to environ_core.js that lets me import styles from sheets into a running page. A big can of worms, that one.

Anyway, gotta go to another exciting and engaging (cough) poly-sci class. At least I've still got good books to read.


Perfectionism. It'll kill me yet.

I don't know why I spend countless hours dreaming up things to try, which turn into things to build, which turn into things that later need fixing. But I do. And I keep doing it. For instance, lets consider just my netWindows wishlist:

Each one of these additions or features will add to the already huge bug list for netWindows. Each of these will generate requests for clarification, documentation, explanation, and dissection from any number of corners. It's a lot.


Button widget comitted.

I'm almost embarassed that 0.2.3 is going to be out less than a month after 0.2.2, but I guess that's the way it all falls out sometimes. Anyhow, the new buttons support internal state management (i.e., they know when they are "active" and when they're "disabled"), can have images, are sizable to any size you choose, are fully themed, and they support both inline and programatic constructors.

On another note, I wish I had a good way to determine how much memory each object and component in the NW environment requires. But I suppose that needing memory optimization for DHTML is a pretty sure sign that I'm doing something unholy. Doesn't mean that I don't want it though.

A Fan

Just found this linked from Scottandrew. CSS and HTML reference in my sidebar? Yes please.

I'm such a fan.

Older Posts

Newer Posts