Site Home > Tk Revitalization > Look and Feel
Key Pages
ProjectsThe general concensus is that the existing Motif style needs updating, and there are two schools of thought as to what to replace it with:
If we had to choose between the two many would opt for the latter. Ideally we'll provide both. And, of course, on Windows platforms they will be the same thing.
This duality allows, for example, a Tk application to appear like a native application on a number of platforms (which is important to many people). But providing a default Windows-like L&F addresses the commercial emperitive of many organisations.
But what exactly does this mean "Windows look and feel" mean?
As noted at the Tcl2003 conference, Microsoft themselves aren't consistent in the use of UI elements between applications and Windows versions. To paraphrase US Supreme Court Justice Potter Stewart who wrote (in 1964) "I shall not today attempt to further define pornography...but I know it when I see it." ... we can't attempt to define "Windows look and feel", but we'll know it when we see it. And we know that Tk currently doesn't have it.
Accordingly, the "Tk revitalization" should focus making Tk apps work and play consistently with common applications like Internet Explorer, Windows Explorer, and all the usual desktop applications. The Display Properties, help system and other areas all contain examples of the things that we want to build and model on. The Microsoft User Experience documents this stuff in gory detail.
Tk needn't implement all of the Windows look and feel, but the user should not be aware that they are using non-native scripting application, any more than a user is a aware of the differences (and there are a number of them) between Excel and Word.
Also providing the native look and feel is perhaps less urgent, but nevertheless important if Tk is to be accepted on platforms like MacOSX and Linux. And on Linux/Unix there is the problem of many window managers to choose from. This may be as simple as alternative default font/color/options for MacOSX/KDE/Gnome. Or as complicated as theme support.
First steps first though - whilst not precluding theme support let's get the basic stuff in place before attempting such a significant change.
One issue which arises when providing native support, is that native widgets don't necessarily implement all the features that the equivalent Tk widget does. Some examples
Since Tk is to a large extent a cross-platform abstraction of a window library, the "Tk revitalization" will need to take into consideration these issues. Perhaps by using the native widget functionality, but with the option of using a Tcl/Tk version should the missing functionality be required - much like the File Open/Save dialogs currently do on Windows.
Issues related to Themes moved to its own page.
Another thing to consider is the size of some of these other windowing packages. Tk is microscopic by comparison. (BTW, relying on the windowing library being installed on the system already isn't an option.)
Posted at Dec 10/2003 08:15 AM:
Will Duquette: This just argues that we need to be able to create and swap in new styles easily. Tk needs to become a chameleon.
Posted at Dec 10/2003 09:23 AM:
David S. Cargo: This is also true when you can use Windows XP and choose to use the "classic" look and feel. That adds yet another variation on how things might look. (I have no idea how a Tk program might determine that it's running on XP with a classic look selected.)
Posted at Dec 15/2003 05:57 AM:
DKF: Bet there's a registry key you can look at. If we're very lucky, it'll even be documented and human-readable...