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? | [reply] |
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.
| [reply] |
Does Perl/Gtk2 depend on any system libs (eg. in Windows, on a Gtk distrib)? I remember that last time I touched Gtk on Windows I had to copy all the dlls to the program dir plus some more trickery - and apparently, just everyone does that.
| [reply] |