[wingide-users] requested features survey

It's a cool idea for Archaeopteryx to have a survey on requested
features for Wing.  The GUI builder was the most requested feature at
the time I took the survey; it was one of my votes as well.  I'd like
to tell you what I'd most like to see in Wing, then I have some
comments on a possible GUI builder piece.

In terms of most desired features, the main point of a debugger is to
help clear problems in one's code.  I believe this is best
accomplished by shortening the view-alter-test cycle.  That is, a bug
arises; I debug the program and view/test the code to see where a
problem is arising.  I then alter the code.  I then test again to see
if the problem was fixed.

If I could modify a function inline in Wing, and then see immediately
what the output would look like without having to restart the
debugger, that would be cool.  Think of it as a combination of editing
code and debugging at the same time -- mix the writing of code and the
debugging of code into a single action.  I might prime a function with
certain values, and as I write the function, as I enter each line,
Wing would show me what the values would currently be.  If my
function calls other functions, if I don't actually want to call those
functions, I could prime the return values as well with arbitrary
data -- this would be especially useful for database calls.  I've
never heard of this being done before, but I think it'd be a really
cool idea and it'd move debugging forward a lot.  I could set up a
suite of different input values, which would become the basis of my
regression tests for the function.  Then I could just select one set of
input values or another, and see what the function is doing with those
values at any point, or just see what the return value would be.

I think something like that would make code-writing much faster and it
would eliminate a lot of bugs before they ever got written; as such it
would save an enormous amount of debugging time.

On the subject of GUIs, probably one of the most basic design
principles should be that the GUI should be capable and
cross-platform.  Cross-platform is obvious; capable means we are not
hemmed in to just a few widgets or too dependent on a single widget
provider.  I also don't like depending on another language such as TCL,
so if you agree with me about that then that rules out TK.  GTK, while
technically cross-platform, seems relatively weak/unsupported on
Windows; I don't think it's a strong contender, but I admit I'm not an
expert on the latest developments in that area.  wxWindows seems like
the most obvious GUI to support.

I've learned, however, that it's good not to mix action with
presentation.  That is, it's good to separate the stuff that presents
the user interface with the stuff that acts on it.  A good example is
HTML.  When writing a web app, it's better not to embed the HTML
directly in code.  It's often more convenient to use an ASP-like
model, where the page is basically an HTML file with code embedded in
the file as needed.  Even in that model, it's best to keep as much
code as possible in external modules.  If this is done, the interface
can be handled separately from the code that manipulates the
interface.  It maximizes the modularity and reusability of your code
as well as your interface.

Unfortunately, wxWindows and most other GUIs force you to mix
interface and code a lot.  You can't just "represent" a wxWindows
interface and have some tool that will render that interface into an
actual application, using backend code that you provide.  The
interface code is intertwined with your backend code.  So to change
the interface you have to be a skillful wxWindows programmer, not just
a web-designer type.

XUL is a markup language that is used with Mozilla.  It is somewhat
like HTML but far more powerful in terms of the user interface it can
provide; all of the Mozilla application itself is rendered using XUL,
so that means if Mozilla can do it, XUL can do it.  It's as
cross-platform as Mozilla itself, which is to say, very cross
platform.  It's as stable and reliable as Mozilla, which in the latest
releases is quite good and getting better.  It very effectively
achieves separation of code and interface, separation between things
that describe and things that do.  It is not limited to the default
widgets that come with XUL; very complicated new XUL widgets have been
developed and are actually relatively easy to develop.  For example,
someone created a XUL widget that actually plays the Minesweeper game!
If you can create such a widget in XUL, you can create a widget that
looks and feels virtually any way you want.

I would suggest taking a close look at supporting XUL in the GUI
builder.  With proper modular design, it should be possible,
eventually, to support other GUI systems as well.  But of GUI systems
that meet the basic design principles, I think XUL is a strong
contender -- indeed, in my mind, the strongest contender.

Long post; if you've gotten this far, thanks for reading. :-)

-------------------------------------------------------------- 
Steven D. Arnold                                    Neosynapse
stevena@neosynapse.net                        Managing Partner
AIM: abraxan                       MSN: neosynapse@hotmail.com