# To subscribers of the xforms list from David Paigen <paigen@heathen.com> :
> # To subscribers of the xforms list from Angus Leeming <a.leeming@ic.ac.uk> :
>
> Steve, how do you see future development of xforms panning out? At present it
> seems to be stagnating somewhat. That may seem churlish, given that you only
> released 1.0final over the weekend, but it isn't meant to be. I'm merely
> pointing out the reality of a release that occurred 6 months after you said
> something along the lines of "absolutely, definitely 1.0 will be released
> next Friday." I don't recall toooooo much new code going in in the interim.
After reading the above paragraph, I wanted to insert a bit of real world
perspective from a professional software development manager.
The hardest part about developing software is releasing it. I thought
about the fact that there were five release candidates, and I thought
about the fact that there was no formal testing procedures, no profit
motive, and less than the full attention of the release manager. After
all, he has a real job and a real life.
Given all that, six months seems like about the right amount of time.
About one release candidate per month. That gives the community enough
time to grab, install, and work with the software, and time for them
to comment back.
And the last thing you want to do when trying to release software is
to add any new code. Every change in the source potentially introduces
new bugs and requires yet another release candidate.
So my kudos to Steve for a job well and timely done, from a guy who
knows how hard it can be.
[ObXForms:]
I stumbled on xforms about 18 months (or more?) ago when I needed
a drag&drop gui builder for X. In retrospect, it looks like I
could have done the job with gtk or qt, but it was not obvious
that a gui builder was included and they seemed very heavyweight.
XForms has worked very well for me. It does just about everything
that I want. I do have some gripes though, and I am willing to put
in some effort to fix them.
1. Better documentation. While the supplied manual is very good to
learn from, it is a lousy developer's reference. The pages are too
large and take too long to load, the index gives no clue as to the
nature of a reference or its context, and there need to be man pages
or a quick reference guide.
2. OO interface. I can't count the number of times a link has failed
because I called fl_select_button instead of fl_button_select or
something like that. A consistent, orthogonal set of C++ classes
would be great. I think this would be best as an optional wrapper.
What do you think? I have a not-very-general set I have worked up
for my current project, but would like more input from people who
have worked with gtk, qt, and mfc before I propose anything.
3. Nested tab folders. Maybe. I wanted this at one point but found
another way to structure my gui. I am not sure if nested tab folders
are a good idea at all, would they be confusing to the user?
4. Better resizing support. Or do I not know enough? I briefly looked
at the gravity stuff quite some time ago and decided there was too
much to learn for a 1.0 or 2.0 product, so I put it aside. Is it easy?
Is this my problem, a problem in the documentation, or does the resizing
issue need better treatment in the api?
-David Paigen
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://world.std.com/~xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/
This archive was generated by hypermail 2b29 : Fri Dec 13 2002 - 12:48:25 EST