Re: [wxperl-users] your xrc wishlist

[Eric W. <scr...@gm...>]

# from Mark Dootson
# on Saturday 17 March 2007 02:13 pm:

>So ... (and sorry for getting all gui designer specific) what's needed
>is a dialog designer written in perl that gets 80% of things right so
>you can fix the other 20% to meet your own needs. The thing is, once
> one has attained the level of basic competence that allows one to
> make a reasonable job of writing such a thing - one has probably lost
> a lot of the incentive to do so. I'm just going to attempt to get the
> ball rolling by shoving something out that does stuff the way I want
> it to.

Oh, I do want a dialog designer.  I just said I didn't want to talk 
about it.  But, here we go.

I don't want it to get in my way.  I also don't want XRC, and I'm not 
sure that anything XML would be a good idea when we have YAML.

What about a compile-time class generator that feeds off of a perl data 
structure?  That would get around most of the troubles with generated 
(printed) code, and possibly lead the way to something that allows 
run-time redefinition (think menu-items, but I wouldn't rule-out 
buttons, sizer layouts, etc.)  Add the ability to break individual 
class designs into separate files and you open the option to use 
something like SGI::FAM to automatically redefine the class when the 
source changes on disk (e.g. the designer could modify the running 
code.)  Now make the designer also understand this data-structure (and 
possibly use the file-alternation-monitor), and you get the two-way 
street that wxglade is so badly lacking.  This, of course assumes a 
unix-like development system (and shouldn't be enabled in typical 
deployment builds.)

Besides being slower than a dead snail on vacation in the arctic, XRC 
seems to have no way to create objects other than in sizer-order.  IMO, 
the object creation and sizer declaration should be totally separate.  
Further, the manual process of loading the individual bits and 
constantly calling GetXRCID($name) to get access to things that already 
have names is just plain painful.  Think `$class->new()` and 
`$self->$name`.  Now, doesn't that sound better?  Perl's unifying 
concept of "everything is a string" really gets lost in the Wx paradigm 
of "everything is a number".

I think it would also do well to include support for events.  AFAICT, 
XRC has nothing for this.

How about code snippets as part of the designer?  (Again, broken into 
individual files.)  I'm not sure about this yet, but it does seem to 
have some yummy smalltalk flavor.

Just think "strings are methods" and you're well on your way to being 
free of the C++ mindset which is likely at the core of most of what I 
find lacking in XRC.

--Eric
-- 
Like a lot of people, I was mathematically abused as a child.
--Paul Graham
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------