<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body text="#000000" bgcolor="#ffffff">
Here enclosed a svn diff file with a number of patches.<br>
<br>
1) I've modified AppRun and AppWaitMessage, in order to achieve a
behavior similar to that of both GTK and Qt. This change makes mouse
movements on the form to wake up the main loop (I think this to be
necessary for hints on controls, and that's what both GTK and Qt
do), and gets rid of an useless wake up of main loop each second. No
adverse effects that I can tell. Most changes can be reverted by
unsetting <i>CD_X11_UseLCL_MainLoop</i>.<br>
<br>
2) I've fixed form repositioning on the screen, by removing a
harmful XTranslateCoordinates in customdrawnforms_x11.<br>
<br>
3) I've fixed the crash at the end of the program by modifying
EvClientMessage always in customdrawnforms_X11. I left there a
lengthy explanation on what SendCloseQueryMsg does, which can be
suppressed without hesitation.<br>
<br>
4) Again in customdrawnforms_X11 I've modified ShowHide, to fix the
bug which didn't hide or close the second form in nonandroidtest.<br>
<br>
5) I've fixed the double slashes on some font paths. Just a cosmetic
fix, because Linux doesn't care, and TT_Load doesn't tamper with
paths.<br>
<br>
6) I inserted a different mechanism to handle timers, because I was
unhappy with a timers behavior, which is, well, let's say, less than
perfect. A resolution of one millisecond, and errors in the order of
one second are a bit contradictory. I tested with a small
application, and I compared the results with those obtained with
GTK2 and Qt. Also GTK2 shows errors, but by far much smaller, while
Qt is reasonably accurate.<br>
<br>
Basically there are two flaws: <br>
<ul>
<li>GetSmallestTimerInterval isn't the best way to handle timers,
if you have more than one. If two timers start approximately at
the same time one with interval 700, the second with 1000, when
the first one expires, the next to fire is the one with larger
Interval, because it expires after 300 ms.</li>
<li>Handling the timers in the AppWaitMessage (i.e. in the main
thread) makes timing too much disturbed by external
unpredictable events, like mouse activity on the form, other X
events, OS scheduling, etc. <br>
</li>
</ul>
I tried to solve at least the first one by using a different
technique, which I've been using since the dawn of times in my real
time systems. A queue of timers, kept in order of firing, so that
the head of the queue is always the first timer to handle. The queue
is built as a double linked list, so that insertion and deletion are
very fast. Actually, if there are no disturbances, the timing is
much more accurate (even better than that of Qt), but when there are
too many X events, and maybe some repaints, the timing becomes quite
bad. Not a big step forward. One can revert to the old situation, by
unsetting <i>CD_X11_UseNewTimer</i>.<br>
<br>
The real solution would be to handle timers in a separate thread,
which isn't disturbed by main thread events, and just send an
appropriate message if and when a timer expires. In this context my
queue could be much more useful than now. Other "native" widgetsets
run in their own thread, or multiple threads, and this allows
cleaner solutions. After all we have multitasking since more that
forty years, multiple core CPU's since at least ten years: we're not
obliged to put everything in a single thread as it was customary
fifty years ago, when computers were powered by vacuum tubes instead
of IC's.<br>
<br>
That's all about the patches. I've also began to look what is
required for ATI-SPI and ATK. I gathered that GLoop is only the top
of the iceberg, and maybe not even of the right iceberg, but I'll
tell in more detail another time.<br>
<br>
Giuliano<br>
<br>
<br>
</body>
</html>