Tcl/Tk 8.5.0 Released
dkf writes "Tcl/Tk 8.5 has been released for all major platforms after 5 years of development. There are many new goodies in it, including significant speedups through an advanced bytecode engine, stronger localization of applications, integrated arbitrary-precision arithmetic, a whole bunch of brand new skinnable widgets, anti-aliased text support on all platforms, and a new code-module management system to make maintenance of installations a snap. More in-depth information about the features of both this release and Tcl/Tk in general is available at the official Tcl/Tk website. Mark Roseman's blog has a first-look review."
I'm tickled pink!
Tkinter is the de-facto python windowing kit. This in itself is enough for a new python release. Faster==better, and python always wants to be a bit faster. Tcl/Tk by itself is kind of clunky IMO, but python Tkinter makes good use of it. Thanks Tck/Tk guys!
Clickety Click
Tk has been so in need of a makeover for many years. The widgets in their default state have looked like crusty relics on our grandparents' computers, and even make Windows 3.1 look contemporary. Well done guys. I can't wait to check it out.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
From what I've seen, the internals of the Tcl environment (the interpreter, libraries and so on) are pretty solid and nicely done. Unfortunately the Tcl language itself is peculiar, dated and just not very good. I wish the Tcl people would consider a thorough backward-incompatible revamp of the language into something a bit less off-putting.
Tkinter is the de-facto python windowing kit.
I think Gtk is becoming more and more the "de-facto python windowing kit", in particular as Gtk's cross platform support is improving.
I am only interested in one thing:
Will the Tk widgets now integrate with the rest of the desktop, in terms of using the same theme settings that other programs use?
I like how Tk has been used as a GUI toolkit by many programming lanugages, and I think that says something good about its design and implementation, but the ugly, unthemeable, and out-of-place looking widgets have always been a thorn in my eye.
Especially because it _did_ work sort of right on proprietary OSes as far as I know.
Please correct me if I got my facts wrong.
the Tklet browser plugins again, so that I can write in-browser applications in a sensible programming language. Why Java won that market I can't possibly fathom.
I am trolling
Wow, didn't know that people used it. Now I know what gramps was talking about when he mentioned "programming tickles!"
// file: mice.h
#include "frickin_lasers.h"
Yahbut tcl/tk is used to run machines, factories. The hint is in the name.
Whether the widgets look like Windows, Linux, OSX, Motif or whatever is largely irrelevant as long as the start and stop buttons work when you click them.
Deleted
"Really? For what purpose?"
Bragging.
Anyway, I better get back to writing my Micro Controller Design handbook in Gaelic - I'm sure this one will be a seller, hardly anybody is writing Gaelic computing text books!
M0571y H@rml355.
I think Tkinter still has a lot of advantages at this point over GTK. It has plenty of life left in it. At least until someone writes an equally high-level Python interface to a different graphical toolkit and gets it into the standard library.
If you have a Python application and want to throw a quick GUI onto it, Tkinter is a lot easier. It is also very easy to deploy since it is in the Python standard library. You can write a custom app on your Linux workstation and then the next day put it on a customer's Windows desktop.
Relative to most Python libraries, PyGTK is rather low level, the Python bindings to TK are a lot more Pythonic. For 80% of people, TK is far more useful for adding a quick and dirty GUI onto an application.
Even for someone such as me who uses GNOME-based systems and couldn't care less about how ugly it looks on Windows, GTK is far more powerful and better looking than Tkinter, yes. However, you can't just dip in with Python knowledge and get going, you have to learn rather a lot of low level details about how GTK works. You are far more programming to an implementation rather than to an interface.
So another approach is the WX toolkit. However, I have been looking at a library called Kiwi (
http://www.async.com.br/projects/kiwi/ ) which attempts to provide a more abstracted Python interface to PyGTK. It is still in some ways lower level than Tkinter though.
So I don't see Python changing its default graphical toolkit from TK anytime soon.
P.S. Slashdot does not allow TK >= GTK as the title, perhaps they should re-write the site in Python?
My little Linux and tech blog
The policy is that major version is bumped only when significant backward incompatibility is expected. New features don't do it unless they break old code.
Apparently, some developer are playing with the QT/KDE and GTK theme engine hooks :
Here's a link to tileqt that I found on tcl's page. This theme uses the QT-theme-egine to make TCL/TK applications look like the rest of the KDE desktop. (It works like the gtk2's qt-engine).
Probably there's also someone working on using GTK2's theme engine so Gnome people can have their applications look like their desktop too. But I'm a KDE user and too lazy to search for that information.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
TCL is still used in some surprising places. A good example is networking equipment, such as Cisco devices, F5 load balancers, and so on. Many of these have TCL capabilities for one reason or another. A good example for the Cisco case would be their load balancing devices. You can create custom monitoring scripts in TCL and import them into the device.
My UID is the product of 2 primes.
Apparently Tcl is pronounced 'Tickle'. I learned the hard way after someone had pointed out that I named a file test.tcl.
It is necessary, as you can't embed Perl into anything but a full PC. Thats why I now loath Perl and love Tcl. Power in smaller size.
You might have a look at Ruby sometime. It has pretty good language design (inspired by Lisp and Smalltalk), many practicalities copied from Perl, it has plenty of libraries available for it (though not nearly as many as Perl), which are easy to manage with Ruby Gems, and it's easy to interface to C code.
I find that Ruby is the language that nobody wants to look at, because it's just like the language they're currently happy with (usually Python, often also Perl). It was the same for me for many years (and, at the time, English documentation was somewhat lacking). But when I did check out Ruby, I quickly fell in love with it. I'm a programming language freak, so chances are that whatever language you use now is one I've used as well. It would go too far to say that Ruby beats them all...but on many tasks, it does.
Please correct me if I got my facts wrong.
I will be moderated down for this? Who cares, I have to say it. Why the heck do Tk always looks like total crap on linux? It is the most hideous widgets I have ever seen, the graphic designer should be covered in tar and feathers, and he would still look better than the widgets.
For the rest tcl/tk is still one of the easier ways to develop some cross-platform mini-apps, useful when you don't want to loose time in programming graphic interfaces but you have to for marketing reasons.
this post contain no useful information, no need to mod it down
I'm in complete disagreement. In the last 10 years Tcl has evolved greatly. It's not just for simple cross-platform embedded scripts, but also for complex cross-platform embedded apps.
Not so.
Tcl's strongest redeeming features are its consistency and its sensibility. Tcl very strongly has a principle of least surprise, thanks to these. That alone makes programming in Tcl a joy compared with many, many other things. You'll spend a lot less time wondering how your code will work on a foreign platform, which flags a given widget expects, and so on.
Tcl of 2007 is also not Ousterhout's Tcl of 1987. A lot has happened in the last 20 years, including totally pervasive unicode support (the [msgcat] library makes internationalization such a breeze, there's absolutely no reason not to make all your programs localizable from the start), some very healthy namespace functionality, an excellent networking library, and of course the relatively recent Tile toolkit.
There are also new projects being developed with Tcl all the time.
Far from being an outdated or dying language, Tcl today is just a well-kept secret, sitting out in plain sight.
I think there may be one other speech analysis package that did spectrograms and used TCL/TK at one point, but I don't think it has an active distribution the way WaveSurfer does.
What the WaveSurfer people did is that about half their code base is C-language for implementing speech-specific TK widgets, such as a spectrogram Canvas elaboration of the TK Canvas widget. Their C-language routines call down to low-level X to draw things, and if you build on Windows you need some implementation of X. The WaveSurfer Windows distribution, however, is a single .exe file that has WaveSurfer and whatever support libraries all rolled in, so there is a very simply install.
Their TCL part, however, is a big ball of goo, or at least to someone who doesn't know TCL. Instead of pushing a lot of the functionality into the speech toolkit widgits, they implement a lot of stuff in the TCL layer -- it is not simply a thin scripting layer over a largely C code base. You find that out when you try to customize your own speech app using their speech widgets -- there is tons of functionality that you need to reproduce in your own app as the widgets are pretty bare bones. Not that there is anything wrong with it, but using the WaveSurfer app and hearing about rolling-your-own speech app with their toolkit, you kind of get the wrong impression about how much is in the widgets. I found this out when playing with Python scripting to display their widgets.
The one thing that appeals to me about TK is the Canvas widget, which was apparently inspired by someone's Scheme graphics or some such thing. No worrying about paint messages and invalid regions -- you just give the Canvas a scene graph of line, text, even 3-color bitmap or even overlaying buttons, and the Canvas takes care of all of that. I would like to see such a high-function widget in other environements.
I was never bothered by the non-Windows look to WaveSurfer (OK, the lame Files Open dialog of GTK under Windows bothers me, but not most stuff as Windows is not that uniform a GUI experience to begin with).
Most of the negative comments about Tcl/Tk focus on the past versions, missing the point of this new 8.5.0 release! Try it before you bash it.
Whenever you have one of these overlapping-window GUI front-ends to an OS, developing apps for it is a hard slog, whether it is Windows, GTK, Motif, raw X, whatever. Just like MS came out with their application programmer-friendly Visual Basic as the go-to way of slapping a GUI together, Sun was at one time promoting TCL/TK as the way of slapping a GUI front end on your C program.
In commercial apps, your users worry if your widgets are pretty and Mac people are in a huff about ported software or Java not conforming to UI standard, but for internal apps that just have to get a job done, you often don't care. The projected associated with a high-voltage custom x-ray machine had been a Sun shop since the days Sun 2's came out, and the current app running the x-ray machine is TCL/TK running on a SPARC.
That app makes good use of the Canvas widget to display gray-scale x-ray images and allow you to drag cursors and place measurement markers over those images; apart from that the app is a bunch of buttons to start and stop image collection and motion tracking modes of the x-ray system. I wouldn't have taken note that it was TCL/TK it it were not pointed out, but now that I know, I can see the characteristic widget styles and layouts along with the Canvas that does the x-ray images.
Given that this was all implemented prior to the release of Java, TCL/TK is what you had, and TCL/TK is what you did unless you wanted to take much more time doing the GUI, and our app has aged well (although try hiring someone to change the TCL code), so yes, it is a good question why Sun in effect abandoned that and jumped on the Java bandwagon of their making.
I'm happy about this new release because I do use one or two programs that use Tcl/Tk and I'd be very happy to see them ... well.. look nicer. Coincidentally, for this very reason I was looking at Tile the other day, which is the skinning engine available for Tcl/Tk. I compiled and installed it.. and.. nothing changed.
So, it seems that Tcl/Tk applications have to explicitly use Tile in order to get the skinning, is this correct? In other words, if I install 8.5, it won't change anything (visually) for the applications I'm already using, until they update themselves properly for 8.5, is that right?
Or is there some flag I can set in some configuration file that will enable the skinning engine?
Just some side information. I read Coccinella will already switch to Tcl/Tk 8.5 in a few months (12 March). See comment at the end of the announcement of the latest release: http://coccinella.im/coccinella-0.96.4 Oh yes, and Coccinella is already using an older version of Tile for Tcl/Tk 8.4. This is some sexy theme proof that Tcl/Tk shouldn't be ugly: http://coccinella.im/stuff/sexy.png
Does anyone know if this will end up making the widgets in perl/tk apps look better/more modern at some point?
Find free books.
nah. His work was tarred and Gunzipped instead of feathered
I'm starting to think GNU is the problem with "GNU/Linux" these days.
``I get the same reaction when I bang on people's door and try to tell them the good news about Jesus Christ. I wonder if it might possibly be related to my behaviour, rather than the relative merits of my beliefs and theirs?''
Thanks for pointing out that I have gone a bit further over the edge than I wanted to. My post was meant to be a friendly suggestion to try Ruby, because I think the person I replied to might like it, based on what he wrote.
``Seriously, the #1 problem with Ruby right now is the way Ruby advocacy has literally turned into a kind of religious evangelism. Ruby fans claim that their new favourite programming language will change your life. Even you talk of "falling in love" -- more extreme cases talk of having their eyes suddenly opened to huge new worlds of possibility.''
Frankly, depending on what languages you already know, I think this might not be over the top at all.
``I understand this because I've been there and done it (evangelised the One True Language, that is; it wasn't Ruby for me, but I felt the same way about it). You get over it with time, and come to recognise that no language is so good that it matters whether other people use it too or not, and start choosing your languages more pragmatically instead of believing that code blocks are so cool that they make Ruby absolutely the ideal language to write this microcontroller in.''
Oh, I'm all for the right tool for the job. And Ruby definitely isn't fit for all jobs. In fact, I do think I mentioned that in my original post.
The sentiment I get from that last paragraph of yours, though, is the suggestion that all the features that I (or someone else) like in Ruby don't matter too much. Some sort of "who cares if you have code blocks, just shut up and get the job done". And that's something I vehemently disagree with. What makes programming languages great is not the amount of things that are built in, the amount of library code shipped with them, or even the amount of library code available for them. What makes programming languages great is the productivity you get when developing _new_ things. I find that, here, it matters a lot how well you can abstract from things. Basically, you adapt the programming language to the problem you're solving. In Ruby, this is very easy. In many languages, it isn't. This makes all the difference in the world. Oh, and of course, Ruby isn't the only language like this. But if I start about Lisp, people fall over me, too.
Please correct me if I got my facts wrong.
I like Tcl (and Tk). It has a nice syntax. It has good libraries. It runs pretty much the same on any OS I care to use. One of the big benefits as well is the community. It is super helpful and very nice to work with.
Why the heck do Tk always looks like total crap on linux?
Because it was based on the state of the art in 1992 or so.
Who cares?
Because the new widget set is themable and doesn't have to look like total crap.
It's not the way I would have solved the problem, personally, but it does solve it.
Saying PyGtk is less clunky that GObject in C is like saying Stephen Hawking is slightly more intellectually inclined than George W. Bush
P.S. I don't like GObject in C.
no text
--
Promoting critical thinking since 1994.
Yes, okay Plain Text formatting.
My little Linux and tech blog
This post has been created as "HTML Formatted" for your angle-bracket viewing pleasure (and note the post subject). If you learn about HTML entities, you'll have no trouble displaying your >s and <s.
--
Promoting critical thinking since 1994.