From octave-graphics-request at bevo dot che dot wisc dot edu Thu Jun 27 12:47:32 2002 Subject: Re: GTK and Octave From: "John W. Eaton" To: =?iso-8859-10?q?Jo=E3o=20Cardoso?= Cc: octave-graphics at bevo dot che dot wisc dot edu Date: Thu, 27 Jun 2002 12:47:22 -0500 On 27-Jun-2002, =?iso-8859-10?q?Jo=E3o=20Cardoso?= wrote: | On Tuesday 25 June 2002 00:12, Ben Sapp wrote: | | Hello, | | | | I have written a class and some DLD functions to accompany the class | | that allow a person to bring up most GTK widgets from within Octave. | | I also have a callback implementation working. | | Hi, | | I didn't compile your gtk_octave, only quickly browse the code. | | Again an Octave deficiency arises, as the gtk main loop is only called | during "Octave idle time", i.e., while Octave (actually readline) waits | for user keyboard input: | | /* This is called during octave idle time */ | extern int | event_hook() | { | while (gtk_events_pending()) | gtk_main_iteration_do(FALSE); | | return 0; | } | | What happens if the user hits a button which deploys a lengthly | calculation that afterwards the user wants to cancel hitting another | button? Nothing, the current calculation has to finish until the new | button is recognized (or the user code has to check regularly for the | new gtk event, which is not a very clean approach) | | This can be avoided only if event_hook() is also called during Octave | processing. Without knowing enough about Octave "insides", it looks to | me that the only "safe" way of doing this is for Octave to call | event_hook() when the parser hits a "terminal symbol". | What do you think about this? How would this help in the lengthy calculation example? In that case, Octave would be off processing some long-running calculation so there would be no terminal symbol for the parser to hit. If you were designing Octave from scratch with event handling (keyboard input, mouse clicks, signals, something else?) in mind, how would you do it? jwe