Here is my suggestion. Do not design a program that works with gtk.
I say this not because I have a problem with gtk. In fact, I have learning to use the toolkit on my "to do" list for both Perl and C. Obviously for unixish systems it's an important library and with good reason.
I say this because your application should not depend on gtk. If you keep all of the user interface routines as separate and clean as possible (in their own module would be fairly tidy), this keeps you thinking of the interface as a view to your application's functionality and data.
For a larger, more complex application, I'd venture to say that keeping the view, the data, the functions, and the storage I/O separate both in your mind and in your application will make each element easier to construct, test, integrate, debug, upgrade, and replace. This hopefully increases the chance that your program will succeed and survive challenges it meets down the road. | [reply] |
thanks for your comment ... my vision of how to implement this resembles your suggestion, though i didn't explitly mention that.
| [reply] |
A quick search on freshmeat reveals over 400 apps using gtk (albeit not with perl, the API is similar in all languages). I'd say it's a good starting point. I find that lots of GTK stuff on freshmeat is just a GUI wrapper around console stuff. Good luck!
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
part of my app involves calling console stuff, which is part of the reason i like doing it with perl. thanks for your comment.
| [reply] |
If you want a good example of a large application using Gtk-Perl, take a look at Pronto. You can find it at
http://www.muhri.net/pronto
| [reply] |
thanks ... i've downloaded pronto.
| [reply] |