About
Code by Kevin: Programming, code, business, and other pursuits
Your Host
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
2010
2009
2008
2007
2006
Categories
Business
Software
General
Thu, 19 Nov 2009
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.
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.
Sat, 19 Sep 2009
64-bit Tk-Cocoa and embracing limits
After releasing NameFind last month to mixed reviews, I am now knee-deep in updating my applications to work as 64-bit programs under Tk-Cocoa.
I'm finding some pleasant surprises. Many minor interface glitches and performance problems that persisted under Tk-Carbon have magically disappeared under Tk-Cocoa. Some users, for instance, complained about slow scrolling and image redraw in NameFind, which draws a lot of images in its tableview. The higher performance of 64-bit seems to have fixed this problem. Similarly, the broken help menu search function in Tk-Carbon now works as expected in Tk-Cocoa.
I'm also finding some knottier issues that Tk-Cocoa can't magically fix. A couple of reviewers of NameFind complained about the way its toolbar is laid out. Doesn't look native, they grumbled. They're right. It's a custom Tk-based toolbar widget that tries to imitate the Cocoa-style toolbar--not very well, in their view.
This is actually a very hard problem to solve. The "unified toolbar" style that started with Cocoa applications and is now very prevalent on the Mac is not easy to implement in Tk. I've tried patching Tk at the C-level to draw a metal-style, textured window in a way that integrates well with Tk--but it has major problems with screen redraw, flickering when the window's resized, and so on. It looks good at first, but induces more and more nausea as you go on. So I've abandoned metal windows.
I'm starting to come to terms with the fact that even as Tk is now a 64-bit-capable, Cocoa-based GUI toolkit, thanks to Daniel Steffen's hard work, Tk still doesn't entirely fit in to Mac UI fashions, and perhaps never will. A huge amount of work I've done over the past few years has been fueled by my insecurity about this issue. Perhaps it's time to stop worrying about this issue altogether. It focuses on Tk's limitations, rather than playing to Tk's strengths--it's a powerful toolkit for rapid development. Its customizability means one can go a long way toward making it fit in with its platform, but it does have limits.
I'm wondering if, instead of trying to emulate the UI fashion of the week on the Mac, I should focus on following the best practices of the leading commercial Tcl/Tk application developer, ActiveState. ActiveState makes developer tools for scripting languages, and targets Windows, Unix/Linux, and OS X. It makes extensive use of Tk in its applications, some of which cost several hundred dollars.
Here's a screenshot from the Mac version of an ActiveState product, the Perl Dev Kit, which uses a Tk GUI:
Looking at this, you'll see that this application has a very polished user interface, and one that fits in fairly well on OS X. It uses native widgets in its table display--the discolosure triangle, the Aqua column headers, the system shading in the window, and so on. It also uses native buttons in the toolbar. The toolbar itself isn't native, but does it really look that out of place? Having played with a demo version of this application, I think it's quite professional, and does not feel out of place at all.
I've spent years trying to work around the fact that Tk isn't completely native on the Mac. Striving to fit in with the platform has yielded fruitful results. In general, the UI polish of my apps has greatly improved. Incorporating user feedback has helped improve the usability of my programs. Paying closer attention to these issues has also allowed me to contribute feedback and even code to Tk's core on the Mac, where the native platform integration takes place--and where improvements in the integration pay the biggest dividends. I will continue to do this as time allows; I have some open-source projects on my plate for later this year that will continue my work along this path.
But I have to wonder: does the toolbar in NameFind really look better than the toolbar in the ActiveState application?
I used to think so; I've spent a lot of time trying to achieve the "iconbutton" look of the Cocoa toolbar, in which just the image darkens. But now I'm not so sure. Perhaps my time might have been better spent in adding features that would really make my programs unique. A basic "button bar" would have taken much less time, much less trial and error, and, as the ActiveState application shows, would have looked no less professional.
As I get closer to releasing a 64-bit version of NameFind, and bringing the rest of my applications to the 64-bit Tk-Cocoa foundation, I'm leaning toward leveraging Tk's strengths for rapid development of a polished user interface, and not worrying so much about where it doesn't perfectly integrate with OS X.
Fri, 07 Aug 2009I'm shifting gears a bit, and pulling back from Tk-Cocoa to focus on new application development. After using Tk-Cocoa to get a new application almost ready for release, I've found a couple of major bugs that have reminded me that Tk-Cocoa is still very much in a beta state. It hasn't undergone widespread production use, nor (to my knowledge) been tested much by outside developers besides myself. So, while I remain very excited about its new features and promise, my use of Tk-Cocoa for now is going to be focused on testing, bug reporting, and bug fixing.
In the meantime, I have about half-a-dozen applications in the works, and Tk-Carbon remains a stable and not-yet-obsolete platform for developing them. So, over the next several months, I'll plan to release several new applications. After that, it's my hope that Tk-Cocoa will be fully ready to rock!
Mon, 04 May 2009I get inspiration for GUI design from some unlikely sources:
This homely screenshot is from PgAccess, a now-defunct Tcl/Tk GUI for the PostgreSQL database. You may wonder why I draw inspiration from a database GUI that uses ugly icons, and seems more at home on Unix than on the Mac.
The reason is that this user interface, although not as slick as what you typically see on the Mac, is considered examplary in the Tcl/Tk community for the quality of its UI design. Here's what I like about it:
The example of PgAccess is a major reason why I incorporated these particular widgets in my applications: see this entry for an example of how I use them in my programs to implement Cocoa-style GUI's in my programs. The fact that PgAccess hardly looks like a Mac application doesn't mean much; the cosmetic aspect is actually the easiest one to deal with. Using more modern, Mac-style icons, setting colors and spacing accordingly, and you get very close to Mac conventions without too much effort.
I have considered using other widgets in my apps. BWidgets is not actively developed anymore, and it's quirky--some parts of it are powerful, such as the tree, but other parts of it are broken and nearly unusable. Tablelist is actively developed, and is one of the simplest-to-use and best-documented Tk widgets available--it has earned its considerable popularity among Tcl/Tk developers. However, it is most useful for simple list displays, and can't do certain things that other widgets can, for instance blending a tree and list display in the same view. (See the Finder for an example of how this works.) Also, both widgets are script-level (Tcl-based) widgets, and thus are slower than widgets coded in C, a compiled language.
TkTreeCtrl is an extremely fast, powerful widget code in C that can do just about anything you want, but it is enormously complex. (The tutorial for TkTreeCtrl is intimidating in itself.) TkTreeCtrl is widely used in commercial Tk applications with complex GUI's, but it is probably overkill for my needs; also, as a binary extension that requires compilation, it's not clear whether it will work with the forthcoming Tk-Cocoa branch of Tcl/Tk.)
Another, somewhat less complex widget is the ttk::treeview widget that is new in Tcl/Tk 8.5. It can provide a tree, list, and combination view, something that neither the BWidget or Tablelist libraries can. It also compiles just fine with Tk-Cocoa. However, the ttk::treeview widget lacks some important functionality that comes out of the box with Tablelist, such as sorting of data in the display. Tablelist supports this with a single command, but a developer has to add this to ttk::treeview. Also, ttk::treeview lacks visual cues to indicate when data is sorted, such as an up-or-down arrow in the column view. Again, Tablelist includes this out-of-the-box. Finally, it's not clear to me how configurable ttk::treeview is; developers' general experience with the ttk themed widgets is that they are great in their default values (they are designed to conform to platform conventions out of the box), but they are much harder to customize.
Given that I'm able to do nearly everything I want to with BWidgets and Tablelist, it's likely I will continue to live with their minor drawbacks and use them in my applications. And I trace that all back to PgAccess--homely on the surface, but clean and designed with care.
Tue, 28 Apr 2009While doing a bit of research on how Cocoa developers create user interfaces, I was struck by the difficulty this developer faced in trying to create a user interface similar to that used by Apple in several of its applications:
"That's what I wanted for my new application: a source list on the left, a content list on the right, and a detail view below that. All with no margins. Unfortunately you just can't whip this up with Interface Builder."
This seems hard to believe, but the developer had to do a huge amount of work to implement the basic interface. He wound up collecting code components from several different sources--one package implemented a "split-window" view, another implemented a gradient list selector and icons in the list, another implemented custom layout in a table's cell, and so on.
The results are below:
Nice, but hardly easy or rapid--the major arguments that Cocoa developers make for their toolkit.
Here's what I use in Tk to achieve a similar interface: a BWidget Tree on the left, a Tablelist view on the right, and a text view below that, all wrapped up in ttk::panedwindow or two, and with their appearance options (such as the background, the list selector, etc.) customized to match OS X conventions.
Here are the results:
Fortunately, you can whip this up in 150 lines of code, or thereabouts. (That 150 lines doesn't include the code for the toolbar, search field, and so on, but this is an apples-to-apples comparison.)
I'd suggest that my Tk interface is very close in its appearance to the native Cocoa interface developed with Objective-C code...and I was able to develop this basic approach with far less work than the custom Cocoa interface, leveraging components that are either part of the Tcl/Tk core (text widget, paned window) or part of the standard Tcl/Tk extension library, and thus well-maintained and readily available.
I'm sure this example won't persuade any Cocoa developers to give Tk a try--heavens no!--but it does show the surprising power that Tk has, and demonstrates why I choose to develop my programs with this toolkit.
A recent favorable comment about Phynchronicity online--the commenter said that Phynchronicity "has evolved into a fine package"--was very gratifying, and also thought-provoking. The idea of "evolution" is what spurred my thinking, because this is a very accurate description of my approach to development.
When I begin developing a new program, I have a certain number of features and functionality in mind. My basic strategy is to implement the absolutely essential features and functionality in version 1.0, with an eye to getting the program out as soon as possible. Some refinement and polish of the program occurs after this point, especially in response to user feedback. However, my main goal is to implement the rest of the major features I've envisioned and move to version 2.0 in a reasonable time frame.
Once I reach version 2.0, I usually shift gears away from a big laundry list of new features, and my approach becomes much more evolutionary. Some developers use the laundry list approach as way of demarcating major versions of their software, to 2.0 and 3.0 and beyond, and also as a way of justifying upgrade charges. That's not how I prefer to do things. Once I get to a point where a program does what I want it to do, I want to continue to improve it by refining its polish and usability--not by dramatically changing the scope of what it does. This approach doesn't rule out new functionality and new features, but it does rule out a huge number of new features that may bear little resemblance to the program's original purpose.
That's how Phynchronicity has evolved. The program's core functionality--installing and removing software--has remained from the start. What has changed is how the program goes about its tasks, and the experience it presents to the user.
When I first started work on Phynchronicity, it installed and removed software, but it was slow, ugly, and unituitive. Today I started version 1.0, and almost laughed at how unpolished it was. I then looked at version 2.4, which was just released earlier this week, and the difference was night and day. This is what the comments above focused on--initial reviews of the program complained about version 1.0, while version 2.4 is what the current comment was based on.
Between version 1.0 and 2.4, here's what changed:
With the exception of one big jump--to version 2.0--all of these changes and enhancements were added bit by bit over time. The change from version 2.0 to 2.1 did not seem like a big jump, for instance--just a few little tweaks and enhancements. But the sum total of these enhancements is a program that is vastly improved, indeed one that bears only a passing resemblance to the program it was when first released.
This evolutionary approach to software development is one reason why I shy away from charging upgrade fees--it's hard for me to draw a line in the sand and say that this update is big enough to merit an upgrade fee. Over a couple of years, the changes are dramatic, but not from one released version to the next. Still, even if this means I'm passing up some revenue, I still prefer this iterative, evolutionary approach to the "laundry list of features" approach. I think it means better software over the long run.
Tue, 21 Apr 2009"In Defense of Eye Candy" is an interesting article about the value of attractive design in software. The most salient point:
"The more we learn about people, and how our brains process information, the more we learn the truth of that phrase: form and function aren't separate items. If we believe that style somehow exists independent of functionality, that we can treat aesthetics and function as two separate pieces, then we ignore the evidence that beauty is much more than decoration. Our brains can't help but agree."
In the past I've voiced some skepticism about excessive eye candy in Mac software; some Mac developers, particularly those who have been termed "the Delicious generation," tend to release programs with baroque, gaudy interfaces that tilt so far in favor of the high-gloss finish that they may sacrifice usability. If they were paintings, they would be right at home in the last Victorian era, mostly marked by decadence in its visual style.
However, if we consider eye candy as part of a larger whole--the fusion of attractiveness and usability, with balance between the two--then eye candy is definitely important. While I've tried to avoid gaudiness in my programs, I've definitely striven for both attractiveness and usability. (An example of how the aesthetics of my programs have evolved can be found here.)
In any event, "In Defense of Eye Candy" is a thought-provoking piece about the intersection of usablity and visual appeal.
Sat, 07 Mar 2009As readers of this blog know, one of my great preoccupations as a developer is the future of Tk on OS X. Tk currently is built on top of OS X's Carbon frameworks, which are more or less deprecated and will not be joining the great OS X migration to 64-bit capability. My concern has been simple: Will Tk become obsolete on the Mac if it does not run on top of Cocoa? Last year it appeared a developer was working on a port of Tk to run on top of Cocoa, which gave me great hope. But it appears that project never got off the ground.
Imagine my surprise, then, when recently running a Google search for "Tk Cocoa 64-bit" (which I idly do, from time to time), I ran across something interesting on page two of the search results:
What caught my eye was this phrase: "This is a port of TkAqua 8.5 to Cocoa and 64bit for Mac OS X Leopard..."
My.What was this? Clicking on the link brought me to the main page. What awaited me there:
" TkAqua Cocoa/64bit Port *
* *
* Copyright (c) 2008-2009 Daniel A. Steffen <das@users.sourceforge.net> *
* Copyright 2008-2009, Apple Inc. *
* *
* See the file "license.terms" for information on usage and redistribution *
* and for a DISCLAIMER OF ALL WARRANTIES. "
This could scarely be better news for anyone concerned with Tk on the Mac. Daniel A. Steffen is the maintainer of Tk on the Mac--its lead developer, the one who makes sure it is up-to-date and continually improved with new features. No one knows more about Tk on OS X than Daniel. One reason I was feeling very discouraged about Tk's future on OS X is that last year Daniel had publicly ruled out undertaking a port of Tk to run on top of Cocoa. Since he works as an independent software consultant and is not paid for his maintainer work on Tk, his decision was understandable. Somehow, however, Daniel has apparently found time to work on the Tk-Cocoa project, and it appears that Apple itself is contributing resources to the project. Daniel has been conspicuously silent about his work on this project, but Apple is (in)famous for its secrecy about unreleased projects, so perhaps that's playing a role here.
Testing Tk-Cocoa
Out of curiosity, I downloaded the Tk-Cocoa source tree from the Github site (if you don't have the git source code control tool installed, you can download a zip archive of the source tree from the site, which is what I did). I spent some time browsing through the source code, which confirms what I hoped: this is an extensive rewrite of Tk to run on top of Cocoa, instead of Carbon. I also built Tk Cocoa from source, so I could give it a test drive.To build Tk Aqua, you should change to the source code directory in Terminal, and run these commands: make -C tcl/macosx; make -C tk/macosx; make -C tcl/macosx install-embedded INSTALL_ROOT=`pwd`/embedded/; make -C tk/macosx install-embedded INSTALL_ROOT=`pwd`/embedded/. This will build and install a standalone application bundle of the Tcl/Tk frameworks, which allows you to test the system without disturbing an existing Tcl/Tk installation. (Note: These instructions yielded a 32-bit Intel binary. I also did a test build of a 4-way universal binary: 32-bit PPC and Intel, and 64-bit PPC and Intel. I did that by exporting "export CFLAGS= -arch ppc -arch i386 -arch ppc64 -arch x86_64" and running ./configure --enable-framework from the tcl/unix directory, and ./configure --enable-framework --enable-aqua from the tk/unix directory. Running the "file" command on the resulting binaries showed a four-way universal binary, including 64-bit on both Mac platforms! I did not test that build, however.)
What follows is my overview of Tk-Cocoa: how it compares to the current Tk implementation of Tk on Carbon, what effect Cocoa has on Tk as a development toolkit, and the larger impact for Tk on OS X. Tk-Cocoa appears to be somewhere between an alpha and beta stage right now: most of it works, but there are undoubtedly some bugs, and some of it is not yet implemented. The final release, whenever it comes, will likely improve on my reaction below.
Improvements
Tk-Cocoa does fix several annoying, long-standing warts in the implementation of Tk on Carbon. Images in menus is one of them. If you look at the two screenshots below, you'll see that the image in the Tk-Cocoa menu has some padding around it, while the image in the Tk-Carbon menu is smashed against the side of the menu. The Cocoa layout is the correct one. I'm not sure if this is a case of the Cocoa implementation "just working," but it certainly does work.
 |
 |
| Tk-Cocoa menu. | Tk-Carbon menu. |
One extremely cool feature, which I discovered while rummaging around in the source code, is that Tk can now display Mac-native images. Tk had this ability on Mac Classic, but this feature has been broken every since Tcl/Tk was ported to Mac OS X in 2001. The screenshot below uses the "NSUser" system image. This feature, by itself, will make a huge difference in the polish of Tk applications on Mac OS X if it is intelligently used. (I will certainly be trying it out in my apps!)
 |
|
| Native Cocoa bitmaps. |
Some things, while not necessarily better, are different. The Cocoa dialog below looks very different from the Carbon. One item of note is that the Cocoa dialog does not display as a "sheet," that is, a window that slides down from the top of the main window. I hope this is functionality that will be added later, as I use this feature in all of my applications.
 |
 |
| Tk-Cocoa dialog. | Tk-Carbon dialog. |
Tk-Cocoa also picks up the correct behavior of the "help" menu, and in fact displays something that annoys me about Cocoa programs: if the application lacks installed user help, by default it pops up a window that says, "Help is not available for this application." (Programmers should always provide user help, in my view, but that's a digression.)
The Status Quo
While there are some definite improvements and nice touches in Tk-Cocoa, what is especially interesting to me is how much is unchanged, at least on the surface. The two screenshots below are basically indistinguishable; both display old-fashioned Mac notebook tabs. (I'm not sure why Tk's themed "ttk" widgets use this Jaguar-era tab control, but that's been unchanged for five years now.)
 |
 |
| Tk-Cocoa notebook. | Tk-Carbon notebook. |
Indeed, running the Tk widget demo with Tk-Cocoa, it's amazing how little seems to have changed. Most everything looks identical as before. Apart from the improvements noted above, there is almost nothing different between Tk-Cocoa and Tk-Carbon. The significance of this is clear: the goal is to preserve the user-level implementation of Tk as much as possible, even while there is a massive under-the-hood rewrite going on. It's a conservative approach, one that will not break existing packages that depend on this framework. It's a laudable goal, and one I've highlighted before in the work of other developers porting a toolkit to run on top of Cocoa.
Rough Edges
Of course, since the Tk-Cocoa port still appears to be a work in progress, not everything is done yet. The "to-do" list at the Github site mentions that native dialogs are not fully in place yet. Testing the widget demo, I can confirm this, as the screenshots below demonstrate.
 |
 |
| Tk-Cocoa color dialog. | Tk-Carbon color dialog. |
The Tk-Cocoa screenshot is actually Tk's cross-platform color picker dialog, which is what Tk uses on Unix and serves as the fallback dialog on other platforms. The Tk-Carbon dialog uses the native system dialog; I assume this will be implemented at some point in Tk-Cocoa.
Conclusion: The Significance of Tk-Cocoa
Tk-Cocoa is a real milestone in the evolution of Tk on OS X. With better menu displays, native bitmaps, and other improvements, it offers a much higher degree of platform-specific Mac integration than it has in the past, while still preserving the API that makes Tk widely-used as a cross-platform toolkit. Cocoa purists may not be impressed, but I am definitely looking forward to using Tk-Cocoa in my applications; it will make the work I do to ensure a polished, high-quality Mac user experience with my programs much easier. I feel that Tk has always been a hidden gem, so to speak, and perhaps more developers on the Mac would be willing to give it a try now that it's moving to Cocoa.
Fundamentally, Tk-Cocoa ensures Tk's viability as a development toolkit on OS X for years to come. Apple has been moving slowly away from Carbon for years, and finally forced the break with Carbon by not making it a 64-bit development framework. That's how Apple has ensured a convergence of all Mac developers around Cocoa. Now, Tk is no longer left behind. It joins Qt, RealBasic, and wxWidgets as a major cross-platform toolkit with Cocoa as its foundation. And it's not just Tcl/Tk applications that benefit; major applications written in Python, Ruby, Perl, and other languages will also benefit, because they have Tk bindings.
All in all, it's a good time to be a Tk developer on the Mac. Daniel is doing a tremendous job, apparently almost single-handedly, in moving the Tk toolkit to Cocoa. And Apple, which sponsored the port of Tk to OS X back in 2001, is apparently contributing again to this important effort. I can't wait to see the final release!
Sat, 31 Jan 2009I've released two open-source Tcl/Tk packages that add some needed functionality to Tk in a cross-platform fashion.
The first package, TkWebView, provides a lightweight HTML viewer that can either be used as a standalone window or embedded in another widget. Tk is conspicuous among cross-platform GUI toolkits in lacking an easy-to-use HTML widget. TkWebView only supports basic HTML, not tables, CSS or other components of web browsers, but it still fills a void in Tcl/Tk. (An ambitious project to provide a modern HTML widget for Tk, TkHTML 3, appears to have stalled--and even when development was moving forward, it suffered from an extremely high level of complexity that made it nearly impossible to use in an application.) TkWebView could be used as a help viewer, a widget to display HTML from RSS feeds, and more.
The second package, SimpleDND, provides a lightweight mechanism for drag-and-drop within a Tk application. There are various methods to display drag-and-drop in Tk applications, but they are either limited (quick hacks specific to a particular application or widget), complex (such as BWidgets' drag-and-drop mechanism), or not fully cross-platform (TkDND is the most powerful DND extension out there, supporting drag-and-drop between different applications, but is not supported on the Mac). SimpleDND provides basic drag-and-drop visualization with a few commands, and such fills a void.
Both packages are available at http://www.codebykevin.com/opensource/xplat_oss.html. I hope some people find them useful.