|
From: | Daniel J Sebald |
Subject: | Re: using timers in the GUI |
Date: | Wed, 20 Mar 2013 11:59:32 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 03/20/2013 03:22 AM, John W. Eaton wrote:
On 02/19/2013 02: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).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.Maybe I'm missing something, but what comparison is needed other than comparing the lists of variable names, types, and sizes? That is all the information that is displayed, isn't it?
One feature I'm imagining is placing the cursor above a variable in the workspace and the tool tip displays the variable's contents in some way. However, I don't think that requires comparison at all, just retrieving data.
I still don't understand the use of the timer. The attached patch seems to work for me. If I understand correctly the way things work with the patch applied, an event will be triggered from the readline idle loop to update the workspace view. That function will then call the workspace model to update the info stored there, then redisplay it. Currently this is just happening on each call, but we could limit that to once per prompt instead of ten times per second when Octave is sitting and waiting for input. A similar approach could be used for the history widget. The second patch attached to this message makes that change. Again, I don't think it makes sense to update the history list ten times per second, or at some other arbitrary interval. The list will only change when Octave accepts a line of input or when it is modified through some GUI menu item. Shouldn't it be safe to process the GUI "update history" action when Octave adds the entry to the history list? For changes made through GUI menus, we can schedule an event to process at the next "safe" time (readline event hook function, prompt function, or the point when Octave is accepting input). If the list of events to process could be large, we could enforce a limit on the number of events that can be processed on any given trip through the readline event hook function. If there is some reason that these changes can't work, I'd like to understand why. It seems much simpler to call these functions without using timers.
Those changes look good. They are pretty much what was discussed as a more event-driven scheme, and use Qt signal/slot as designed. If it seems to run properly, go with it. The timer code will always be in the repository if some issue comes up.
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |