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.
