Submitted by Tcl/Tk 8.5.0 has been released. “The 8.5 release was a long time in development, and brought about several good enhancements to Tcl/Tk. Source releases, the exact changes and ChangeLog for each release are available in the SourceForge Tcl project’s file distribution area.”
Wow, did not realize this was still around. Are there many projects using Tcl/Tk still? I remember when some of the old GUI interfaces were developed with this but not sure how the performance has been improved over say Python and Ruby. I did not realize they used Bytecode now.
yes there are many many projects still using this. It is actualy a rather nice tool kit and i really like what they have done with 8.5
Actually Tcl/Tk is industry standard in scripting engineering applications such as ModelSim, Synopsys DesignCompiler, Xilinx ICE, etc.
I am quite sure it will be around for a while…
Good release.
One of the apps I use and which utilizes Tcl/Tk is aMSN
I remember having read somewhere that 8.5 is supposed to support anti-aliased font rendering which sure is a welcome addition! aMSN is a nice app but one thing that drove me almost nuts was the hideous font rendering.. :/
expect uses tcl.
dejagnu uses expect.
autotools use dejagnu.
most opensource projects use autotools.
tcl is used in most of opensource software.
tcl is the big embeded tool language both in open source and closed source. Python is not nearly widely used as tcl! And it’s mostly a replacement for perl, rarely for tcl.
Now tk is quite ugly indeed.
Edited 2007-12-21 14:11
sK1 is one of recent ones
http://sk1project.org/modules.php?name=Products&product=sk1
Yes, Tcl/Tk is used by several cool applications. aMSN was already noted, and Coccinella is maybe even sexier. Note that the latter will get support for this new Tcl/Tk 8.5 in next major release; which will be already in March of 2008. Source:
http://coccinella.im/coccinella-0.96.4
Tcl has been using bytecodes since around 1997
There are a lot of nice things in this release. It now has a core OO framework that can be used as a minimal OO system but is really designed for other more robust frameworks to build on. Native themeing in Tk. There is now a dictionary data structure.
There is also the start of the much clamored for CPAN for Tcl called Teapot (or something like that).
Highlights of Tcl 8.5
Speed: 8.5 now runs 10% faster than 8.4 with bytecode improvements, object caching and reduced memory usage.
Bignums: Tcl now supports arbitrary-precision integers, which improves math operations on large integers.
Safer interps: Tcl’s powerful safe interpreter mechanism now has improved control of time and command limits in slave interpreters.
clock command: More robust implementation of command for specifying time, with significant l10n and i18n improvements.
dict command: New data structure that allows access to data by value rather than a variable name, which is substantially faster.
Additional improvements: Faster list search, new and improved mathematics procedures, anonymous procedures, new ways to package Tcl extensions, Tcl-level custom channel types, file and line location information for each command, and more.
Highlights of Tk 8.5
New modern theming engine: New and complementary widgets that make use of platform-specific theming on Mac OS X and Windows to better fit in with those environments, and feature an improved look and feel under X11.
New widgets: Part of the themed widget set, Tk now has core notebook, combobox, treeview and progressbar widgets.
text widget: Smooth scrolling, widget peering, and improved procedures for counting and replacing text.
Font rendering: Now uses anti-aliased text under X11, and a more modern text engine (ATSUI) on Mac OS X.
Additional improvements: Window transparency, new fullscreen option for windows, enhancements to specific widgets and window layout, and more.
Resource:
http://wiki.tcl.tk/
Wow! The OS X port look nicer than the wxwidget one. ( I use mostly wxpython)
And wx render annoyingly slow on OS X (Tiger and Leopard) compare to Linux or Windows, I wonder how Tk compared on this matter.
8.5 pre-releases have been used in Mandriva since release 2008.
Yes, this means our amsn package has lovely AA text.
I just picked up the new PyQt book. Tcl/Tk 8.5 is great for legacy apps that started with that tookit, but for new development in that market PyQt is kicking butt. Sometimes you just gotta let go of the old stuff.
This isn’t a plug your own widget set. It is about the release of Tcl/Tk. PyQt…meh. If I was doing Python, I would go with wxPython over PyQt.
The question begged is: why don’t they have a nice abstract GUI PEP that all of the adapter module writers can target?
I’d like to distribut a python egg that can just use whatever is installed. Make GUI writing as close to dumb-simple as HTML, for the 80% solution.
I believe that is what every GUI toolkit is trying to achieve. Everytime you add an abstract supposed to be used by everyone, you actually add a new API and new complexity that will only be used by a few and ignored by the rest. Each GUI toolkit is already an abstraction. No need to add a layer there. Just need to convince everybody to use the same stuff.
There’s more to these toolkits than panels and widgets, else I’m sure we’d be doing as you suggest. Have a look at either GTK or QT’s capabilities sometime. You’ve got thread managing, SQL interfaces, data structure libraries, and other things that get quite specific. While I’m sure a simple interface definition could be in common for all of these things, it would be unable to take advantage of the best features.
Tcl/Tk is still a very good choice for GUI coding in combination with shell scripts. You can even implement more complex applications based on Tcl/Tk scripts without compiling anything.
For example, the tkbrief application is an easy interface for the LaTeX dinbrief document class. (“Brief” is german for “letter”).
http://www.linuxnetmag.com/en/issue2/m2tkbrief1.html
When I have to create a simple GUI wrapper for some automated process, I usually stick with Tcl/Tk, because it’s fast and simple. It’s very easy to code when you are familiar with C and sh. On the complexity side, it does not require huge dependencies, so it’s great on systems with low ressources or that do not run one of the two major DEs on UNIX / Linux. Furthermore, it includes a good documentation you can access via the man command which is an advantage for developers.
For example, I did create a script that makes a booklet out of given image files, so you can simply take it out of the printer, fold it in the middle and have a booklet. The interface to this script contains a simple file selector, some buttons for configuration (e. g. last page aligning convention) and a simple preview / printing facility, along with an interface to the pdflatex tex – pdf processor. I didn’t mind to create a Gtk or Qt based “full application” around this simple script, because I use it in CLI mode most times, but along with the Tcl/Tk wrapper I can share it with other users. I have other scripts for maintaining digital camera outputs, too. None of these tasks is “worth” implementing a “real program”.
I would be sad if Tcl/Tk disappeared from the UNIX world.
One thing I never liked about TCL and TK’s source code is that you actually have to leave it unpacked all the time! Yep, for example (unless you heavily hack the source code), to build TK in its 8.4.X incarnation, you have to have the equivalent TCL 8.4.X *source code* unpacked!
This is very poor indeed – you should have just been able to “make install” TCL, delete the source code and then used the installed TCL files to build TK – which is how every other source package in the universe does it. It gets worse with third-party source code that uses TCL/TK – that often assumes unpacked TCL/TK source trees too – arrgh! If there’s one thing I hope 8.5 has fixed, it’s this “craziness” w.r.t. source code building…
Do you mean the code or the headers? If you mean the former then that would be odd, if you mean the latter then that is how ‘every other source package’ does things.
You can compile EVERYTHING in to a single file called a starkit. Starkits have been around since 8.4.
Glad TCL/TK 8.5 finally released. It’s been in development for 5 long years…
I wish the TK project would split from TCL side.
I have wished that as well. Maybe it is time for a wxTcl to mimic wxPython?
You obviously haven’t looked at tcl since, say, 2002 or so. Tcl is way ahead of the pack in this regard. It’s possible to pack the tcl executable, the runtime, your tcl code, even other executable programs and dll/so’s into a single executable. No install necessary.
The technology is is called a starpack, which consists of a platform dependent runtime (tclkit) and platform-independent code (starkit)
> You obviously haven’t looked at tcl since, say, 2002 or so.
I did mention 8.4.X in my post and I have indeed built tcl/tk 8.4.16 (the last one before the 8.5 series). If you do a straightforward “configure”, “make” and “make install” (which is exactly what unix/README tells you to do), you run into the very problem I described.
Basically, tcl and tk don’t seem to do a full “make install” of all the files required (particularly include files) to build other packages from the installed files. The starpack format you mention isn’t documented in the compilation/installation instructions either – my only guess is that it’s yet another third-party package you have to go off and build/install.
Mind you, a third-party build system doesn’t surprise me because tcl and tk’s build/install system is woefully inadequate!
The starpack is a method for creating single file executables for different operating systems (for instance I have a tcl starpack executable that I email as one file to the sysadmin who runs it on his windows box (although I do all the testing and creating on my linux box). He doesn’t have tcl installed on his machine, just this one executable I send.
You may not like Tcl but you don’t seem to really know enough about using it to comment (for this same reason I’ll not comment on perl/ruby/python/flavour-of-the-month).
I am a relatively new programmer, and having written 3 small apps for work for use at the console, I have decided to try to pop on a GUI front end to my smallest program.
Of all the options, Tk is the most viable option; QT tutorials tell me I have to know C++; Tk tutorials do not. Of the others, Tk has the best documentation for use with Ruby. Tk is also included with the Ruby package. Ruby is free and still cross platform, should I try to market sell my apps.
I would have liked Qt, but the barriers to entry were too steep. Tk is nice for us beginners using FOSS.
Just my .02
I love to play around with languages as a hobby, and Tcl is no exception there. Periodically I go an a Tcl/Tk binge, and they always seem to last longer than the other binges. I like Perl/Tk and Tkinter as well.
The only problem I have with Tk is its printer support. I wish it had better (or maybe there’s some secret about printing under Tk that I haven’t found yet, other than the Canvas/Postscript thingy.) I alwsys kinda liked how Visual Basic could see the printer page as an object and then just print it.
Other thing I love about this is that you can show anybody how to put widgets on their screen and play with them, interactively. Really cool!
I agree – this toolset will be around a lot longer than I will, I think.
I know it’s not the most powerful language but on ratio difficulty to learn language versus potential of it, still one of the best. I write most of my scripts in tcl.