Re: GUI work (was: Graphical help browser)

[Michael Goffioul]

On Tue, Nov 25, 2008 at 7:11 PM, John Swensen <address@hidden> wrote:
> 5) Integrated plotting (40% : I still have a bit to implement concerning how
> windowing events get reported back to new property system in Octave)

Concerning this point, there are still things lying around in my (too long)
TODO list. These are related to the fact that the GUI and octave runs in
different threads. There are operations that happen in the GUI with immediate
effect, but this can imply to run some octave code, which must be run in
the octave thread.

Think for instance about 3D-rotating a plot: you want the rotation to follow
your mouse seemlessly (without any delay). This rotation is typically
performed by changing View property and redrawing. If you want responsiveness,
you'll do that in the GUI thread. Now, if there's a listener attached to View
property, this has to be run in the octave thread.

To handle such situation, my idea was to modify how octave executes
listeners and make it thread aware: if a listener execution request is made
from the octave thread, run it immediately, otherwise queue it for later
execution in the octave thread.

The other solution is to block the GUI thread until the octave thread has
run executed the listener. But the problem here is that the only way to
trigger octave/GUI communication is during readline event_hook, which is
executed every 100ms (by default) [1]. This introduces a significant delay in
the GUI process and you can be sure people will complain. You can have
a feeling of such delay in the current FLTK backend: event processing is
done synchronously with octave, every 100ms; this is noticeable when
you draw a zoom box or rotate the axes.

Now to give my 0.02 about the GUI/toolkit discussion, like John, I also
think the that octave code base should be toolkit agnostic. But OTOH
it should also provide a good framework to build a GUI around it (like this
thread awareness I was talking about previously). That is we should try
to factorize the code as much as possible. In the end, we should also
try to have as few different GUI as possible to avoid manpower spreading.
But I think you won't be able to prevent a few of them, at least the
GTK+/Qt duality. If you focus on GTK+, some time, somewhere, someone
will pop up to write another GUI based on Qt. And vice-versa.

Michael.

[1] AFAIK, there's no way to tell octave "stop what you're doing and execue
me this".