Hi all,
On 15 oct. 09, at 22:02, Joris van der Hoeven wrote:
On Thu, Oct 15, 2009 at 06:11:52PM +0100, Norbert Nemec wrote:
Joris van der Hoeven wrote:
On Wed, Oct 14, 2009 at 05:27:03PM +0100, Norbert Nemec wrote:
Indeed. I guess a proper approach on Qt would be to use
processEvents
frequently during drawing. This does not work with the
check_event gui
interface, but the necessary change in the interface should be
minimal.
Can this indeed be done? Max told me that somethings are also
disallowed
during the painting phase in Qt. Can we process events during
drawing,
or should we first return to the main loop? Long live old-
fashioned GUI
API's...
I just found an ancient thread about calling processEvents from
paintEvent
http://lists.trolltech.com/qt-interest/1997-08/thread00023-0.htm
This seems to suggest that it is not impossible in principle, just
a bit
tricky.
Another source on the web warns in principle:
http://www.kdab.net/~dfaure/conf/Malaga_AsyncProgramming/html/slide_5.html
but this might simply refer to issues like the one discussed in the
thread before. As far as I see it, the main danger is that inside the
TeXmacs code, one must be aware that paintEvent might still be on the
stack. The whole thing certainly is tricky but I think it should be
possible.
Max: how feasable is the following strategy: check_event calls
processEvents after setting a global variable that we are repainting
something.
In each of the event handlers, if this global variable is set,
then either process the event if it is an independent non-blocking
event,
and transform the event in a delayed command if not,
return to the repainting code and set the tell repainting to
interrupt.
I agree that something like this should work. What about the following
more uniform scheme:
each Qt event handler performs some basic computations (which do not
require involvement of TeXmacs objects)
enough to determine an appopriate function call into TeXmacs which is
then boxed as abstract command and inserted in the
delayed messages queue. This would allow to return as fast as
possible to the event loop. Inside check_events should then be safe to
call processEvents which could result in filling up the delayed-
messages queue by some input commands (keypresses or mouse movements).
If this is the case we can set some flags so that check_events can
interrupt the drawing process and return to the main event loop. At
this point the delayed messages can be processed. This would have the
added bonus of giving us the control of the events already
preprocessed so that, for example, we can skip some mouse move events
if they are too many, or process all the key events, etc...
I still have some doubts about the handling of socket events.
Max
_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev
