Re: eliminating GUI event listener class

[Daniel J Sebald]

On 04/08/2013 12:07 PM, John W. Eaton wrote:
> On 04/08/2013 12:58 PM, Daniel J Sebald wrote:
> > On 04/08/2013 11:49 AM, Daniel J Sebald wrote:
> > > On 04/08/2013 11:23 AM, John W. Eaton wrote:
> > > > The only thing we are using the event listener object for is to
> > > > handle cleaning up the GUI when we exit from Octave. I tried to
> > > > switch that to using signals and slots but was not successful.
> >
> > Something else I should say. I do think that the event listener isn't
> > necessary. That is, most everything I can think of on the GUI side can
> > be event driven by signals.
>
> Yes, I'd like to remove it.
>
> > However, going the other direction is a
> > different issue. I think things that go to the Octave thread have to be
> > queued in almost all cases. The issue there is that Octave can be busy
> > for a long time and waiting for a response from the Octave thread should
> > be avoided.
>
> Right, I'm not trying to eliminate the queuing requests for Octave to
> perform some action. Currently, I think we are only performing those
> actions when readline is waiting for input, but we might be able to
> perform some actions at other points.

Well, that seems about right, whenever Octave thread is free it 
processes the next event.  It seems that it would be nice to have some 
type of GUI-related response to Octave returning to readline, whatever 
that might be.  If there is any place for a hook function, it is simply 
that one spot.  Because there, one can tell if Octave has hit a 
breakpoint or not.

Now you mention perform some actions at other points.  You are probably 
thinking workspace updates, maybe progress bar update, or what not.  I'm 
not thinking quite that far yet, just trying to think of a concept for 
good initial overall flow.


> Maybe you have some other idea in mind?

I have a broader idea in mind that I'll write in a followup post: to 
remove the hook functions, and I think eventually simplify things.  It 
requires some work up front in Octave core, but once that's in place 
it's all GUI C++ programming (or GFLTK? programming).  I'll toss the 
idea out and see what you think.

I'm not 100% certain, but I think in addition to the hook function being 
slightly hard to maintain, it has the disadvantage of coming into GUI 
memory space add uncertain times.  I wonder if that might eventually be 
prone to timing problems (at least for a programmer who isn't fully 
aware of how things are set up, i.e., issue a signal inside the hooks, 
don't modify things directly).  With a simplified Octave command queue, 
we might be able to control any timing issues a little better via Mutex 
in a centralized location.

Dan