Laziness got the best of me this evening.
More Win32::GUI hacking (well, beating-head-against-walling, more like) today made me realize that I don't want to be confined to a life of handcoding pixel positions for controls. So off I went, in search of a better tool (particularly, a good form designer for Win32::GUI) to implement my weather program...
Holy moly.
The GUI Loft is a superb (beta, but very very functional) form designer for Win32 native GUI applications. It's based on Win32::GUI, and in my opinion, is exceedingly well-designed.
At first (like, the first 13 seconds) I was a little disappointed at the fact that this tool doesn't generate Perl code, instead using its own engine (aka, Perl modules) to build the windows you design, which are stored in .gld files. However, the author's explanation of why this is so was not only instructive, but gave me even more incentive to play with this.
I've never wanted to use a GUI generator because I didn't want to use pregenerated code. It's like hand-optimizing the assembler that comes out of your compiler. The author of Loft apparently thinks like I do.
Now, my ideal would be your GUI builder creates some kind of text file that specifies the GUI, and you have a preprocessor (read compiler) that turns that text file into code. So then you add a suffix rule to your makefile, and voila! And it's a text file, so it'll stand up (sort of) in version control; and maybe you can modify it by hand, if you follow some syntax rules. And the GUI builder can reopen it later.
I think glade works like that, but I've never gotten the chance to try it.
Re:That's the way to do it
ziggy on 2002-05-04T13:46:56
That's how it's done for PalmOS apps (pilrc does the translation, I think).Now, my ideal would be your GUI builder creates some kind of text file that specifies the GUI, and you have a preprocessor (read compiler) that turns that text file into code.I'm not so sure that this is the way to go though. Gnome, KDE and Mozilla are converging on the idea that the best way to design GUI apps is to encode the UI design in an XML file and use that file at runtime to build the interface elements. Last I checked, glade builds the XML file, and libglade provides the runtime support to use it.
Re:That's the way to do it
jdavidb on 2002-05-04T14:36:22
That makes at least as much sense as my suggestion. As we know, table-driven logic is usually the way to go. (And if that table is particularly complex, it belongs in XML.) If your tables drive your code, you can change them instead of the code, and be working at a higher level.
s/tables/data/g; something like that.
Re:That's the way to do it
jplindstrom on 2002-05-04T14:53:16
I totally agree that text is so much more useful than a binary format. Actually the first versions of The GUI Loft used Data::Dumper for storage (it still can read those files).
Some large data structures didn't go well with Data::Dumper, so I switched to Storable with some hesitation (Data::Denter was an option too, but it's too slow and needs an Inline implementation). I've found that the problem isn't there when using the Perl-only implementation of Data::Dumper, so the Data::Dumper support will return at some point.
Lately there has been requests to be able to dump to XML, and I plan on doing that if I can only find a decent XML dumper module. Data::DumpXML might be the way to go judging from this node: http://www.perlmonks.org/index.pl?node_id=135347
/J
