Re: [wxperl-users] wxPerl IDE / GUI designer

[Peter G. <pe...@pg...>]

I used DialogBlocks to generate the graphics for a wxPerl application.
DialogBlocks generated the xrc file, and wxPerl read it.

--Peter


On Mon, 2007-02-12 at 23:06 -0800, Eric Wilhelm wrote:
> # from Daniell Freed
> # on Monday 12 February 2007 04:37 pm:
> 
> > but it lacks real IDE features  
> >like GUI designer, code completion, and inline syntax checking.
> 
> IMO, the GUI designer doesn't belong in the IDE since it shouldn't be 
> generating code (more on that below.)  I'll also pass on syntax 
> checking unless it *always* knows what I mean better than I do.
> 
> At this point, if you build a good xrc editor, the wxWidgets and 
> wxPython users would all jump on it.  Hmm, maybe even plugins with 
> Inline::CPP and Inline::Python?
> 
> I think the XRC system seems fairly workable, but I haven't fully 
> wrapped my head around it yet.  The C++ examples make instantiation 
> seem rather tedious, and it appears that your code is still very much 
> bound to the layout (or at least the named contents.)  Basically, 
> anything that needs to be connected to an event has to have some code 
> fetch it out of the XRC, and it appears that some objects can't be 
> represented while others have to be manually instantiated.  I'm sure 
> there's a method to the madness, but I'm also sure a lot of it has to 
> do with technical limitations of C++.  Just now looking at it again, a 
> perlish implementation might involve auto-vivifying (hierarchical?) 
> accessors for each of the XRC entities.  But this is just a first (err, 
> fifth) glance and somewhat uninformed opinion at this point.
> 
> <mildly educational rant about wxglade>
> To be clear, *statically* generated *code* is *always* going to (at 
> least eventually) cause maintenance trouble.  Unless you can subclass 
> and tweak the generator from your own code (i.e. meta-programming (i.e. 
> Moose)), you *will* run out of rope somewhere.
> 
> This means using wxGlade will eventually earn you a visit from swarms of 
> locusts (or at least a really long session with sed and such.)  It 
> doesn't matter how smart it seems to be about tagging the code or if 
> you think you're safe because you subclass what gets generated or 
> whatever.  One day you realize that it drops all of your button id's on 
> the floor instead of storing them and your best options (besides 
> ditching it altogether) are to maintain some duplicate table of 
> manually assigned id's or mine the wxg file for them and then generate 
> more code.  So now you're writing a compiler compiler and perl6 is sure 
> to beat you to a ship date.  Or maybe not that, but simply different 
> versions of glade have different bugs and suddenly the commits in your 
> version control system are full of noise and you don't know what's 
> changing and what isn't.  For me, it was lots of big and little things 
> adding up to "this tool is just not working."  I almost forgot to 
> mention "generates code that doesn't run under 'use strict'."
> 
> I learned long ago that code generation doesn't work, but I saw how 
> wxglade did it and thought "hey, this might be feasible."  Those who 
> forget (or ignore) the past are doomed to repeat it and all that jazz.
> 
> Your milage may vary, mine didn't.
> </rant>
> 
> --Eric