Infrequently Noted

Victory is mine! (at least in mozilla).

getComputedStyle (on moz) and offsetHeight (proprietary MS bs) saved the day, allowing me to grab calculated height values for the main split-pane widget and use those to set a height value for the bottom pane in the horizontal configuration.

I have no idea how (or even if) the linked sample page is working on IE, so if you find that it's borked please let me know, providing browser version, your email address, and a general description (or screenshot) of the problem.

Now about that data table widget...

I've spent roughly 12 of the last 24 hours attempting to coax the split-pane widget into doing my bidding, but it's apparently having none of it.

The problem:

Friday morning as I showered, I realized that I could replace a large chunk of the code in the data table widget by using a horizontal split-pane with a fixed size top pane. The only problem with this plan was that upon further examination, I realized that the CSS formatting of the split-pane widget was, um, not working right.

This in mind, I had at least 2 problems (up from one and change). I'd feel like quite a pud shipping a broken split-pane widget, espically after the 13p article. Resolved to fix the split-pane widget, I attempted several iterations using relative and absolute positioning, tables, and just about everything in between. The primary problem is that the widget attempts to fill it's container without knowing anything about the dimensions it is supposed to fill. While this isn't a problem when splitting in the vertical direction, it becomes an issue when splitting in the horizontal.

Using divs with their "float" attribute set to "top" and "width" set at "100%", it's possible to create an arbitrary set of horizontal blocks that will fill their container both vertically and horzontally. To split in the vertical, set float to "left" and "height" to "100%" instead.

The split-pane widget uses this technique to create 3 divs: one for each of the "panes" and one for the draggable bar in the center. The first pane (either leftmost or topmost) will have it's primary dimension (the dimension not set to 100%) set to some value in pixels, while the bar will have an appropriate width or height specified. The other pane div should then fill in the rest, allowing us to resize both of the panes by simply changing the primary dimension on the first pane. None of the panes have to know how big their container element is. In fact, the container may not have explicit dimensions set, and it's this scenario that occurs frequently in netWindows, as that's how the internal space of the window widget is constructed. "windows" are simply tables with their middle row's height set to "*", therefore there is no pixel value to consult for height.

This layout approach works like a charm when the pane set is constructed to vertically split a space, but when splitting in the horizontal, content longer than the height of the bottom pane (the top pane is fine) spills out of the bottom of the panes, irregardless of how the "overflow" property is set. The only way correct this is to set a "height" value for the bottom pane, but this requires knowledge we don't want to need to know: the height of the container (and the continued height of the container of it changes).

Several solutions exist to this problem, but I like none of them, as they require that the pane set know it's container and that the container have an explicit height value set. Mozilla's getComputedStyle seems to provide an "out" to the 2nd condition, but the first still nags a bit, not to mention that getComputedStyle isn't available for IE.

Looks like I'm going to have to add a bit of hackery to the pyMail app after all. Oh how I wish it could have been avoided.

After all the noise and fury about a Python blog system, Matt and I have finally started working on something that might form the kernel of such a thing. There was much compiling and gnashing of teeth involved in getting the bsddb3 data store working, but we are now masters of our collective ZODB installations. The working name for our blogware is "brainFeed". Which brings us to the next point: does that name suck?

Yes?

No?

Consider this a contest of sorts: you send me a better name than "brainFeed" for a Python/ZODB/netWindows based weblog system, and I will personaly install and configure the system for you when it's complete. Include a nifty logo and I'll up the ante to include template design and integration as well as arranging for hosting of your blog for the period of 1 year (subject to my hosting provider's AUP).

So to recap: send me a really good name, get a fully functional copy of the system to try out when it's done. Send me a good name and a great logo, and you'll get not only a configured system, but also template design and hosting for your shiny new blog.

Prizes are non-exclusive, so get cracking and be the first one on your block to be able to say "neener, neener! I've got an OODBMS backend for MY blog! pbhbtttt!"

In my haste to fix the Mozilla history bug, I failed to regression test against Konqueror, leading to a bug that hindered loading of the NW codebase on that browser. Things now seem to be fixed for all Konq 3 verions.

Not quite sure how I missed it, but damn