TkGS (the Tk Graphics System) is a cross-platform graphics system for the Tk Toolkit that is intended to replace the current XLib emulation layer implemented in the Win32 and MacOS versions of Tk.
TkGS is intended to be a low-level cross-platform API to leverage GUI differences, the same way the Tcl API leverages OS differences. It is not intended to be a high-level drawing system. TkGS is written using the C programming language.
TkGS isn't a replacement for Tk. TkGS only takes care of the low-level drawing stuff, whereas Tk manages higher level concepts such as windows, events, bindings... However, the first goal of TkGS is to replace all graphics calls of Tk's current implementation.
The name "TkGS" has been chosen among other candidates for one main reason: "TkGS" does not seems to be used by other projects. Other candidates were (in no special order):
The TkGS home page is located here:
The given URL is actually a persistent URL (PURL) to ensure that the site remains reachable even if the hosting site changes. A PURL will redirect your browser to the currently valid URL. You can safely bookmark PURLs. For more information on PURLs, see http://www.purl.org/
There is a draft implementation here:
This implementation should be considered very alpha software. Its primary intent is to be a proof-of-concept and a testbed for TkGS implementors. Thus, it can still contain old Tk and Xlib calls.
TkGS tries to be as generic as possible, only leaving as less work as possible to do by device drivers. This makes device driver writing very easy. For example, the "Canvas script" and PostScript drivers included in the draft implementation were implemented in a couple of hours each. I believe a programmer with good knowledge of TkGS device architecture and of its favorite graphics system could write a driver very quickly. However, this is only part of the story when it comes to porting Tk to a new platform. For example, the current BeOS port needs a X server on the BeOS machine to work. Writing a TkGS driver for BeOS will solve the graphics part of the porting job but not the whole windowing stuff (see FAQ "What TkGS is NOT").
No. TkGS only lives at C level, maintaining compatibility at scripting level.
C applications written using old Tk calls will need to be rewritten. However TkGS will be designed so that porting can be done easily and quickly.
No, however it provides a device-independent graphics model that makes printing extension easier to develop. Applications written with TkGS would transparently use any printing capabilities when available. For example, on Unix, a printer extension would use the PostScript driver for drawing, and on Windows and MacOS, the native printing facilities. The extension writer's job won't be to supply device-independent graphics operations anymore, but to provide standard, platform-independent methods for accessing printers (eg. standard dialogs), leaving to TkGS the whole drawing job.
Contribute! ;-)
TkGS is an Open Source projects. Everybody's free to work on it: work on the specs, submit ideas, write code...
Currently the only TkGS core developer and specification writer is me, Frédéric BONNET. I'm very busy with my work and other projects, and would like to have more time to work on TkGS because it is something very important to me. But you know, there are only 24 hours a day...
If you're interested in working on TkGS, send be a mail. You can also subscribe to the mailing list.