Re: using timers in the GUI

[Daniel J Sebald]

On 02/19/2013 01:26 AM, Jacob Dawid wrote:
> > 1) It is somewhat inefficient to be updating the workspace so often.
> > From the code, it appears that the workspace tree is rebuilt every
> > half second if Octave is sitting idle at the command line. If one's
> > workspace variables become numerous, not a difficult thing, that could
> > be a lot of unnecessary machine cycles. Being event driven is more
> > efficient.
>
> That is true, but at the time of development there was no possibility to
> have it work without making major changes (ie. implementing a
> thread-safe event system into octave core).

By thread-safe, are you speaking generally?  I don't think we can have 
Qt code specifically in Octave core, e.g., a Qt signal.  However, there 
might be a case for setting things up internal to Octave that allows 
general access for whatever GUI might be on the other side of things. 
For example, maybe a configurable generic C function that is pinged 
whenever Octave returns to an idle state.  In the Qt framework, such a 
function might be a simple routine that initiates a signal to the 
Workspace window Qt code.

The variable table inside Octave core is a dynamic thing, so really the 
only time that an outside GUI can examine it is when Octave is idle.

I'm thinking that there is no desire, at least at the moment, for a 
feature that tracks changes to Octave data variables while Octave is 
processing.  That would be a much bigger project.


> > One way would be to do a variable-by-variable comparison in the GUI
> > code. A before and after tree, as it were. Another approach is that
> > if John could make the variable table shared memory and include some
> > flag for each variable that is changed or added whenever the value of
> > that object changes, it might be easier to figure out. Then again,
> > setting such a flag again-and-again within a big loop might be less
> > efficient than just doing a before and after variable comparison.
> > That design element can be a future project, but I think that using
> > some method other than a timer would be a good change early on.
>
> Comparing variable by variable was extremely inefficient for large sets
> of data, as I found out. It was much faster to drop the old data and
> renew it again. Anyways, I agree that your suggestion 1) would be the
> proper way to handle things.

I'm curious if you did the comparison within the Qt framework or some 
other means such as keeping a duplication of the data table.  I'll admit 
it is not an easy problem keeping track of general data, and if not done 
efficiently at the C level maintenance could slow down quickly.

For example, a table might be needed that contains a list of Octave 
variables and associated widget pointers within the Qt tree.  The 
comparison of what variables change between idle times could be done 
more efficiently in C, then modify individual elements of the Qt tree. 
Again, this is a future consideration as opposed to the problem at hand.

Dan