Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

mothra (1667)

mothra
  (email not shown publicly)

Journal of mothra (1667)

Saturday May 04, 2002
12:23 AM

The GUI Loft

[ #4658 ]
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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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
    • 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.

      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

      • 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
    • 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 a