All the Perl that's Practical to Extract and Report
use Perl Log In
mothra (1667)
(email not shown publicly)
The GUI Loft
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
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
That's the way to do it (Score:2)
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 c
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re:That's the way to do it (Score:2)
That's how it's done for PalmOS apps (pilrc does the translation, I think).
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 chec
Re:That's the way to do it (Score:2)
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.
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re:That's the way to do it (Score:1)
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 a