# 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.
I get the feeling from this list that there's no great appetite to change
xforms greatly. What there is works well and people are basically happy with
it. However, it does contain a number of bugs. Most are small and are
trivially simple to fix. Some less so.
I really think that you should roll out a cvs tree so that those interested
in ironing out these bugs can live on the bleeding edge. Not that I envisage
this edge being very sharp. Continual advancement rather than revolution.
I also think that we should develop a culture where proposed patches are
discussed and refined. To that end I append my list of what I consider to be
bugs in the current source. 10 bugs is hardly very many and of these only 2
or 3 require a considerable amount of work.
In many cases, I've mentioned many of them on this list before. I have often
posted sample patches to this list that "cured" the problem to some extent.
For sure, many of these patches were sub-optimal, but the resulting
discussion has, in most cases, been nil. Zip. Nada.
IMO, that's not the sign of a healthy development process, hence my desire to
know your vision of the future.
As a carrot to go with this stick, I also feel the LyX has a few home-grown
widgets that could be rolled into the main xforms source. Specifically, I'm
thinking of a combox widget. The current code is written in C++, but it
shouldn't be too difficult to rejig it as a proper xforms composite widget
and roll it into fdesign also.
Best regards,
Angus
(README-xformbugs)
o The slider and counter widgets should discard more mouse events when the
mouse button is pressed continuously. Ie, they should react to every 10th
event or so or use a timer. Currently, they are almost impossible to use on a
fast machine.
See sample patch
http://bob.usuhs.mil/mailserv/list-archives/xforms-archive/0505.html
A timer would be better than this, providing consistent behaviour across
different machines. The time interval should be tunable via
fl_set_slider_discard_interval(FL_OBJECT * ob, unsigned int interval);
fl_set_counter_discard_interval(FL_OBJECT * ob, unsigned int interval);
o xforms should pass the XEvent to the XWorkArea handler on an FL_DRAW event.
That way, we'll be able to make use of this info to redraw only the part of
the window that has changed.
See sample patch
http://bob.usuhs.mil/mailserv/list-archives/xforms-archive/0285.html
o the xforms image loader should fail gracefully if it fails to load a weird
xpm file.
o xforms should be able to load png images natively.
o fl_adjust_form_size should be split into two, allowing me to discard a
large chunk of xforms_resize.C
o The browser widget should display tooltips.
Proposed patch at
http://bob.usuhs.mil/mailserv/list-archives/xforms-archive/0518.html
o you cannot switch between two menus without closing the first menu
first (one annoying mouse click too much).
o the problem with clicking on Edit menu when File is open.
JMarc reported it in this thread:
http://bob.usuhs.mil/mailserv/list-archives/xforms-archive.2000/0529.html
and analyzed it here:
http://bob.usuhs.mil/mailserv/list-archives/xforms-archive.2000/0643.html
o xforms should swallow null keyevents. They occur during composition of
multi-byte chars. The problem was reported and a solution proposed here:
http://bob.usuhs.mil/mailserv/list-archives/xforms-archive/0530.html
o xforms should pass FL_KEYRELEASE events to the widgets. Currently they are
swallowed.
o The keyboard event handling code in do_keyboard is unnecessarily weird. The
result from the user point of view is that xforms does weird things when
xke->state is not null (the modifier keys Control, Shift or Alt are pressed
as well as some other key).
It handles this stuff well enough internally (fl_keyboard) but the present
code means that new widgets must be unnecessarily complex. All that is needed
it to pass the keysym and xev to fl_handle_form from do_keyboard and thence
to fl_keyboard. Instead, xforms passes keybuf char by char.
The problem was described here
http://bob.usuhs.mil/mailserv/list-archives/xforms-archive/0525.html
It should be possible to come up with an elegant, LyX-like solution to the
current mess. Ie, replace the contents of fl_keyboard with something similar
to XLyXKeySym.C.
_________________________________________________
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 : Tue Dec 10 2002 - 06:46:19 EST