Sidnei da Silva wrote: > On Tue, May 31, 2005 at 09:37:32AM -0600, Shane Hathaway wrote: > | I have only GUI code so far, because in this project, I want the UI to > | drive the requirements. I'm thinking about the code behind it now. > > Ok. What are you using for drawing the UI? I just googled for wxGlade > but it seems like it just generates code and doesn't save in glade's > xml format (which would allow for sharing the UI design between > wxpython and pygtk).
I'm using XRCed, which comes with wxPython. I was planning to be selfless and use all-inclusive technologies like anygui, XUL, or AJAX, but I finally decided that I was wasting a lot of time and I needed to selfishly use the technologies I like the most (or dislike the least.) ;-) Also, now that wxPython 2.6 is out, I can safely depend on the latest features. Once I decided on a GUI, it took me hardly any time to get past the easy GUI stuff and start to think about the real requirements for a good software configuration browsing/editing session. It may turn out that you can browse/edit configuration just fine through the web, but I find it a lot easier to discover requirements if I assume that it *won't* be done TTW. Here are some of the less obvious requirements I've discovered so far: - The configuration editor should be useful for fixing a broken configuration. Imagine a new Zope user starts one of Stephan's tutorials, but misspells a Python package name, and wants more help than a traceback for fixing the problem. The user launches the configuration editor, which points out the problem and makes it easy to fix it. - The configuration editor should work even if the user has written crashy code. Therefore, the GUI code should not directly import any possibly unstable Python modules. Unstable Python modules could change stuff they shouldn't, segfault, start infinite loops, etc. Virtually all new code is unstable. - Users should be able to save a broken configuration. Imagine how annoying a Python code editor would be if it didn't let you save your Python module unless it passed some checks. The same principle applies here. Saving broken stuff is an essential part of a normal development workflow. Shane _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
