|
From: Eric W. <scr...@gm...> - 2007-03-18 10:51:35
|
# 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
---------------------------------------------------
|