Archives / Search ›

If you're not familiar with Frontier or Radio, just ignore the rest of this post… it probably won't make much sense!

Almost there, but I'm stuck. I figured out a way to embed #directives in an OPML file so they aren't visible, but ran into problems calling Radio's rendering scripts from the saveWindow callback.

radio.webServer.setTemplate refers to pta^.path, but radio.html.publishStaticPage doesn't set the 'path' attribute of the pagetable, and it circumvents any attempt I make to set a pagetable. I should have checked this before carefully constructing a fake pagetable to pass it… as is, the only way to insert directives is by modifying radio.data.website.[“#prefs”], which is horribly ugly. radio.data.website is the fake website framework root in which Radio pages get rendered (always in the same place, radio.data.website.default) before being upstreamed.

It turns out publishStaticPage is only called from a try within a webserver request. This may indeed be a dead codepath, and any exceptions caused thereby are simply ignored.

More digging to commence next weekend. I should probably start with radio.upstream.getUpstreamText, which is definitely called, and write the file into the www directory myself, letting the standard upstream mechanism deal with it. However, writing rendered files into the www directory is against the philosophy of Radio as I see it, so it's an ugly hack at best.

Or, perhaps, I could do the opposite: upstream the OPML file by somehow turning off #flRender, and letting regular upstreaming handle everything else.

Thanks to my sustained hacking effort, I didn't get a chance to convert the icons. That I can do tomorrow, though…

I love the humanity of code, especially when I find a particularly colorful statement in it. For example, in Frontier.tools.windowTypes.callbacks.openWindow, there's a bundle of commented-out code with an interesting comment.

Jim has a new design! Very nice looking! (Keep it!)

Weird, Radio seems not to be receiving receiving updates from Bill Bumgarner's weblog. He's posted a lot in the last few days and I hadn't seen a word of it. In particular, there's a very thorough developer's introduction to Mac OS X, full of lots of useful information. It's not often I read such a large amount of advice which I completely agree with, but in this case, I couldn't find a single point of argument.

Well, perhaps one. He doesn't mention Mozilla as a viable OS X browser. See below.

Mozilla weblogs: a nice index. Among those I hadn't seen before, Matt Judy wrote a concise statement on Chimera. I agree with everything he says. I don't want to see Mozilla on Mac OS X take a back seat to Chimera either, because currently Mozilla is ready for me to use as my primary browser, and Chimera isn't. I have used Mozilla as such for a month now. The number of annoying bugs I encounter on a daily basis in Mozilla is now very small (counting 'lack of speed in new window opening and general interface performance' as one bug), and otherwise are:

  • keyboard shortcuts, especially the Return key, don't function in OS dialogs (save, print)
  • naming of saved files is erratic, sometimes adding file extensions where inappropriate
  • menus in the Personal Toolbar activate when dragging over them, even when Mozilla is not the active application
  • history is poorly implemented (see Windows IE for a very nice implementation, and Mac IE/OmniWeb for tolerable ones).
  • bookmarks are poorly implemented (same as above, but Mac IE far surpasses other browsers I've seen here)
  • you can't Command-click on a bookmark to open it in a new tab
  • if Mozilla can't load a page in a tab or window, it doesn't display the URL, making it impossible to know which page you wanted if you try to reload

On the other hand, I'm starting to miss many Mozilla features when I use other browsers, especially Mac IE. These include tabbed browsing, intelligent forms auto-fill, decently functional form fields, and rendering speed. Mozilla has also largely stopped crashing for me; CrashReporter's logs indicate that it hasn't crashed since Sunday the 21st, and I've been using it several hours a day since.

I've discovered the bottleneck I was looking for in instant outline rendering, and I should be able to fix all the problems I documented yesterday in one fell swoop.

Still need to convert the toDo icons with GraphicConverter… will do when I get frustrated when my code doesn't work. :-)

‹ Newer Posts  •  Older Posts ›