Tk will always be around. Even in it's current limited state, it is a valuable tool, and the Tk::Canvas is still very useful (it's only drawback IMO, is the lack of transparency support....but Tk::Zinc picks up that slack. Tk ( not the Perl port) is moving ahead full speed, and the newest version has all sorts of improvements. The question is whether someone with c savvy will start the porting to the next Tk level, and hang around to do the innumerable bugs that will pop up.

I'm gradually trying to move to Gtk2, even if Tk improves. It has very active developers and seems to be going in the right direction, and the perl code parallels the c code very well, so you can prototype in Perl, and if it's widely adopted, convert it to c with relatively little effort.

So....Perl/Tk is not dead, it's not even dying...it's just growing old with no doctor's care, and being pushed off into the backrooms, while the youngsters( Gtk2, Wx, Tkx, etc) are kicking up their heels and making alot of noise.

I don't know - about Gtk - last time I tried it was one hell with connecting all those signals and other, fairly low-level, stuff. Or, what is your way of doing Gtk apps?

All of the newer gui toolkits have increased in complexity, and is why so many people who just have a simple gui to make, take a fallback position with Perl/Tk. As wiggins said, its mostly about geometry management, and just like with packing-and-Tk, you just have to jump in there and get your feet wet. After you construct a few hundred small test apps, you get the hang of it.

The signal problem is a 2-edged sword. In Perl/Tk programmers would lament the lack of control over signals, now in Gtk2 they complain about the complexity. ?

I admit, it is harder to use Perl/Gtk2 for 4 reasons.

1. The docs take some time getting used to. They are auto-generated from the c code, so they are sparse and to the point. There are a few things to always watch when you open a Perl/Gtk2 perldoc. Look at the inhertitance tree at the top. Gtk2 widgets are well designed and have an inheritance tree. This is important, because the methods of the parents, apply to the child....so often you need to read the perldocs of the ancestors to find the method you need. Also, look at the signals for the widget at the bottom... it will tell you what signal you can define for the widget (also remember to look at the ancestor's signals).

2. The signals. Yeah, they take getting used to, but if you keep your test code samples around, you can usually just cut'n'paste the signal you want into your app and modify the callback.

3. The TRUE/FALSE return values from callbacks are often overlooked by someone coming from Tk. Gtk2 has a very clean way of running/stopping timers and chaining of signals. In a timer, return 1 to keep it going, 0 to stop it. In a signal callback, return 0 to let the signal propagate( chain), and 1 to stop it. Stopping a signal chain can be very useful, like when you want to control how a widget behaves.

3. The Gdk window. The low-level Gdk window is the actual window seen on the screen, it is NOT the widget itself. Often you need to deal with this. The 2 most common issues are the Label widget and the DrawingArea. The Label has no Gdk window associated with it, so it has no signals. You often need to put a Label into an Event box, to give it signalling capabilties like changing colors or clicks. The DrawingArea is another tricky one, and it's low-level window needs to be redrawn on every expose event. The expose event is used often in Gtk2 and has to be watches out for.

4. Color changes. Everyone in Tk laments the drab look and wants the natural system look and feel. Well Gtk2's theme engine does just that, but at the expense of making it very difficult (compared to Tk) to change colors in widgets. See renegadex's reply in Perl-Gtk2::How to set a window background image.. He was the first one here to figure out how to override the default pixmap theme for a window background.

The best thing to do, is look at this Perl/Gtk2 tutorial and run the examples, and try to modify them. Save all your test code for snippets to be used later. Also, check out the Perl/Gtk2 maillist . Many answers are in the archives. Download the last year's worth of archives, for easy searching on your local computer. You will usually find an answer, and if you don't ask on the maillist.

---

I'm not really a human, but I play one on earth Remember How Lucky You Are

I guess I grew up "mashing rectangles together" in the Sony Widgets, OpenLook, early Java, HTML Forms, Frames and page layout. It is all about geometry management. If one doesn't understand these underlying fundamentals, they are limited; not by talent or knowledge, but by the limitations of some layout tool.

My .2 cents

That's quite a small amount of change~

I'm so adjective, I verb nouns!

chomp; # nom nom nom

You can install Tk into ActivePerl via the package manager, but they don't ship it per default anymore and they even advise against doing it (because of bugs, some of which are security, or something).

You won't get much sympathy from me as I don't use Tk at all. I found Tk drifting away from my life when I became a web programmer. Personally, I also find Perl/Tk to be very un-Perlish and more of your standard "create a bunch of objects and pack them up." However, i really would hate to see Perl/Tk die out, but as long as one person out there takes care of this project it won't be abandoned. Are you busy, ATM? :)

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

So how do you do stuff like scrolled, rotext, hlist, in tkx? IMHO these (and many more) are the added value for Perl/Tk. In Tkx you have to DIY again and again ad nauseam.

I was under the impression that installing Gtk2 on windows was a PITA too, mostly because google links point you to outdated instructions and ppm repositories. See Re^5: Accessible GUI Applications in Perl for currently working installation instructions (on Vista anyways with ActiveState Perl5.10). You need to chase down one dll, but the locations are located in the above node, so it should be easy for you.

---

I'm not really a human, but I play one on earth Remember How Lucky You Are