This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Comment about Tk
Feed Title: Pollock
Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml
Feed Description: Pollock - the next VW GUI
Yes indeed, Tk is a very interesting GUI framework that must be included in the list of frameworks. More important than that is its fairly unusual design.
Tk is a hybrid between a true emulation framework and a native widget framework. And in doing that, it is a VERY important framework. Let's look into some of the details.
Genesis, Wrapper, Pollock, Swing, Morphic, Microsoft GUI, Apple GUI and Xlib are low level do everything frameworks. This is, they do all of the drawing of the widgets, management of their state as well as manage, trigger and act on events that occur in and around a widget. For instance, if you want a scrollbar in some widget or window that you would expect to have a scrollbar, it has to instantiate it, draw it, and communicate between the widget and it's model and the display of the widget and the scrollbar.
Wrapper, Pollock and Swing stand out in these as they don't actually create the windows in which these widgets reside. Instead, these use the host (Microsoft, Apple or XLib) to create the windows.
Tk is an important hybrid because, to the best of my research, it was the first to do what it did. And what it did is a trick called Owner Draw widgets. For some widgets, for instance, the Button, CheckBox, RadioButton and Menus it creates widgets of the appropriate type from the underlying operating system, and then, does all of the drawing itself. It then has a mechanism for allowing the events from these native widgets to notify Tk when to draw it and when to react to some user input event.
Almost all of the rest of the widgets in Tk are completely drawn and managed by Tk itself. Where it gets interesting is for widgets that need scrollbars. For widgets that have scrollbars, it does something VERY interesting. Basically, it always creates an underlying operating system native scrollbar of the right type, then creates a bit of glue that allows this native scrollbar to talk to the emulated widget it is managing. Thus, Tk doesn't ever have to draw what a scrollbar looks like, but rather just has to respond when the underlying native scrollbar sends events about it being dragged or clicked on.
What this means is that Tk has many of the same problems that Wrapper, Pollock and Swing does (and to an extent, Morphic). If a hosting OS changes what it's widgets look like (such as from MacOSX 10.0, to Jaguar and soon, Cougar, or Windows 3.x to 95 to XP), then Tk has to catch up. This is the problem for ANY emulated framework, and is not unique to Tk, Wrapper, Pollock or Swing.
This is also why today, as the looks and feels of underlying OS's start to change, and the failure of the "Browser As The Desktop" is being realized, native widget frameworks are becoming more important. How does one deal with that? Well, in the Java world, the SWT framework goes back to native widgets in a portable way, but, it leaves all of the Swing developers pretty much in the lurch.
So, what about Pollock and Native widgets? Well, as stated before, Pollock has a follow on project called Chagall. Chagall will allow Pollock to display and manage native widgets. However, it will NOT be all or nothing. In fact, it will allow Pollock widgets and native widgets to reside on the same window. Furthermore, if we do it right, it won't require much re-coding on the behalf of existing Pollock users. What do I mean by "much?" Well, when Chagall comes along, developers should only have to go into their UserInterface objects, and turn on a "Use Native Widgets" option. If the developer wants to go widget by widget, they'll be able to load their UserInterfaces into the Painter, and on a widget by widget basis, turn on "Be Native Widget" as they see fit, or of course, using an API.
So, where does this leave Tk? Well, from what I've seen of the code, they COULD do for Tk what Chagall will do for Pollock.
What about Swing? I'm afraid that Swing is floating around, waiting for the god of dead end frameworks to finally decide to flush.
Previous Topic
