[wingide-users] requested features surveySteven D. Arnold Steven D. Arnold" <email@example.com
Sun, 20 Jan 2002 22:47:05 -0500
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 firstname.lastname@example.org Managing Partner AIM: abraxan MSN: email@example.com
Run by Mailman v 2.0.8
Copyright (c) 2000-2002, Archaeopteryx Software, Inc.