[XForms] New pre-release 1.0.91pre7

[Jens Thoms Toerring]

To subscribers of the xforms list

Hello,

On Mon, May 05, 2008 at 10:43:23PM +0200, Andrea Scopece wrote:
> My feel is that the library cointain a bit of support for
> platform that really are not used anymore.
> To cleanup the things there is the need at least to know
> what are the platform currently used...
> Programmer and Users please: report back some info to list!

Yes, that is an issue that needs taken care of in several
respects. E.g. on the Savannah project page it's claimed
that

     It should work under X11 R4, R5 & R6.

Now I don't know who still got a R4 or R5 release of X11. I
definitely don't (and that for years), so I can't test how
far this claim is for real.

Concerning support for different operating systems at least
there don't seem to be those kinds of claims. I guess that
OS2 and Windows NT are not really supported anymore. But I
have no idea if WIN32 (whatever exactly this is meant to be)
works at all - I don't use Windows, so I can't check. And
concerning rather old versions of different UNIX flavors
there's a similar situation. VMS is another candidate...

> >    There are quite a number of corner cases, i.e. functions that
> >    are in <forms.h> but that have never been documented. It's
> >    difficult to decide what to do in these cases: since the func-
> >    tion never have "officially" become part of the API one could
> >    argue that they should be taken out but, on the other hand,
> >    some existing programs might be using them by now anyway...
>
> Jens, please could you please list who are that funcs/features ?

To be honest, while that's a good question I can't really answer
it in detail. I went through the lib/flinternal.h file and the ones
below lib/private and grep'ed which functions actually exist at
all, which of those were also declared in <forms.h> and in many
cases checked against the documentation. But I didn't make any
notes on that, so I can't give you a list, sorry... I als haven't
gone through all the files below lib/include that make up <forms.h>,
but I would take bets that there are also many declarations for
functions that just don't exist anymore and quite a number that
(at least to my feelings) shouldn't be part of the public API
and also haven't been documented as beeing part of the API...

> > l) All cases where alert box pops up when there's an internal error
> >    (most likely due to the caller of a public function not passing
> >    the correct types of arguments) have been changed to print a
> >    message to stderr only - I don't think it's proper for a library
> >    to bother the end user with stuff popping up suddenly with some
> >    error messages they rather have no idea what they are meant for.
> >    And actually the whole error handling part of the library is in
> >    for a rewrite...
> I vote for dropping all popups, and returning error by return value,
> debug info should be outputted only if requested (cmd line -debug)
> and only from functions of the API.

There shouldn't be any pop-ups anymore, just error messages going
to stderr by default (but that can be redirected to a file or
/dev/null or dealt with in other ways by redefining things with
fl_set_error_handler()).

> Internal errors should/need to be debugged before releasing
> the library.

Yes, for sure. But all, shit happens;-) And then the library is
still not in the state I would like it to be in where errors
like improper arguments passed to API functions would get caught
in time and wouldn't in turn make internal functions barf. That
is something to aim for, but we're definitely not there yet...

> > I guess there have been enough new developments by now to permit a
> > "real" new release (not 1.1.0 yet but 1.0.91). I also got a bit of
> > a feeling that not too much testing is going on (for the last pre-
> > releases I have not got much feedback except by two or three people),
> > so it may not make much sense to wait any longer - a "real" release
> > may stir things up a bit since it could also be noticed by those not
> > on the mailing list. Does anyone care to comment?
>
> My idea, because XForms appear right now like a costant work in progress,
> with no real stable-release, is to start a completely new branch (say 
> 2.0-unstable) and start a rewriting from scratch, collecting the 
> functionality required, dropping those not used, and implementing
> new features.

Rewriting things from scratch is a very attractive idea. In
principle count me in on that. But (isn't there always a but?)
that's going to take a lot of time and work and "old" programs
depending on the current version of the XForms API should keep
working (my own included;-) and I also guess that's what being
a "maintainer" entails. For this reason I may seem to be a bit
conservative, but at the moment my primary goals don't go too
far beyond getting things to work correctly (I hope may views
of that "wrok correctly don't deviate too much from those of
others) - that's what I hope I will be able to handle. When I
first took a look at the code my reaction was similar to yours,
i.e. "get rid of all the old cruft and redo it in a reasonable
way", but then I realized what amount of code there is that I
don't feel that a "rewrite from scratch" aproach will bear
fruits for quite some time. And, on the other hand, in order
to attract enough people to get involved for a rewrite (like
you perhaps?) I think it could be an advantage to have some-
thing that works so that the project doesn't just look like
mere vaporware.

On a personal note, I had some time to spend on something in-
teresting in the last few months since I hadn't had a regular
job, but this will probably (and my bank account says "hope-
fully";-) change soon. And then I fear I will have to spend
more time on other (hopefully also interesting;-) things and
less on debugging or even rewriting XForms.

What I convinced of is that XForms needs some work-over to have
a future at all. There are other toolkits that can be used in-
stead and they will be used if there are no new developments to
make it attractive again to use and hopefully thus get more
people involved.

Ok, is there anbody out there on this mailing list that would
like to chime in with his/her views? It's not as we would be
overwhelmed by the amount of traffic at the moment. I guess
Bob's (thanks to him for keeping the mailing list running!)
server is going to be able to cope with a bit more;-)

                           Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      jt at toerring.de
   \_______________________________      http://toerring.de
_______________________________________________
To unsubscribe, send any message to
xforms-leave at bob.usuhs.mil or see: 
http://cweblog.usuhs.mil/mailman/listinfo/xforms
List Archive: http://bob.usuhs.mil/pipermail/xforms and
http://bob.usuhs.mil/mailserv/list-archives/
Development: http://savannah.nongnu.org/files/?group=xforms