[XForms] New pre-release 1.0.91pre3
Jens Thoms Toerring
jt at toerring.de
Wed Mar 26 16:50:31 EDT 2008
To subscribers of the xforms list
Hello,
having a few holidays with rather ugly weather allowed me
to continue so, again, here's something new to play with:
http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre3.tar.gz
The most important changes are:
a) Input objects now lose the focus (and report changes back
to the program) on clicks of other objects that accept a
click with the mouse (buttons, sliders, etc.). This gets
around the problem that if you had an input field, edited
something in there (without hitting the ENTER or TAB key)
and then clicked on some button that's supposed to make
use of what just had got entered into the input field, the
function fl_get_input() still returned the unchanged value
since the input field never lost its focus and thus didn't
accept the changes you made.
If you move the mouse out of a window with an active input
object and move it into another window keyboard input now
goes to the new window instead of to the one you left.
Further restructuring of the event handling code. Same
code is now used in xpopup.c and forms.c for dealing
with idling.
b) Memory gets deallocated also for all objects on call of the
functions fl_free_form() and fl_finish(). I would very much
like to come to a point where XForms doesn't leak memory
anymore - but that's not done yet, at least tabfolders still
pose a problem...
The code from the file lib/be.c (a kind of primitive garbage
collection) isn't used anymore, it didn't really do what I
guess it was intended to do (and then only when an idle
callback was installed).
c) Timeouts should be a bit more precise now and not expire
too early anymore (as it's promised in the manual).
d) Silders (and thus scrollbars) got a rework and some minor
annoyances hopefully have gone.
e) If available sigaction() is now used instead of signal()
for signal handlers.
f) Code emitted by fdesign doesn't use fl_calloc() anymore
but instead fl_malloc() (somebody reported to have had a
bit of a problem with that and it didn't make any sense
to zero out the memory anyway).
I have also another proposal. At the moment the action asso-
ciated with a button gets executed the moment you press down the
left mouse button. Most other toolkits do it differently - the
action only gets executed when the left mouse button is released.
I prefer that behaviour quite a lot since it's then still possible
to move the mouse (with the button still pressed down) away from
the button and release the mouse button only then, thus avoiding
the action coupled to clicking onto the button. This has a few
times saved the day for me when I carelessly clicked somewhere
and only in the very last moment realised that this was a rather
stupid idea... As far as I can see all button types (except touch
buttons for obvious reasons) could be made to work that way. What
do you think?
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
More information about the Xforms
mailing list