Code by Kevin

About
Code by Kevin, Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.



Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

Privacy Policy

Site design: Skeleton

 

Thu, 19 Nov 2009

Which HTML renderer?

One of the most comical aspects of my programs over the years has been my repeated gear-shifting over how to display help documentation in my applications. Apart from the other reasons I've discussed--dissatisfaction with Apple's built-in help viewer chief among them--part of the issue has been my continuing search for a suitable HTML renderer. Tk offers several different approaches, but none are optimal.

For the past couple of years I've been using my own html display package, tkwebview. It's an updated version of an ancient Tk package (mid-1990s vintage), built on Tk's text widget, that can parse and display basic HTML. This package has the virtue of simplicity, being composed entirely of scripts, and it doesn't require any additional compilation. However, it's rather slow to render HTML, and when an HTML pages has numerous images, its scrolling performance is noticeably slow and jerky. (An unavoidable limitation of Tk's text widget.)

As a result, earlier this year I examined two other HTML rendering packages, both of which are written in C and require compilation: TkHTML 2 by D. Richard Hipp, and its successor, TkHTML 3 by Dan Kennedy.

TkHTML 2 is a fast, lightweight renderer for basic HTML. Over the years it has been widely adopted, documented, and supported by Tcl/Tk developers, which means that it is fairly easy to adopt and use in applications. The main problem with TkHTML 2 is that it is rather old (last updated in 2002), only supports basic HTML with no support for more recent web advances such as Cascading Style Sheets (CSS), and is hard to build, at least on the Mac. (A colloquial term for this is called "bit-rot," meaning that the code has not kept up with its environment.)

TkHTML 3 is an ambitious attempt to provide a more modern HTML rendering widget for Tk that supports both CSS and JavaScript. It underwent intensive development from 2005-2007, and in that time, an impressive, nearly full-featured, TkHTML-based browser (HV3) was one result. However, development on TkHTML 3 has come to a complete halt, and the widget has not gained widespread use among Tcl/Tk developers. It is considerably more complex than TkHTML 2, and no common set of best practices for incorporating the widget into an application has emerged (in sharp contrast to TkHTML 2).

After evaluating both options, I finally opted to use TkHTML 2; George Petasis, the author of several widely-used Tk extensions including TkDND, assisted me in getting it built for OS X. While TkHTML 2 is essentially obsolete, it is sufficient for my modest needs: it displays basic HTML, much faster than my earlier text-widget-based package did. It provides everything I need, and nothing more. It would be nice to take advantage of TkHTML 3's features, but I would be largely on uncharted ground: I'm not aware of any simple TkTHML 3-based help viewers out there, just the enormous HV3 browser (which is overkill for my needs).

Another, intriguing possibility down the road is to tap into the Cocoa-native WebKit frameworks on OS X. Daniel Steffen put together a sample project that embeds a Cocoa WebKit view inside a Tk widget. Very cool. However, at present, this method does not allow fine-grained control of the HTML view from Tk; all of that is turned over to Cocoa. For instance, I want to be able to control whether a page is displayed in the web view or loaded into an external browser; WebKit provides hooks for this, but it's not clear to me whether they can be controlled from Tk or not. As a result, I won't be integrating WebKit into my applications anytime soon, although that may be a longer-term project after my other projects--and new applications--are released.

[/general] permanent link

More Tk infrastructure

The blogging has been quiet lately, and work on new applications is on the back burner right now, but I'm plenty busy. I'm working on some low-level Tk infrastructure projects to fill in some serious gaps in the toolkit's functionality.

The first project is porting TkDND to run on OS X. TkDND is a Tk extension that provides platform-native drag and drop capabilities to Tk windows. While this package has been in existence in one form or another for nearly a decade, it's never been supported on the Mac, just Windows and Unix. With Tk finally running on Cocoa, I've decided to add TkDND to the Mac. I'm making good progress on implementing "drop" support--dragging files, text, and URL/bookmarks from the Finder and other applications to a Tk window. "Drag" support--dragging text and other elements from a Tk window to the desktop, for instance--is proving much harder, and I may not implement that feature. (This feature is also missing from TkDND on Unix.)

Drag and drop is the most important project. After this is done, I plan to look at implementing Mac sheets for windows other than dialogs in Tk (dialogs, such as message notifications and saving/opening files, already work as sheets); native (Cocoa-based) Mac printing; and providing additional methods to access native Mac icons in Tk. All of these projects will be released as open-source when they're finished.

It's common for unpaid, open-source programming to originate from the developer's desire to "scratch an itch"; that's true in my case. Sheets, drag-and-drop, and native printing are all features that I've wanted in my own applications for a long time. Until this year my programming skills in C/Objective-C/Cocoa were not equal to the task. I'm still no expert in Cocoa or Tk at the C level, indeed I still have much to learn, but now I feel competent to take on these projects. When they're done, they will make my Tk applications much more pleasant to use.

[/general] permanent link