Version: 1.0.0_pre1 (using KDE 3.3.1, Gentoo) Compiler: gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) OS: Linux (i686) release 2.6.8-gentoo-r3 How to reproduce: start kst Create an equation, eg, x^2 from -10 to 10 1000 samples plot it. You see the parabola range and domain are correct Edit the equation - change to -(x^2), and <ok> -The plot limits do not change, so the inverted parabola is not visible. You can manually change the plot limits to make it appear, but autoscale returns to the old limits. Reload from the toolbar fixes everything. (It acts as if the curved is not updated) The same type of behavior holds for psds and histograms. I don't know about plugins. Correct behavior: Autoscale should be accurate for the new plot. The plot should re-scale on <OK> after editing if the plot is in autoscale mode.
Should be fixed for 1.0.0
When a histogram is edited update( ) is called on the histogram, which calls update( ) on its vectors. However, the curve which is created at the same time as the histogram is left untouched, so its maximum and minimum values are unchanged. This applies to equations and psds also. Reloading from the toolbar fixes this as all the curves are updated. One possible solution would be to have the histogram, equation, or psd hold a reference to the curve. The curve could then be updated when necessary.
On Monday 22 November 2004 16:28, Andrew Walker wrote: > One possible solution would be to have the histogram, equation, or psd hold > a reference to the curve. The curve could then be updated when necessary. Won't work... there could be multiple curves, plus it gets really messy for reference counting and garbage collection. I have a "fix" which reworks updating altogether but it's not ready for 1.0. For one, we need providers to be set properly.
I'm not clear on how there could be multiple curves. When you create a histogram it creates a histogram and a curve. The histogram could contain a reference to the curve. How could it have multiple curves? I think we need a fix for this for 1.0. Given your fix won't be ready by then what would you suggest? > ------- Additional Comments From staikos kde org 2004-11-22 22:32 ------- > On Monday 22 November 2004 16:28, Andrew Walker wrote: > > One possible solution would be to have the histogram, equation, or psd hold > > a reference to the curve. The curve could then be updated when necessary. > > Won't work... there could be multiple curves, plus it gets really messy for > reference counting and garbage collection. I have a "fix" which reworks > updating altogether but it's not ready for 1.0. For one, we need providers > to be set properly.
On Monday 22 November 2004 18:22, Andrew Walker wrote: > ------- I'm not clear on how there could be multiple curves. > When you create a histogram it creates a histogram > and a curve. The histogram could contain a reference to > the curve. How could it have multiple curves? > I think we need a fix for this for 1.0. Given your fix > won't be ready by then what would you suggest? Historgrams, equations and PSDs are all data objects. They produce slave vectors, not curves. There is an accelerator in the dialogs to automatically create a curve from the object. There is also a 'hint' so that the user can quickly create another such curve from the object. The user could even right-click on a slave vector and do "Make curve". Equations could use the derived vectors. Other objects could even do so. The problem is more fundamental, and putting in a hack for one curve is not going to solve it. I noticed this in Paris and started working on it, but it's very complicated to get right. We don't want to have unnecessary updates (this happened at least twice in the past year and a half). That causes major performance issues. My only suggestion right now is to extend that patch since it's the right fix, but I also suggest that we ship 1.0 without it and do 1.0.1 later with this fix. Or we delay 1.0 for another full week at least.
> On Monday 22 November 2004 18:22, Andrew Walker wrote: > > I think we need a fix for this for 1.0. Given your fix > > won't be ready by then what would you suggest? On psd, etc change, updatethread:_force is set. But updatethread was not updating the data objects and curves, even if force was set. This patch makes the update thread update curves and other data objects, even if no rvectors update, iff _force is set. This fixes the bug. Created an attachment (id=8385) update.patch
On psd, etc change, updatethread:_force is set. But updatethread was not updating the data objects and curves, even if force was set. This patch makes the update thread update curves and other data objects, even if no rvectors update, iff _force is set. This fixes the bug. Created an attachment (id=8386) update.patch
On Monday 22 November 2004 18:48, netterfield@astro.utoronto.ca wrote: > 00:48 ------- On psd, etc change, updatethread:_force is set. But > updatethread was not updating the data objects and curves, even if force > was set. This patch makes the update thread update curves and other data > objects, even if no rvectors update, iff _force is set. > > This fixes the bug. I don't think this fixes all cases of non-updating, and I think this perhaps causes updates when not necessary, but feel free to commit this temporarily. It will be backed out with the new update code anyway.
CVS commit by netterfield: 'forced update' forces update. Now psds get updated when changed. Approval: George BUG: 93638 M +1 -1 updatethread.cpp 1.31 --- kdeextragear-2/kst/kst/updatethread.cpp #1.30:1.31 @@ -199,5 +199,5 @@ bool UpdateThread::doUpdates(bool force, } - if (U == KstObject::NO_CHANGE) { // no need to update further + if ((U == KstObject::NO_CHANGE) && (!force)) { // no need to update further return false; }