# To subscribers of the xforms list from Angus Leeming <angus.leeming@btopenworld.com> :
On Thursday 27 March 2003 4:47 pm, Steve Lamont wrote:
> # To subscribers of the xforms list from Steve Lamont <spl@ncmir.ucsd.edu> :
> > Last year I posted a mail
> > (http://bob.usuhs.mil/mailserv/list-archives/xforms-archive/0536.html)
> > in which I asked similar questions. In reply, you mentioned that you
> > would try and roll out a cvs tree over the Christmas vacation. Did
> > anything come of this?
>
> We're in the process of hiring a CVS administrator.
Great news.
> > That aside, LyX has an active interest in maintaining xforms, even
> > now that a Qt frontend has also come on-stream. Perhaps we could
> > make your life a little simpler by offering to host an xforms cvs
> > tree? Please be assured that I am not talking about a hostile
> > fork. I am interested only in getting things moving.
>
> I'm curious as to what you think is needed.
"Needed" is the wrong word. I concur with your statement of yesterday in which
you considered `XForms' to be pretty much mature and stable. That said, here
are some possible improvements:
* My collection of small patches has already reached the xforms list. In it
you'll find that forms.c has two pieces of code that deal explicitly with
tabfolders. Whilst the code 'fixes' the relevant bugs, it's the wrong way to
go IMO.
By and large, xforms widgets are pretty Object Orientated, resulting in
FL_FORM knowing little or nothing about individual FL_OBJECT widgets. This
has allowed your users to devise new widgets without needing to hack the core
library. Its an example of why I find xforms to be a pretty well designed
piece of code.
The tabfolder, however, is relatively immature. It's also the only native
xforms widget that contains its own FL_FORMs which can themselves contain
other FL_OBJECTs. At the moment these internals must be exposed for the
widget to work correctly but such special casing means that other, complex
widgets external to the library itself have no hope of working properly.
Somehow, therefore, this tabfolder code should be moved out of forms.c. For
example, the code that enables the tabfolder and its contents to be resized
correctly probably requires a new FL_SCALE event or somesuch to allow the
tabfolder itself to just 'Do The Right Thing'.
This sort of modification will allow people to continue to devise arbitrarily
complex widgets without the need to hack the library itslelf.
* that said, rolling new widgets into the library is a positive thing to do.
For example, LyX uses a Combox widget that would be a real boost to xforms.
It is currently written in C++ but I now know enough about xforms to consider
re-writing it as a native xforms widget. I'm sure that others out there have
other widgets that could also be rolled into the core library.
* At the time of writing this mail I haven't seen my _big_ patch (entitled
"Cleaning up the key handling") arrive on the mailing list. It may be that I
still have some unresolved problems with my mailer. In brief summary,
therefore, this patch cleans up the key handling code in xforms as a
necessary precursor to enabling it to display and input of Far Eastern
characters natively.
* The Far Eastern patch itself.
So, you see that I am talking mainly about extending the library rather than
repairing what exists currently.
Kind regards,
Angus
_________________________________________________
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 : Thu Mar 27 2003 - 13:30:35 EST