Re: __fltk_ginput__ to __qt_ginput__

[Michael Goffioul]

On Sat, Apr 5, 2014 at 6:12 PM, Daniel J Sebald <address@hidden> wrote:

Re: __fltk_ginput__ to __qt_ginput__

On 03/28/2014 10:51 AM, Michael Goffioul wrote:

QtHandles already supports a bunch of callbacks. The most outstanding
missing one is the "motion" callback.

and

Re: [PATCH #8316] Variable Editor

On 02/24/2014 11:45 AM, John W. Eaton wrote:

now would probably be a good time to take another look at the
changes you proposed last year. Can you tell me where they are again? I
thought they were in the patch tracker but I don't see them now.

---

I'm surmising that the UI callback (there is a distinction between UI callback and C++ code callback) and what we have from time to time discussed as "background queue" are in fact one and the same.  That is, when a GUI object does a callback, all it is doing really is calling Octave with the script command that is assigned to it in the list of properties.  It's just that the command doesn't appear at the command line or end up in the history.

Yes, I think it's pretty similar. Basically it's about pushing some action to be executed synchronously in the octave thread, from another thread.

The graphics manager maintains an event queue, which can be populated from any thread. The events in the queue are processed in the octave thread, using the readline input hook. In the graphics system, there's no need (yet) for a feedback or a return value. So it's only push-and-forget. The pair base_graphics_event/graphics_event form the base of the event class hierarchy; at the moment, mainly 2 events are used: change property of graphics object, execute callback.

The main problem in the mechanism is that it relies on readline. So first readline must be compiled in and active (octave must run in interactive mode), second it has a pretty big lag (~100ms, which is huge on modern computers, but it's hard to make it lower without CPU increase).

Michael.