It looks like wxglade will generate code but without any hooks or ways to extend the generated code without editing it directly. Bummer.
I was really hoping to use a GUI to make my GUI. :-(
I'm always wary of those plain code generators because they never are round-trip capable, which means that my upfront design would need to be perfect. And if I had a perfect design already, I wouldn't need a graphical tool to create it. bart has a cool idea how to make code generators work across version upgrades, by applying diff against the baseline file and your current code, and then patching your changes into the new version that wxglade or whatever is the code generator du jour outputs. Of course, some manual fudging will still remain, and you always run the risk of losing all your precious changes by overwriting your file from within wxglade, but that's what we make backups for, right?
The other approach could be to steal the Perl GUI Loft and adapt it to work with Wx instead of using Win32::GUI, at least in the code/bindings it creates. I think the GUI Loft takes a more VBish approach of calling functions in your namespace based on the name of the control, which is a magic binding, but better than littering your object model with callbacks everywhere.
Re:wxglade - A one way trip? (diff, patch?)
bart on 2006-10-09T17:46:39
The basic idea is, just as in a version control, that the original generated code gets stored as a root version, and then it branches. One branch is the manual edit, by you, the other is the changes induced by editing the GUI and rerunning the code generation. You'd then be able to merge the manual changes back into the freshly generated code, allowing you to modify the GUI using a WYSIWYG visual designer, and still keep any code you attachedto the widgets.
I can imagine a similar approach being applicable to any system that involves generating initial code which you then have to fill up, such as the core of an XS module.Re:wxglade - A one way trip? (diff, patch?)
jjore on 2006-10-09T18:15:15
I'm generally convinced this is a bad idea. Generated code ought not to be edited especially when in this case the odds are pretty high the code is going to get regenerated.Re:wxglade - A one way trip? (diff, patch?)
bart on 2006-10-25T19:43:11
Well, yeah... but I'm lazy. I don't want to write code that the computer can generate. Very lazy. That means I want the computer to write not only the core code for me, but also the stubs for the event handlers, which then I just have to fill up with custom code. Just as in VB. Yes, that may mean that the computer may later want to change the file it wrote the stubs to, after the user edited them.
I can think of 2 obvious ways to do it:
- Have it generate a single master program source file, including the event loop for a widget, and the switch statements, which the user can edit.
- Have it generate a master file which calls event handler subs, and have a much simpler separate file with the handlers, where the user just has to insert his event code. The latter would be initialized with empty event handler subs, which the user can edit, and the computer would only add event subs that are missing, the next time around. That would imply that it should be a bit smart about how to parse the source code, so it would know what is missing next time around, and the order of subs wouldn't matter. The code generator would never delete anything.
I believe that you probably object most strongly to the former model, and might find the latter (more) acceptable...? After all, its cleverness wouldn't have to be so high, and it wouldn't cause any major disasters in any case, anyway.
Re:wxglade - A one way trip? (diff, patch?)
jjore on 2006-10-09T17:46:54
It turns out there's an easy way to use wxglade to generate code and *not* edit it manually afterward. I'll post more on this later.Re:wxglade - A one way trip? (diff, patch?)
Alias on 2006-10-10T02:55:07
Sooner would be even better than later!:)
I've got the itch lately to wrap various bits and pieces in a GUI candy shell, and if you have a straight forward way to do this maintainable without hacking Wx directly, I for one would love to hear how it's done.Re:wxglade - A one way trip? (diff, patch?)
jplindstrom on 2006-10-10T11:16:50
Actually, the creation of accessors from the control names isn't a GUI Loft thing, it's a Win32::GUI thing. At least it was a couple of years ago. Now there's a new way of doing that, but TGL hasn't kept up.
Re: code generation, there are some thoughts on that in the manual.
