| Summary: | ability to operate only on what is visible shown in plot | ||
|---|---|---|---|
| Product: | [Applications] kst | Reporter: | Netterfield <netterfield> |
| Component: | plotting | Assignee: | Duncan Hanson <duncan.hanson> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | arwalker |
| Priority: | NOR | ||
| Version: | 1.x | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Screenshot of New/Edit interface for proposed Subcurves.
SubMockup#2 |
||
|
Description
Netterfield
2004-08-10 15:42:32 UTC
*** Bug 96249 has been marked as a duplicate of this bug. *** How about a "subvector" that can be created by the user - the parameters would be an existing vector, and a plot or custom min/max values. The subvector would have the same values as the existing vector, but only in the range determined by the current min x and max x values of the plot, or the custom min/max values. Eli and chatted about this a little yesterday... At the low level, this could be implemented by a new data object: KstVectorView (or some other name). It takes as inputs an X vector, a Y vector, and a view range (xmin, xmax, ymin, ymax) and it outputs X/Y vectors over the defined range. The only sticky bit is interpolation... there are a couple options here: -merge the VectorView into curves, and give curves outputs -split interpolation out of curves into a new data object KstInterpolator. -Let KstVectorView interpolate, keep everything else the same. I favour the third option (but I think Eli favours the second). In any case, we could then create a few different UI's for creating KstVectorView objects - eg, by the fit dialog. Perhaps before we start discussing implementation details we could decide on the functionality. To get things rolling the LFI team needs to see something like the following: * for every curve in every plot there will be created two vectors which give the x,y values of all the points contained within the plot boundaries. * these two vectors will always be of the same length. * these vectors will automatically update when the view of the data is modified (e.g. the user pans, zooms in, zooms out, etc.) * these vectors will, like other vectors, automatically create and update associated scalar values (giving values such as mean, std dev, min, max, etc.) * in the interests of preserving memory the user will have the ability to switch off or on sub-vector generation on a curve by curve basis. The default setting will be sticky. * the names of the sub-vectors will be such that they are uniquely identified and each sub-vector name will contain the name of each of the parent vector, the curve of which it is part, and the plot within which the curve is found. On 14-Mar-07, at 6:55 PM, Andrew Walker wrote: > ------- Additional Comments From arwalker sumusltd com 2007-03-14 > 23:55 ------- > Perhaps before we start discussing implementation details we could > decide on the functionality. To get things rolling the LFI team > needs to see something like the following: > > * for every curve in every plot there will be created two vectors > which give the x,y values of all the points contained within the > plot boundaries. > * these two vectors will always be of the same length. > * these vectors will automatically update when the view of the data > is modified (e.g. the user pans, zooms in, zooms out, etc.) > * these vectors will, like other vectors, automatically create and > update associated scalar values (giving values such as mean, std > dev, min, max, etc.) > * in the interests of preserving memory the user will have the > ability to switch off or on sub-vector generation on a curve by > curve basis. The default setting will be sticky. > * the names of the sub-vectors will be such that they are uniquely > identified and each sub-vector name will contain the name of each > of the parent vector, the curve of which it is part, and the plot > within which the curve is found. Those also sound like implementation details... what is it that they want to do? In any case having a VectorView is something that logically makes sense and will allow for the implementation of features like the ones I think you are saying are wanted. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ I don't see where I discussed implementation detail. In Barth's e-mail he was talking about code classes - i.e. implementation detail. I deliberately kept my email at the functional level, describing only what the user wants to see - not how it will be achieved in code. The original bug report describes what it is that they want to do. These VectorView objects sound good- I think that they are similar to Rick Chern's suggestion. The trick would be getting them to automatically update with a change in the contents of a plot. The cleanest thing to do seems to be that we would have curves themselves maintain the VectorViews. Curves could have a 'maintain subvectors' option. There's an architectural problem with this, because right now Curves can be placed in multiple plots. Would it be a big deal to change this? Duncan. On 22 Mar 2007 18:18:36 -0000, Andrew Walker <arwalker@sumusltd.com> wrote: [bugs.kde.org quoted mail] Ah, I think that this is the idea of Barth and Eli's #1. We have a three way tie! On 3/22/07, Duncan Hanson <duncan.hanson@gmail.com> wrote: > These VectorView objects sound good- I think that they are similar to > Rick Chern's suggestion. The trick would be getting them to > automatically update with a change in the contents of a plot. > > The cleanest thing to do seems to be that we would have curves > themselves maintain the VectorViews. Curves could have a 'maintain > subvectors' option. > > There's an architectural problem with this, because right now Curves > can be placed in multiple plots. Would it be a big deal to change > this? > > Duncan. > > On 22 Mar 2007 18:18:36 -0000, Andrew Walker <arwalker@sumusltd.com> wrote: > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > > > > http://bugs.kde.org/show_bug.cgi?id=86915 > > > > > > > > > > ------- Additional Comments From arwalker sumusltd com 2007-03-22 19:18 ------- > > I don't see where I discussed implementation detail. > > > > In Barth's e-mail he was talking about code classes - i.e. implementation detail. I deliberately kept my email at the functional level, describing only what the user wants to see - not how it will be achieved in code. > > > > The original bug report describes what it is that they want to do. > > _______________________________________________ > > Kst mailing list > > Kst@kde.org > > https://mail.kde.org/mailman/listinfo/kst > > > SVN commit 645953 by netterfield: CCBUG: 86915 I have commited a partial spec for this feature (competes w/ Andrews...). Please review and comment. A datasubsets.txt Barth's proposal looks good. It inclues several potentially useful options from the user's point of view. What release is this tabled for? The next release (ie, not in 4 days... but as soon as possible after that). I will poke my head up from my real job and try to come up with a proposed list of priorities for 1.5 in the next day or two. cbn On Monday 26 March 2007 1:13:44 pm Andrew Walker wrote: [bugs.kde.org quoted mail] Created attachment 20474 [details]
Screenshot of New/Edit interface for proposed Subcurves.
Seems reasonable. Though should it use checkboxes instead of radio buttons for Use Plot/Use flag vector/Manual. That way the user can exlcude points based on one or more criteria. Andrew -----Original Message----- From: owner@bugs.kde.org [mailto:owner@bugs.kde.org]On Behalf Of Duncan Hanson Sent: May 3, 2007 1:41 PM To: arwalker@sumusltd.com Subject: [Bug 86915] ability to operate only on what is visible shown in plot ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=86915 ------- Additional Comments From duncan.hanson gmail com 2007-05-03 22:41 ------- Created an attachment (id=20474) --> (http://bugs.kde.org/attachment.cgi?id=20474&action=view) Screenshot of New/Edit interface for proposed Subcurves. Hi All, I propose to implement 'Subcurves', which are mainly based on Barth and Eli's suggestions. They require two inputs: a curve, and range information. They produce a clipped version of the curve, using the curve's interpolation rules. The range can be input either as: a pointer to a plot (in which case both X and Y are clipped according to the plot range), a flag vector (which should be the same length as X. only X values corresponding to entries of the flag vector which are non-zero will be used. would it be useful to allow for the possibility of TWO flag vectors, one for X and one for Y?) and a manual range (in which case X and Y can be clipped according the inputs as shown in the attached screenshot, checkboxes are available to disable clipping for Xmax, etc.) Tell me what you think, Duncan. Hi All, I propose to implement 'Subcurves', which are mainly based on Barth and Eli's suggestions. They require two inputs: a curve, and range information. They produce a clipped version of the curve, using the curve's interpolation rules. The range can be input either as: a pointer to a plot (in which case both X and Y are clipped according to the plot range), a flag vector (which should be the same length as X. only X values corresponding to entries of the flag vector which are non-zero will be used. would it be useful to allow for the possibility of TWO flag vectors, one for X and one for Y?) and a manual range (in which case X and Y can be clipped according the inputs as shown in the attached screenshot, checkboxes are available to disable clipping for Xmax, etc.) Tell me what you think, Duncan. That would be useful. Another thing which just occurred to me-> Barth and Eli's original suggestion of taking X and Y vectors as input would work really well if subcurves followed their plots in the update chain. Then, rather than plotting a curve and then making a subcurve based off of it, you could just plot the subcurve, and have it update itself as you change the plot range. On 3 May 2007 20:45:23 -0000, Andrew Walker <arwalker@sumusltd.com> wrote: [bugs.kde.org quoted mail] That would be useful.<br><br>Another thing which just occurred to me-> Barth and Eli's original suggestion of taking X and Y vectors as input would work really well if subcurves followed their plots in the update chain. Then, rather than plotting a curve and then making a subcurve based off of it, you could just plot the subcurve, and have it update itself as you change the plot range. <br><br><div><span class="gmail_quote">On 3 May 2007 20:45:23 -0000, <b class="gmail_sendername">Andrew Walker</b> <<a href="mailto:arwalker@sumusltd.com">arwalker@sumusltd.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ------- You are receiving this mail because: -------<br>You are the assignee for the bug, or are watching the assignee.<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=86915">http://bugs.kde.org/show_bug.cgi?id=86915</a> <br><br><br><br><br>------- Additional Comments From arwalker sumusltd com 2007-05-03 22:45 -------<br>Seems reasonable. Though should it use checkboxes instead of radio buttons<br>for Use Plot/Use flag vector/Manual. That way the user can exlcude points <br>based on one or more criteria.<br><br>Andrew<br><br>-----Original Message-----<br>From: owner bugs kde org [mailto:<a href="mailto:owner">owner</a> bugs kde org]On Behalf Of Duncan<br>Hanson<br>Sent: May 3, 2007 1:41 PM <br>To: arwalker sumusltd com<br>Subject: [Bug 86915] ability to operate only on what is visible shown in<br>plot<br><br><br>------- You are receiving this mail because: -------<br>You are on the CC list for the bug, or are watching someone who is. <br><br><a href="http://bugs.kde.org/show_bug.cgi?id=86915">http://bugs.kde.org/show_bug.cgi?id=86915</a><br><br><br><br><br>------- Additional Comments From duncan.hanson gmail com 2007-05-03 22:41 -------<br>Created an attachment (id=20474) <br> --> (<a href="http://bugs.kde.org/attachment.cgi?id=20474&action=view">http://bugs.kde.org/attachment.cgi?id=20474&action=view</a>)<br> --> (<a href="http://bugs.kde.org/attachment.cgi?id=20474&action=view"> http://bugs.kde.org/attachment.cgi?id=20474&action=view</a>)<br>Screenshot of New/Edit interface for proposed Subcurves.<br></blockquote></div><br> Another possiblity would be in place of xmin, xmax, ymin, ymax, etc. to simply allow the user to enter multiple expressions to exclude data points. e.g. x<0, y>5, x*y>10 The same effect could be achieved but in a more powerful way. That also sounds useful. Right now I guess that you could accomplish the same thing using an event monitor as a Flag Vector. On 3 May 2007 21:27:44 -0000, Andrew Walker <arwalker@sumusltd.com> wrote: [bugs.kde.org quoted mail] That also sounds useful.<br><br>Right now I guess that you could accomplish the same thing using an event monitor as a Flag Vector.<br><br><div><span class="gmail_quote">On 3 May 2007 21:27:44 -0000, <b class="gmail_sendername"> Andrew Walker</b> <<a href="mailto:arwalker@sumusltd.com">arwalker@sumusltd.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ------- You are receiving this mail because: -------<br>You are the assignee for the bug, or are watching the assignee.<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=86915">http://bugs.kde.org/show_bug.cgi?id=86915</a> <br><br><br><br><br>------- Additional Comments From arwalker sumusltd com 2007-05-03 23:27 -------<br>Another possiblity would be in place of xmin, xmax, ymin, ymax, etc. to simply allow the user to enter multiple expressions to exclude data points. <br><br>e.g. x<0, y>5, x*y>10<br><br>The same effect could be achieved but in a more powerful way.<br></blockquote></div><br> Ok, after some more thought: SubCurves inherit from Curves. This way it's straightforward to incorporate SubCurves into the UI (fit context menu, etc)., because they are actually just curves. Their inputs are the same as those for curves (X and Y vectors, interpolation rules, linetype, etc.), with the addition of the Range options in the screenshot. They maintain a pair of vectors which they can fill with the cut data. If manual range information or flag vectors are used, subcurves report Min and Max X/Y values accordingly. If only plot range information is used, they report their range information to be the same as that of their input X/Y vectors. This way, you will be able to zoom and out on a plot of a subvector which takes its range information from the plot which contains it, and still do WYSIWYG things with it. Think it would work? Ok, after some more thought:<br><br>SubCurves inherit from Curves. This way it's straightforward to incorporate SubCurves into the UI (fit context menu, etc)., because they are actually just curves. Their inputs are the same as those for curves (X and Y vectors, interpolation rules, linetype, etc.), with the addition of the Range options in the screenshot. They maintain a pair of vectors which they can fill with the cut data. <br><br>If manual range information or flag vectors are used, subcurves report Min and Max X/Y values accordingly. If only plot range information is used, they report their range information to be the same as that of their input X/Y vectors. This way, you will be able to zoom and out on a plot of a subvector which takes its range information from the plot which contains it, and still do WYSIWYG things with it. <br><br>Think it would work?<br> Could you attach the latest mockup of the subcurve dialog? From what you wrote it seems that the user must create the subcurve explicitly. One usage case for the subcurve is in fitting only the portion of a curve displayed in a plot. For this case the subcurve would be better created implicitly as part of the fitting operation. In the data manager would subcurves be shown as separate entities or as children of their corresponding curves? Would it be possible to create a subcurve of a subcurve? Could a curve be purged only when all its subcurves are deleted, or does purging a curve automatically delete its subcurves? I don't see why you would ever need to interpolate a subcurve. Curves are already interpolated to create matching x-y pairs so subcurves should be constructed of those pairs. Would subcurves also inherit the error bars of the parent curve? ------- Additional Comments From arwalker sumusltd com 2007-05-04 20:56 ------- > Could you attach the latest mockup of the subcurve dialog? Just take the screenshot which was already attached, replace the Curve drop down menu with two Vector drop down menus, and add all of the Appearance and Interpolation options from the current Curve dialog. It might need some trickery to make it look nice ;) From what you wrote it seems that the user must create the subcurve > explicitly. > > One usage case for the subcurve is in fitting only the portion of a curve > displayed in a plot. For this case the subcurve would be better created > implicitly as part of the fitting operation. I was thinking that it would be nice to have some quick way to convert a curve to a subcurve. Actually, if the clutter doesn't bother anyone I would be happy just adding the Range options to current curves. > In the data manager would subcurves be shown as separate entities or as > children of their corresponding curves? Um... in the proposal which I think you are replying to subcurves no longer have parent curves. The cut vectors would be shown as children of the subcurve, if that's what you're thinking of. Would it be possible to create a subcurve of a subcurve? It would be possible to create a subcurve from the cut vectors maintained by a subcurve, so yes. Could a curve be purged only when all its subcurves are deleted, or does > purging a curve automatically delete its subcurves? I think this is a continuation of the misunderstanding in the previous two questions. I don't see why you would ever need to interpolate a subcurve. Curves are > already interpolated to create matching x-y pairs so subcurves should be > constructed of those pairs. " " (above) Would subcurves also inherit the error bars of the parent curve? " " (above). ------- Additional Comments From arwalker sumusltd com 2007-05-04 20:56 -------<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Could you attach the latest mockup of the subcurve dialog? </blockquote><div><br>Just take the screenshot which was already attached, replace the Curve drop down menu with two Vector drop down menus, and add all of the Appearance and Interpolation options from the current Curve dialog. It might need some trickery to make it look nice ;) <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">From what you wrote it seems that the user must create the subcurve explicitly. <br><br>One usage case for the subcurve is in fitting only the portion of a curve displayed in a plot. For this case the subcurve would be better created implicitly as part of the fitting operation.</blockquote><div><br>I was thinking that it would be nice to have some quick way to convert a curve to a subcurve. Actually, if the clutter doesn't bother anyone I would be happy just adding the Range options to current curves. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In the data manager would subcurves be shown as separate entities or as children of their corresponding curves? </blockquote><div><br>Um... in the proposal which I think you are replying to subcurves no longer have parent curves. The cut vectors would be shown as children of the subcurve, if that's what you're thinking of.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Would it be possible to create a subcurve of a subcurve?</blockquote><div><br>It would be possible to create a subcurve from the cut vectors maintained by a subcurve, so yes. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Could a curve be purged only when all its subcurves are deleted, or does purging a curve automatically delete its subcurves? </blockquote><div><br>I think this is a continuation of the misunderstanding in the previous two questions.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I don't see why you would ever need to interpolate a subcurve. Curves are already interpolated to create matching x-y pairs so subcurves should be constructed of those pairs.</blockquote><div><br>" " (above) <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Would subcurves also inherit the error bars of the parent curve?</blockquote><div> <br>" " (above). <br> </div><br></div><br> This is very different from the proposed solution in devel_docs/datasubsets.txt (though very similar to my original idea which Eli talked me out of). Why did you change? Comments on the current plan: -By directly accessing plots, rather than taking scalars from plots, I think you are decreasing the flexibility of the system. -Verify that in the update system, un-plotted curves get updated. Currently they don't need to be (but maybe they are). -It is common to want the sub-vectors for something other than plotting them (eg, fitting, scalars). -It is common to want to make a sub-vector of something which isn't plotted, and only plot the sub-vectors (eg, flagged data). It seems to me that the reason you are merging with curves is to get access to the parent curve's interpolation rules. I think that this is not worth it. I think the user also needs to be able to specify whether the range limited by a plot is in x, y, or both. Also equations would be much more powerful than simply x-min, y-min etc. Those could remain (for ease of use) but expressions would add to the functionality. The same thing could be achieved with events but this adds an unecessary layer of complexity for the user. Under this scheme where vector values are excised based on limits the interpolation scheme will result in potentially dramatic differences between the original curve and the subcurve. It seems to me that the only way to have subcurves reflect the parent curve is to have subcurves based on curves rather than vectors. ------- Additional Comments From netterfield astro utoronto ca 2007-05-04 21:38 ------- > This is very different from the proposed solution in > devel_docs/datasubsets.txt (though very similar to my original idea which > Eli talked me out of). Why did you change? Really? To me, this seems very similar to the datasubsets suggestion. The only major difference is that there is one object rather than separate XView, Yview, XYView, and FlagView objects. The advantage to this is that you can use several criteria for cutting data at the same time. > Comments on the current plan: > -By directly accessing plots, rather than taking scalars from plots, I > think you are decreasing the flexibility of the system. Good point. How about this: make the 'manual' options take scalars as inputs. If even more flexibility is necessary, then I think that it will boil down to the ability to use arbitrary expressions to limit the range. -Verify that in the update system, un-plotted curves get updated. Currently > they don't need to be (but maybe they are). Yes. This should be true. -It is common to want the sub-vectors for something other than plotting them > (eg, fitting, scalars). Yes, this is one of the main requirements. -It is common to want to make a sub-vector of something which isn't plotted, > and only plot the sub-vectors (eg, flagged data). Because these subcurves take vectors as input rather than curves this is fine. > It seems to me that the reason you are merging with curves is to get > access to the parent curve's interpolation rules. I think that this is not > worth it. > Well, the thing that I don't want to have to have to do as a user is: 1) create a curve. 2) create a `subcurve' from it, which contains the data which I'm interested in. 3) creating another curve which plots the vectors of the subcurve. Making subcurves a type of curve is a way to condense these 3 steps into one. It's just as powerful as the other approach, and involves almost no overhead-- so I think that it's worthwhile to do. ------- Additional Comments From netterfield astro utoronto ca 2007-05-04 21:38 -------<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> This is very different from the proposed solution in devel_docs/datasubsets.txt (though very similar to my original idea which Eli talked me out of). Why did you change?</blockquote><div><br>Really? To me, this seems very similar to the datasubsets suggestion. The only major difference is that there is one object rather than separate XView, Yview, XYView, and FlagView objects. The advantage to this is that you can use several criteria for cutting data at the same time. <br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Comments on the current plan:<br>-By directly accessing plots, rather than taking scalars from plots, I think you are decreasing the flexibility of the system. </blockquote><div><br>Good point. How about this: make the 'manual' options take scalars as inputs. <br>If even more flexibility is necessary, then I think that it will boil down to the ability to use arbitrary expressions to limit the range. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-Verify that in the update system, un-plotted curves get updated. Currently they don't need to be (but maybe they are). </blockquote><div> Yes. This should be true. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-It is common to want the sub-vectors for something other than plotting them (eg, fitting, scalars). </blockquote><div>Yes, this is one of the main requirements.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-It is common to want to make a sub-vector of something which isn't plotted, and only plot the sub-vectors (eg, flagged data). </blockquote><div>Because these subcurves take vectors as input rather than curves this is fine.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It seems to me that the reason you are merging with curves is to get access to the parent curve's interpolation rules. I think that this is not worth it.<br></blockquote></div>Well, the thing that I don't want to have to have to do as a user is: 1) create a curve. 2) create a `subcurve' from it, which contains the data which I'm interested in. 3) creating another curve which plots the vectors of the subcurve. <br><br>Making subcurves a type of curve is a way to condense these 3 steps into one. It's just as powerful as the other approach, and involves almost no overhead-- so I think that it's worthwhile to do.<br> > ------- Additional Comments From arwalker sumusltd com 2007-05-04 21:40 > ------- > I think the user also needs to be able to specify whether the range > limited by a plot is in x, y, or both. Ok. This should be easy to accomplish if we have plots export scalars, and have the manual options for Xmin, Xmax, etc. use scalars rather than Also equations would be much more powerful than simply x-min, y-min etc. > Those could remain (for ease of use) but expressions would add to the > functionality. The same thing could be achieved with events but this adds an > unecessary layer of complexity for the user. Yes, expressions are a powerful way to do things. BUT, they will generally be much slower SO I am thinking that we will still need to have the Manual, Plot, and Flag vector options as fast alternatives THEREFORE I suggest that we implement these range options first, and add general expressions later as a 4th option if requested. Under this scheme where vector values are excised based on limits the > interpolation scheme will result in potentially dramatic differences between > the original curve and the subcurve. It seems to me that the only way to > have subcurves reflect the parent curve is to have subcurves based on curves > rather than vectors. What is this 'original curve'? <br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">------- Additional Comments From arwalker sumusltd com 2007-05-04 21:40 -------<br> I think the user also needs to be able to specify whether the range limited by a plot is in x, y, or both.</blockquote><div><br>Ok. This should be easy to accomplish if we have plots export scalars, and have the manual options for Xmin, Xmax, etc. use scalars rather than </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also equations would be much more powerful than simply x-min, y-min etc. Those could remain (for ease of use) but expressions would add to the functionality. The same thing could be achieved with events but this adds an unecessary layer of complexity for the user. </blockquote><div>Yes, expressions are a powerful way to do things. BUT, they will generally be much slower SO I am thinking that we will still need to have the Manual, Plot, and Flag vector options as fast alternatives THEREFORE I suggest that we implement these range options first, and add general expressions later as a 4th option if requested. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Under this scheme where vector values are excised based on limits the interpolation scheme will result in potentially dramatic differences between the original curve and the subcurve. It seems to me that the only way to have subcurves reflect the parent curve is to have subcurves based on curves rather than vectors. </blockquote><div><br></div></div>What is this 'original curve'?<br> Here is the list of things which we would like to be able to do using Subcurves/KstViews/whatever.
-Operate only on what is visible in a plot.
--This should primarily be WYSIWYG, so the data which is operated on is interpolated the same as the curve which is displayed.
--It should be possible for the results to update automatically as we zoom in and out on the plot (example: labelling a plot with the statistics of the data which you're currently looking at).
--This should be just as easy as operating on a curve (example: performing a fit from the fit/filter context menu.)
-Cut data with a flag vector (example: masking out bad points.)
-Cut the data range with a scalar. (example: fitting a 1/f power spectrum for a knee frequency, and then plotting the region below or above the knee.)
-Possibly, cutting the data range with an expression.
My proposal for now is that we make a new class KstSubCurve, which inherits directly from KstVCurve. The difference between KstSubCurve and KstVCurve is that:
-KstSubCurve has additional range options in its edit/new dialogs, which are shown in the latest mockup (SubMockup#2, attached).
-If the range options are selected and the X/Y data must be cut KstSubCurve will output child vectors which it will fill with the cut data.
Some details:
--If it has created child vectors, KstSubCurve will report the children as its vectors, rather than the originals, so that if you select a KstSubCurve from the fit context menu, the fit will be performed on the child vectors.
--If scalars are used as range options, KstSubCurve will adjust its reported X/Y Max/Min values accordingly. It will not make any adjustments based on cutting due to Plot Range, however. This way, if you're plotting a subcurve and basing its range on the plot which contains it, it will be possible to zoom out ;).
--If you select the Plot range option, and no scalars are being used for the range, then the plot ranges will be penciled in to the scalar range entry boxes. This way, if you don't want your range automatically updated, you can just deselect the plot option and enable the scalar ones.
So-- why curves instead of KstViews? Well, it is:
1) Easy to plot and perform operations on subcurves-> doesn't require creating a separate curve to show your cut data, as with KstViews, and doesn't require any changes to the Fit/Filter context menus, whereas with KstViews I think that we would need to have new FitSubset type entries.
2) Easy to keep the interpolation rules of subcurves up to date with those used in a plot (because subcurves are what you're plotting in the first place!)
What would be a pain about SubCurves? Well, we have to invent a good interface for converting KstVCurves to KstSubCurves, as KstVCurves are the default curve type created by the data wizard, equations, etc. A new entry in the data manager context menu would probably work, ALTHOUGH I think it would be better to just shove the KstSubCurve functinality into KstVCurves. If I implement SubCurves, the idea would be that SubCurves are a proof-of-concept. Then, if everyone is happy, we can add the SubCurve functionality to Curves themselves. We could have the Range options appear in the curve dialog widget under something like a GTK+ expander triangle.
Barth, this is all basically a rewriting of your #1, as you pointed out. Can you tell me what the arguments which say that they are a bad idea? Maybe I'm missing something, but it seems like a good way of doing things.
Duncan.
Created attachment 20495 [details]
SubMockup#2
This makes sense to me. There are a couple of things that should be kept in mind: 1) there should be a very simple way for people to fit an existing curve and have a fit created which automatically uses the plot range as the cut 2) when cutting the cut would have to be done on the already interpolated data so that the x,y pairing post-cut is the same as for the x,y pairing pre-cut - for those pairs that survive the cut. Implementing as a proof of concept in a separate class with a view of merging it all into KstVCurve also makes sense. Barth, anything big that I've missed? If not then I will start to implement this plan. Barth, anything big that I've missed? If not then I will start to implement this plan.<br> In ancient times, all data objects (psds, equations, histograms) inherited from KstCurve. This turned out to be awkward: -Particularly: line and drawing attributes always associated with the data objects, even w/ no intention to draw them. This messed up the UI (eg, edit an equation you are not directly plotting, to find line type attributes...). Things have been cleaner and more obvious since we move away from that model to the data objects != curves, particularly with the invention of X and Y slavevectors . The Views fit perfectly into the existing structure (it could even be a plugin) like any other data object, and this is the most 'the kst way' of implementing them. For the most part, the UI could be identical. Ok, I understand. What you're saying is that it's not absolutely necessary for subcurves to be curves, and we want to avoid the possibility that this approach will become cumbersome in the future. I still feel that it is reasonable to tie curves to subcurves/kstviews. data objects != curves, but subcurves don't quite equal data objects either. That's fine though, you surely have a better intuition for this than I do, so I will implement KstVectorViews. I won't implement separate X, Y, Flag, XY views because, as Andrew pointed out, it's more powerful to be able to do all 4 at once. I will probably use the "Let KstVectorView interpolate" approach for uneven vectors. Duncan. On 8 May 2007 01:08:46 -0000, netterfield@astro.utoronto.ca <netterfield@astro.utoronto.ca> wrote: [bugs.kde.org quoted mail] I'm going to try to get over the problem of DataObjects not begin allowed to know about plots by having 2DPlots export scalars. The alternative is to have KstApp act as an intermediary. Both solutions seem kind of silly. I'm going to try to get over the problem of DataObjects not begin allowed to know about plots by having 2DPlots export scalars. The alternative is to have KstApp act as an intermediary.<br><br>Both solutions seem kind of silly. <br> Sounds reasonable - what happens if the user changse the name of a plot that is being used to give the limits in a subcurve/KstVectorView? I hope to maintain pointers to the scalars in the VectorView, so nothing will stop working immediately. Then, I hope it's possible to extract the plot tag from one of the scalars when if the edit dialog is called. If none of this works, then I'll just write things so that there is no crash. Such are the penalties of this architecture? SVN commit 663060 by dhanson:
CCBUG:86915 give plots scalar outputs.
M +59 -1 kst2dplot.cpp
M +14 -1 kst2dplot.h
--- branches/work/kst/1.5/kst/src/libkstapp/kst2dplot.cpp #663059:663060
@@ -653,7 +653,7 @@
_i_per = 0;
- setTagName(KstObjectTag(in_tag, KstObjectTag::globalTagContext)); // FIXME: tag context
+ KstObject::setTagName(KstObjectTag(in_tag, KstObjectTag::globalTagContext)); // FIXME: tag context
_isTied = false;
XMin = xmin_in;
@@ -692,6 +692,8 @@
// let this Kst2DPlot register doc changes.
connect(this, SIGNAL(modified()), KstApp::inst(), SLOT(registerDocChange()));
+
+ CreateScalars();
}
@@ -711,6 +713,15 @@
_curveToMarkers = 0L;
_vectorToMarkers = 0L;
+
+ KST::scalarList.lock().writeLock();
+ KST::scalarList.setUpdateDisplayTags(false);
+ for (QDictIterator<KstScalar> it(_scalars); it.current(); ++it) {
+ KST::scalarList.remove(it.current());
+ it.current()->_KShared_unref();
+ }
+ KST::scalarList.setUpdateDisplayTags(true);
+ KST::scalarList.lock().unlock();
}
@@ -1402,6 +1413,8 @@
kstdWarning() << "Bug in Kst2DPlot::updateScale: bad scale mode" << endl;
break;
}
+
+ updateScalears();
}
@@ -7063,6 +7076,51 @@
}
+void Kst2DPlot::CreateScalars() {
+ KstWriteLocker sl(&KST::scalarList.lock());
+ KST::scalarList.setUpdateDisplayTags(false);
+
+ KstScalarPtr sp;
+ _scalars.insert("xmin", sp = new KstScalar(KstObjectTag("XMin", tag()), this));
+ sp->_KShared_ref();
+ _scalars.insert("xmax", sp = new KstScalar(KstObjectTag("XMax", tag()), this));
+ sp->_KShared_ref();
+ _scalars.insert("ymin", sp = new KstScalar(KstObjectTag("YMin", tag()), this));
+ sp->_KShared_ref();
+ _scalars.insert("ymax", sp = new KstScalar(KstObjectTag("YMax", tag()), this));
+ sp->_KShared_ref();
+
+ KST::scalarList.setUpdateDisplayTags(true);
+}
+
+void Kst2DPlot::RenameScalars() {
+ KstWriteLocker sl(&KST::scalarList.lock());
+ KST::scalarList.setUpdateDisplayTags(false);
+
+ _scalars["xmax"]->setTagName(KstObjectTag("XMax", tag()));
+ _scalars["xmin"]->setTagName(KstObjectTag("XMin", tag()));
+ _scalars["ymax"]->setTagName(KstObjectTag("YMax", tag()));
+ _scalars["ymin"]->setTagName(KstObjectTag("YMin", tag()));
+
+ KST::scalarList.setUpdateDisplayTags(true);
+}
+
+void Kst2DPlot::updateScalears() {
+ _scalars["xmax"]->setValue(XMax);
+ _scalars["xmin"]->setValue(XMin);
+ _scalars["ymax"]->setValue(YMax);
+ _scalars["ymin"]->setValue(YMin);
+}
+
+void Kst2DPlot::setTagName(const KstObjectTag& newTag) {
+ if (newTag == tag()) {
+ return;
+ }
+
+ this->KstObject::setTagName(newTag);
+ RenameScalars();
+}
+
QWidget *Kst2DPlot::configWidget() {
return new View2DPlotWidget;
}
--- branches/work/kst/1.5/kst/src/libkstapp/kst2dplot.h #663059:663060
@@ -28,6 +28,7 @@
#include "kstviewwidget.h"
#include "kstviewlegend.h"
#include "kst_export.h"
+#include "kstscalar.h"
#include <qvaluestack.h>
@@ -139,6 +140,8 @@
void pushPlotColors();
void popPlotColors();
+ void updateScalears();
+
/** Set the scale */
void setScale(double xmin, double ymin, double xmax, double ymax);
/** Set the X scale */
@@ -383,9 +386,19 @@
double verticalSizeFactor();
double horizontalSizeFactor();
-
+
+ virtual void setTagName(const KstObjectTag& newTag);
+
+protected:
+ QDict<KstScalar> _scalars;
+
+ /** Scalar Maintenance methods */
+ void CreateScalars();
+ void RenameScalars();
+
signals:
void modified();
+ void scaleChanged();
public slots:
void copy();
SVN commit 663065 by dhanson: CCBUG:86915 restrict modifications of X/YMin/Max to the set*Scale functions, so our scalars will always update when we expect them to. M +210 -158 kst2dplot.cpp SVN commit 665126 by dhanson:
CCBUG:86915 set plots' scalar outputs to be orphans-> so they are saved in the kst file and will always be available to objects when kst starts up.
M +24 -4 kst2dplot.cpp
M +1 -1 kst2dplot.h
--- branches/work/kst/1.5/kst/src/libkstapp/kst2dplot.cpp #665125:665126
@@ -7133,14 +7133,30 @@
KST::scalarList.setUpdateDisplayTags(false);
KstScalarPtr sp;
- _scalars.insert("xmin", sp = new KstScalar(KstObjectTag("XMin", tag()), this));
+
+ sp = *KST::scalarList.findTag(KstObjectTag("XMin", tag()));
+ if (!sp) { sp = new KstScalar(KstObjectTag("XMin", tag()), this); }
+ _scalars.insert("xmin", sp);
sp->_KShared_ref();
- _scalars.insert("xmax", sp = new KstScalar(KstObjectTag("XMax", tag()), this));
+ sp->setOrphan(true); //seems kind of funny, but is req'd for the scalar to be saved. this should be done so that these scalars are be produced before vectorviews (and other objects which might want to use them) when a .kst session is recreated.
+
+ sp = *KST::scalarList.findTag(KstObjectTag("XMax", tag()));
+ if (!sp) { sp = new KstScalar(KstObjectTag("XMax", tag()), this); }
+ _scalars.insert("xmax", sp);
sp->_KShared_ref();
- _scalars.insert("ymin", sp = new KstScalar(KstObjectTag("YMin", tag()), this));
+ sp->setOrphan(true);
+
+ sp = *KST::scalarList.findTag(KstObjectTag("YMin", tag()));
+ if (!sp) { sp = new KstScalar(KstObjectTag("YMin", tag()), this); }
+ _scalars.insert("ymin", sp);
sp->_KShared_ref();
- _scalars.insert("ymax", sp = new KstScalar(KstObjectTag("YMax", tag()), this));
+ sp->setOrphan(true);
+
+ sp = *KST::scalarList.findTag(KstObjectTag("YMax", tag()));
+ if (!sp) { sp = new KstScalar(KstObjectTag("YMax", tag()), this); }
+ _scalars.insert("ymax", sp);
sp->_KShared_ref();
+ sp->setOrphan(true);
KST::scalarList.setUpdateDisplayTags(true);
}
@@ -7173,6 +7189,10 @@
RenameScalars();
}
+const QDict<KstScalar>& Kst2DPlot::scalars() const {
+ return _scalars;
+}
+
QWidget *Kst2DPlot::configWidget() {
return new View2DPlotWidget;
}
--- branches/work/kst/1.5/kst/src/libkstapp/kst2dplot.h #665125:665126
@@ -141,6 +141,7 @@
void popPlotColors();
void updateScalears();
+ const QDict<KstScalar>& scalars() const;
/** Set the scale */
void setScale(double xmin, double ymin, double xmax, double ymax);
@@ -398,7 +399,6 @@
signals:
void modified();
- void scaleChanged();
public slots:
void copy();
SVN commit 665128 by dhanson:
CCBUG:86915 first draft of KstVectorView. Currently, scalars are connected to the VectorView via signals. I'd like to just check them in the update loop, but this doesn't seem to work right now.
M +2 -0 libkstapp/Makefile.am
M +9 -0 libkstapp/dialoglauncher-gui.cpp
M +2 -0 libkstapp/dialoglauncher-gui.h
M +5 -0 libkstapp/kst.cpp
M +2 -0 libkstapp/kst.h
M +2 -0 libkstapp/kstdatamanager_i.cpp
M +5 -0 libkstapp/kstdoc.cpp
A libkstapp/kstvvdialog_i.cpp [License: GPL (v2+)]
A libkstapp/kstvvdialog_i.h [License: GPL (v2+)]
A libkstapp/vectorviewdialogwidget.ui
M +2 -1 libkstmath/Makefile.am
M +4 -0 libkstmath/dialoglauncher.cpp
M +2 -0 libkstmath/dialoglauncher.h
M +6 -0 libkstmath/kstdefaultnames.cpp
M +1 -0 libkstmath/kstdefaultnames.h
A libkstmath/kstvectorview.cpp [License: GPL (v2+)]
A libkstmath/kstvectorview.h [License: GPL (v2+)]
M +2 -1 widgets/scalarselector.ui
M +28 -3 widgets/scalarselector.ui.h
--- branches/work/kst/1.5/kst/src/libkstapp/Makefile.am #665127:665128
@@ -21,6 +21,7 @@
imagedialogwidget.ui \
matrixdialogwidget.ui \
plugindialogwidget.ui \
+ vectorviewdialogwidget.ui \
basicdialogwidget.ui \
eventmonitorwidget.ui \
pluginmanager.ui \
@@ -81,6 +82,7 @@
kstpsddialog_i.cpp \
kstgraphfiledialog_i.cpp \
kstimagedialog_i.cpp \
+ kstvvdialog_i.cpp \
kstquickstartdialog_i.cpp \
updatethread.cpp \
emailthread.cpp \
--- branches/work/kst/1.5/kst/src/libkstapp/dialoglauncher-gui.cpp #665127:665128
@@ -25,6 +25,7 @@
#include "kstplugindialog_i.h"
#include "kstbasicdialog_i.h"
#include "kstpsddialog_i.h"
+#include "kstvvdialog_i.h"
#include "kstvectordialog_i.h"
@@ -90,7 +91,15 @@
}
}
+void KstGuiDialogs::showVectorViewDialog(const QString& name, bool edit) {
+ if (!edit) {
+ KstVvDialogI::globalInstance()->showNew(name);
+ } else {
+ KstVvDialogI::globalInstance()->showEdit(name);
+ }
+}
+
void KstGuiDialogs::newVectorDialog(QWidget *parent, const char *createdSlot, const char *selectedSlot, const char *updateSlot) {
KstVectorDialogI *ad = new KstVectorDialogI(parent, "vector dialog");
if (createdSlot) {
--- branches/work/kst/1.5/kst/src/libkstapp/dialoglauncher-gui.h #665127:665128
@@ -36,6 +36,8 @@
void showPSDDialog(const QString& name = QString::null, bool edit = false);
+ void showVectorViewDialog(const QString& name = QString::null, bool edit = false);
+
void newMatrixDialog(QWidget *parent, const char *createdSlot = 0L, const char *selectedSlot = 0L, const char *updateSlot = 0L);
void showMatrixDialog(const QString& name = QString::null, bool edit = false);
--- branches/work/kst/1.5/kst/src/libkstapp/kst.cpp #665127:665128
@@ -67,6 +67,7 @@
#include "kstfilterdialog_i.h"
#include "kstgraphfiledialog_i.h"
#include "ksthsdialog_i.h"
+#include "kstvvdialog_i.h"
#include "kstiface_impl.h"
#include "kstimagedialog_i.h"
#include "kstlegenddefaults.h"
@@ -2113,6 +2114,9 @@
if (!onlyVisible || KstHsDialogI::globalInstance()->isShown()) {
KstHsDialogI::globalInstance()->update();
}
+ if (!onlyVisible || KstVvDialogI::globalInstance()->isShown()) {
+ KstVvDialogI::globalInstance()->update();
+ }
if (!onlyVisible || KstPsdDialogI::globalInstance()->isShown()) {
KstPsdDialogI::globalInstance()->update();
}
@@ -2161,6 +2165,7 @@
KstCsdDialogI::globalInstance()->updateWindow();
KstEqDialogI::globalInstance()->updateWindow();
KstHsDialogI::globalInstance()->updateWindow();
+ KstVvDialogI::globalInstance()->updateWindow();
KstPsdDialogI::globalInstance()->updateWindow();
KstCurveDialogI::globalInstance()->updateWindow();
KstImageDialogI::globalInstance()->updateWindow();
--- branches/work/kst/1.5/kst/src/libkstapp/kst.h #665127:665128
@@ -502,6 +502,8 @@
KAction *EqDialogAction;
/* Histogram Edit Action */
KAction *HsDialogAction;
+ /* VectorView Edit Action */
+ KAction *VvDialogAction;
/* Spectrum Edit Action */
KAction *PsdDialogAction;
/* Data Manager Action */
--- branches/work/kst/1.5/kst/src/libkstapp/kstdatamanager_i.cpp #665127:665128
@@ -54,6 +54,7 @@
#include "kstplugindialog_i.h"
#include "kstpsddialog_i.h"
#include "kstvectordialog_i.h"
+#include "kstvvdialog_i.h"
#include "kstviewwindow.h"
#include "matrixselector.h"
#include "vectorselector.h"
@@ -669,6 +670,7 @@
createObjectAction(i18n("Event Monitor"), _data, KstEventMonitorI::globalInstance(), SLOT(show()));
createObjectAction(i18n("Image"), _data, KstImageDialogI::globalInstance(), SLOT(show()));
createObjectAction(i18n("Spectrogram"), _data, KstCsdDialogI::globalInstance(), SLOT(show()));
+ createObjectAction(i18n("VectorView"), _data, KstVvDialogI::globalInstance(), SLOT(show()));
//Create plugin actions...
setupPluginActions();
--- branches/work/kst/1.5/kst/src/libkstapp/kstdoc.cpp #665127:665128
@@ -54,6 +54,7 @@
#include "kstgraphfiledialog_i.h"
#include "kstequation.h"
#include "ksteventmonitorentry.h"
+#include "kstvectorview.h"
#include "ksthistogram.h"
#include "kstimage.h"
#include "kstmatrixdefaults.h"
@@ -441,6 +442,10 @@
KstDataObjectPtr p = new KstCSD(e);
KstWriteLocker dowl(&KST::dataObjectList.lock());
KST::dataObjectList.append(p);
+ } else if (e.tagName() == "vectorview") {
+ KstDataObjectPtr p = new KstVectorView(e);
+ KstWriteLocker dowl(&KST::dataObjectList.lock());
+ KST::dataObjectList.append(p);
} else if (e.tagName() == "histogram") {
KstDataObjectPtr p = new KstHistogram(e);
KstWriteLocker dowl(&KST::dataObjectList.lock());
--- branches/work/kst/1.5/kst/src/libkstmath/Makefile.am #665127:665128
@@ -38,7 +38,8 @@
eparse-eh.cpp \
eparse.c \
psdcalculator.cpp \
- escan.c
+ escan.c \
+ kstvectorview.cpp
libkstmath_la_LDFLAGS = -version-info @KST_LIBKST_VERSION@ $(all_libraries) -no-undefined
libkstmath_la_LIBADD = $(LIB_KDECORE) ../libkst/libkst.la
--- branches/work/kst/1.5/kst/src/libkstmath/dialoglauncher.cpp #665127:665128
@@ -78,6 +78,10 @@
Q_UNUSED(edit)
}
+void KstDialogs::showVectorViewDialog(const QString& name, bool edit) {
+ Q_UNUSED(name)
+ Q_UNUSED(edit)
+}
void KstDialogs::newVectorDialog(QWidget *parent, const char *createdSlot, const char *selectedSlot, const char *updateSlot) {
Q_UNUSED(parent)
--- branches/work/kst/1.5/kst/src/libkstmath/dialoglauncher.h #665127:665128
@@ -53,6 +53,8 @@
virtual void showCurveDialog(const QString& name = QString::null, bool edit = false);
+ virtual void showVectorViewDialog(const QString& name = QString::null, bool edit = false);
+
virtual void newVectorDialog(QWidget *parent, const char *createdSlot = 0L, const char *selectedSlot = 0L, const char *updateSlot = 0L);
virtual void showVectorDialog(const QString& name = QString::null, bool edit = false);
};
--- branches/work/kst/1.5/kst/src/libkstmath/kstdefaultnames.cpp #665127:665128
@@ -93,7 +93,13 @@
true);
}
+QString KST::suggestVectorViewName( KstObjectTag vector_name ) {
+ return suggestDataObjectName(vector_name.tag(),
+ i18n("Minimal abbreviation for 'VectorView'", "V"),
+ true);
+}
+
QString KST::suggestEQName(const QString& name_in) {
return suggestDataObjectName(name_in,
i18n("Minimal abbreviation for 'Equation'", "E"),
--- branches/work/kst/1.5/kst/src/libkstmath/kstdefaultnames.h #665127:665128
@@ -29,6 +29,7 @@
extern KST_EXPORT QString suggestCSDName(KstObjectTag vector_name);
extern KST_EXPORT QString suggestEQName(const QString& name_in);
extern KST_EXPORT QString suggestHistogramName(KstObjectTag vector_name);
+ extern KST_EXPORT QString suggestVectorViewName(KstObjectTag vector_name);
extern KST_EXPORT QString suggestPluginName(const QString& pname, KstObjectTag vname = KstObjectTag::invalidTag);
extern KST_EXPORT QString suggestImageName(KstObjectTag matrix_name);
}
--- branches/work/kst/1.5/kst/src/widgets/scalarselector.ui #665127:665128
@@ -1,4 +1,4 @@
-<!DOCTYPE UI><UI version="3.2" stdsetdef="1">
+<!DOCTYPE UI><UI version="3.3" stdsetdef="1">
<class>ScalarSelector</class>
<widget class="QWidget">
<property name="name">
@@ -132,6 +132,7 @@
<functions>
<function access="private">init()</function>
<function returnType="QString">selectedScalar()</function>
+ <function returnType="KstScalarPtr">selectedScalarPtr()</function>
</functions>
<exportmacro>KST_EXPORT</exportmacro>
<layoutdefaults spacing="6" margin="11"/>
--- branches/work/kst/1.5/kst/src/widgets/scalarselector.ui.h #665127:665128
@@ -143,7 +143,7 @@
setSelection(p);
} else {
p = new KstScalar(KstObjectTag(se->_name->text(), KstObjectTag::globalTagContext), 0L, val);
-
+
p->setOrphan(true);
p->setEditable(true);
emit newScalarCreated();
@@ -193,12 +193,37 @@
QString ScalarSelector::selectedScalar()
{
KstScalarPtr ptr = *KST::scalarList.findTag(_scalar->currentText());
- if (ptr)
+ if (ptr) {
return _scalar->currentText();
- else
+ } else {
return QString::null;
+ }
}
+KstScalarPtr ScalarSelector::selectedScalarPtr()
+//returns a pointer to the selected scalar.
+//if the scalar does not exist, but
+ //the text entered is a number and
+ //the selector is editable then
+//a new scalar is created with the given value and returned.
+{
+ KstScalarPtr ptr = *KST::scalarList.findTag(_scalar->currentText());
+
+ if (!ptr) {
+ if (_scalar->editable()) {
+ KstWriteLocker sl(&KST::scalarList.lock());
+ bool ok;
+ double val = _scalar->currentText().toDouble(&ok);
+
+ if (ok) {
+ ptr = new KstScalar(KstObjectTag::fromString(_scalar->currentText()), 0L, val, true, false);
+ }
+ }
+ }
+
+ return ptr;
+}
+
void ScalarSelector::allowDirectEntry( bool allowed )
{
_scalar->setEditable(allowed);
SVN commit 665371 by dhanson: CCBUG:86915 xmin/xmax and ymin/ymax now aligned horizontally, proper tab order. M +148 -84 vectorviewdialogwidget.ui SVN commit 665381 by dhanson:
CCBUG:86915 implement the axes options.
M +28 -20 libkstapp/kstvvdialog_i.cpp
M +0 -3 libkstmath/kstvectorview.h
--- branches/work/kst/1.5/kst/src/libkstapp/kstvvdialog_i.cpp #665380:665381
@@ -438,17 +438,21 @@
void KstVvDialogI::realtimeClicked() {
Kst2DPlotPtr plot = Kst2DPlot::findPlotByName(_w->_plotList->currentText());
- _w->_xMinCheckbox->setChecked(true);
- _w->_xMinScalar->setSelection((plot->scalars())["xmin"]->tag().displayString());
+ if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "X Axis") {
+ _w->_xMinCheckbox->setChecked(true);
+ _w->_xMinScalar->setSelection((plot->scalars())["xmin"]->tag().displayString());
- _w->_xMaxCheckbox->setChecked(true);
- _w->_xMaxScalar->setSelection((plot->scalars())["xmax"]->tag().displayString());
+ _w->_xMaxCheckbox->setChecked(true);
+ _w->_xMaxScalar->setSelection((plot->scalars())["xmax"]->tag().displayString());
+ }
- _w->_yMinCheckbox->setChecked(true);
- _w->_yMinScalar->setSelection((plot->scalars())["ymin"]->tag().displayString());
+ if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "Y Axis") {
+ _w->_yMinCheckbox->setChecked(true);
+ _w->_yMinScalar->setSelection((plot->scalars())["ymin"]->tag().displayString());
- _w->_yMaxCheckbox->setChecked(true);
- _w->_yMaxScalar->setSelection((plot->scalars())["ymax"]->tag().displayString());
+ _w->_yMaxCheckbox->setChecked(true);
+ _w->_yMaxScalar->setSelection((plot->scalars())["ymax"]->tag().displayString());
+ }
updateButtons();
}
@@ -459,21 +463,25 @@
KstScalarPtr sp;
double v;
- _w->_xMinCheckbox->setChecked(true);
- v = (plot->scalars())["xmin"]->value();
- _w->_xMinScalar->setSelection(QString::number(v));
+ if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "X Axis") {
+ _w->_xMinCheckbox->setChecked(true);
+ v = (plot->scalars())["xmin"]->value();
+ _w->_xMinScalar->setSelection(QString::number(v));
- _w->_xMaxCheckbox->setChecked(true);
- v = (plot->scalars())["xmax"]->value();
- _w->_xMaxScalar->setSelection(QString::number(v));
+ _w->_xMaxCheckbox->setChecked(true);
+ v = (plot->scalars())["xmax"]->value();
+ _w->_xMaxScalar->setSelection(QString::number(v));
+ }
- _w->_yMinCheckbox->setChecked(true);
- v = (plot->scalars())["ymin"]->value();
- _w->_yMinScalar->setSelection(QString::number(v));
+ if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "Y Axis") {
+ _w->_yMinCheckbox->setChecked(true);
+ v = (plot->scalars())["ymin"]->value();
+ _w->_yMinScalar->setSelection(QString::number(v));
- _w->_yMaxCheckbox->setChecked(true);
- v = (plot->scalars())["ymax"]->value();
- _w->_yMaxScalar->setSelection(QString::number(v));
+ _w->_yMaxCheckbox->setChecked(true);
+ v = (plot->scalars())["ymax"]->value();
+ _w->_yMaxScalar->setSelection(QString::number(v));
+ }
updateButtons();
}
--- branches/work/kst/1.5/kst/src/libkstmath/kstvectorview.h #665380:665381
@@ -32,9 +32,6 @@
// InterpType order must match the order of entries of _interp in
// vectorviewdialogwidget.ui
enum InterpType {InterpY=0, InterpX=1, InterpMax=2, InterpMin=3};
- // AxesType order must match the order of entries of _plotAxes in
- // vectorviewdialogwidget.ui
- enum AxesType {XYAxes=0, XAxis=1, YAxis=2};
KstVectorView(const QString &in_tag, KstVectorPtr in_X, KstVectorPtr in_Y,
KstVectorView::InterpType itype,
SVN commit 665388 by dhanson:
CCBUG:86915 disconnect scalars from the vector view if they're not being used. would still like to put scalars in the output loop...
M +52 -16 kstvectorview.cpp
M +4 -4 kstvectorview.h
--- branches/work/kst/1.5/kst/src/libkstmath/kstvectorview.cpp #665387:665388
@@ -313,37 +313,73 @@
}
void KstVectorView::setXminScalar(KstScalarPtr xmin) {
- disconnect( _xmin, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
- _xmin = xmin;
- if (xmin) {
- connect( xmin, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ if (xmin != _xmin) {
+ disconnect( _xmin, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
+ _xmin = xmin;
+ if (xmin && _useXmin) {
+ connect( xmin, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ }
}
}
void KstVectorView::setXmaxScalar(KstScalarPtr xmax) {
- disconnect( _xmax, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
- _xmax = xmax;
- if (xmax) {
- connect( xmax, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ if (xmax != _xmax) {
+ disconnect( _xmax, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
+ _xmax = xmax;
+ if (xmax && _useXmax) {
+ connect( xmax, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ }
}
}
void KstVectorView::setYminScalar(KstScalarPtr ymin) {
- disconnect( _ymin, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
- _ymin = ymin;
- if (ymin) {
- connect( ymin, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ if (ymin != _ymin) {
+ disconnect( _ymin, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
+ _ymin = ymin;
+ if (ymin && _useYmin) {
+ connect( ymin, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ }
}
}
void KstVectorView::setYmaxScalar(KstScalarPtr ymax) {
- disconnect( _ymax, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
- _ymax = ymax;
- if (ymax) {
- connect( ymax, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ if (ymax != _ymax) {
+ disconnect( _ymax, SIGNAL(trigger()), this, SLOT(scalarChanged())); //should be fine even w/ null arguments.
+ _ymax = ymax;
+ if (ymax && _useYmax) {
+ connect( ymax, SIGNAL(trigger()), this, SLOT(scalarChanged()));
+ }
}
}
+void KstVectorView::setUseXmin(bool useXmin) {
+ _useXmin = useXmin;
+
+ if (!_useXmin) { disconnect( _xmin, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+ if (_useXmin && _xmin) { connect( _xmin, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+}
+
+void KstVectorView::setUseXmax(bool useXmax) {
+ _useXmax = useXmax;
+
+ if (!_useXmax) { disconnect( _xmax, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+ if (_useXmax && _xmax) { connect( _xmax, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+}
+
+void KstVectorView::setUseYmin(bool useYmin) {
+ _useYmin = useYmin;
+
+ if (!_useYmin) { disconnect( _ymin, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+ if (_useYmin && _ymin) { connect( _ymin, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+}
+
+void KstVectorView::setUseYmax(bool useYmax) {
+ _useYmax = useYmax;
+
+ if (!_useYmax) { disconnect( _ymax, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+ if (_useYmax && _ymax) { connect( _ymax, SIGNAL(trigger()), this, SLOT(scalarChanged())); }
+}
+
void KstVectorView::setXVector(KstVectorPtr new_v) {
_inputVectors[IN_XVECTOR] = new_v;
}
--- branches/work/kst/1.5/kst/src/libkstmath/kstvectorview.h #665387:665388
@@ -54,10 +54,10 @@
void setYminScalar(KstScalarPtr ymin);
void setYmaxScalar(KstScalarPtr ymax);
- void setUseXmin(bool useXmin) { _useXmin = useXmin; }
- void setUseXmax(bool useXmax) { _useXmax = useXmax; }
- void setUseYmin(bool useYmin) { _useYmin = useYmin; }
- void setUseYmax(bool useYmax) { _useYmax = useYmax; }
+ void setUseXmin(bool useXmin);
+ void setUseXmax(bool useXmax);
+ void setUseYmin(bool useYmin);
+ void setUseYmax(bool useYmax);
KstScalarPtr xMinScalar() {return _xmin;}
KstScalarPtr xMaxScalar() {return _xmax;}
SVN commit 665431 by dhanson:
CCBUG:86915 if the vectorview scalars are removed from the global list, we place their current values into the scalar selector combobox.
M +37 -4 libkstapp/kstvvdialog_i.cpp
M +6 -1 widgets/scalarselector.ui.h
--- branches/work/kst/1.5/kst/src/libkstapp/kstvvdialog_i.cpp #665430:665431
@@ -137,11 +137,44 @@
_w->_yMinCheckbox->setChecked(vp->useYmin());
_w->_yMaxCheckbox->setChecked(vp->useYmax());
- if (vp->xMinScalar()) { _w->_xMinScalar->setSelection(vp->xMinScalar()->tag().displayString()); }
- if (vp->xMaxScalar()) { _w->_xMaxScalar->setSelection(vp->xMaxScalar()->tag().displayString()); }
- if (vp->yMinScalar()) { _w->_yMinScalar->setSelection(vp->yMinScalar()->tag().displayString()); }
- if (vp->yMaxScalar()) { _w->_yMaxScalar->setSelection(vp->yMaxScalar()->tag().displayString()); }
+ KstScalarPtr sc;
+ sc = vp->xMinScalar();
+ if (!sc) {
+ _w->_xMinScalar->setSelection("0");
+ } else if (*KST::scalarList.findTag(sc->tag().displayString())) {
+ _w->_xMinScalar->setSelection(sc->tag().displayString());
+ } else {
+ _w->_xMinScalar->setSelection(QString::number(sc->value())); //our scalar has been removed from the global list... just put its current value into the scalar selector. warning: after edit it won't be updated anymore! the motivation for putting this in is to not lose scale information when a plot is deleted.
+ }
+
+ sc = vp->xMaxScalar();
+ if (!sc) {
+ _w->_xMaxScalar->setSelection("0");
+ } else if (*KST::scalarList.findTag(sc->tag().displayString())) {
+ _w->_xMaxScalar->setSelection(sc->tag().displayString());
+ } else {
+ _w->_xMaxScalar->setSelection(QString::number(sc->value()));
+ }
+
+ sc = vp->yMinScalar();
+ if (!sc) {
+ _w->_yMinScalar->setSelection("0");
+ } else if (*KST::scalarList.findTag(sc->tag().displayString())) {
+ _w->_yMinScalar->setSelection(sc->tag().displayString());
+ } else {
+ _w->_yMinScalar->setSelection(QString::number(sc->value()));
+ }
+
+ sc = vp->yMaxScalar();
+ if (!sc) {
+ _w->_yMaxScalar->setSelection("0");
+ } else if (*KST::scalarList.findTag(sc->tag().displayString())) {
+ _w->_yMaxScalar->setSelection(sc->tag().displayString());
+ } else {
+ _w->_yMaxScalar->setSelection(QString::number(sc->value()));
+ }
+
vp->unlock();
updateButtons();
--- branches/work/kst/1.5/kst/src/widgets/scalarselector.ui.h #665430:665431
@@ -56,7 +56,12 @@
qHeapSort(scalars);
_scalar->insertStringList(scalars);
- if (found) {
+
+ bool ok;
+ prev.toDouble(&ok);
+ ok = ok && _scalar->editable(); //if directentry is allowed, and if prev is a number, then we can put it back into the combobox.
+
+ if (found || ok) {
_scalar->setCurrentText(prev);
} else {
_scalar->insertItem("0");
To make this useful we need to add fit options such that the user can fit to: 1) an entire curve (no updates based on plot limit changes) 2) the curve section as displayed (no updates based on plot limit changes) 3) the curve section as displayed (updates based on plot limit changes) currently we support only 1) and need to add 2) and 3) to the fit submenu. SVN commit 693063 by arwalker:
CCBUG:86915 CVS_SILENT Allow for the case where the output vector for the vector view is of zero length
M +61 -29 kstvectorview.cpp
--- branches/work/kst/1.5/kst/src/libkstmath/kstvectorview.cpp #693062:693063
@@ -68,7 +68,7 @@
QString xmintag, xmaxtag, ymintag, ymaxtag;
QString in_tag;
- _interp = (KstVectorView::InterpType(0)); //defaults. shouldn't be necessary.
+ _interp = KstVectorView::InterpY;
_useXmin = false;
_useXmax = false;
_useYmin = false;
@@ -172,10 +172,12 @@
}
bool vecsUpdated = (KstObject::UPDATE == _inputVectors[IN_XVECTOR]->update(update_counter)) ||
- (KstObject::UPDATE == _inputVectors[IN_YVECTOR]->update(update_counter));
+ (KstObject::UPDATE == _inputVectors[IN_YVECTOR]->update(update_counter));
KstVectorPtr flagVec = *_inputVectors.find(IN_FLAGVECTOR);
- if (flagVec) { vecsUpdated = (vecsUpdated || (KstObject::UPDATE == flagVec->update(update_counter))); }
+ if (flagVec) {
+ vecsUpdated = (vecsUpdated || (KstObject::UPDATE == flagVec->update(update_counter)));
+ }
if (!vecsUpdated && !force) {
unlockInputsAndOutputs();
@@ -222,6 +224,7 @@
break;
default:
NS = kMax(inXVec->length(), inYVec->length());
+ break;
}
int NSm1 = NS-1;
@@ -230,14 +233,18 @@
double *outYArr;
if (inXVec->length() == NS && inXVec->isRising()) { //good scenario.
- int i_bot = inXVec->indexNearX(xmin,NS); //closest index to xmin
- int i_top = inXVec->indexNearX(xmax,NS);
+ int i_bot = inXVec->indexNearX(xmin, NS); //closest index to xmin
+ int i_top = inXVec->indexNearX(xmax, NS);
- if (inXVec->value(i_bot) < xmin && i_bot < NSm1) { i_bot++; } //closest index above xmin
- if (inXVec->value(i_top) > xmax && i_top > 0) { i_top--; }
+ if (inXVec->value(i_bot) < xmin && i_bot < NSm1) {
+ i_bot++;
+ }
+ if (inXVec->value(i_top) > xmax && i_top > 0) {
+ i_top--;
+ }
- outXVec->resize(i_top - i_bot + 1,true); //initial resize. will trim later.
- outYVec->resize(i_top - i_bot + 1,true);
+ outXVec->resize(i_top - i_bot + 1, true); //initial resize. will trim later.
+ outYVec->resize(i_top - i_bot + 1, true);
outXArr = outXVec->value();
outYArr = outYVec->value();
@@ -247,9 +254,9 @@
int in = 0;
double yv;
for (long i=i_bot; i<=i_top; i++) {
- if (!flagVec || !flagVec->interpolate(i,NS)) { //only the LHS should be evaluated !flagVec
+ if (!flagVec || !flagVec->interpolate(i, NS)) { //only the LHS should be evaluated !flagVec
yv = inYVec->interpolate(i,NS);
- if ( (ymin <= yv) && (ymax >= yv) ) {
+ if (ymin <= yv && ymax >= yv) {
outXArr[in] = inXArr[i];
outYArr[in] = yv;
in++;
@@ -257,17 +264,28 @@
}
}
- outXVec->resize(in,false);
- outYVec->resize(in,false);
+ if (in > 0) {
+ outXVec->resize(in, false);
+ outYVec->resize(in, false);
+ } else {
+ outXArr[0] = 0.0;
+ outYArr[0] = 0.0;
+ outXVec->resize(1, false);
+ outYVec->resize(1, false);
+ }
} else if (inYVec->length() == NS && inYVec->isRising()) { //also good.
- int i_bot = inYVec->indexNearX(ymin,NS); //closest index to xmin
- int i_top = inYVec->indexNearX(ymax,NS);
+ int i_bot = inYVec->indexNearX(ymin, NS); //closest index to xmin
+ int i_top = inYVec->indexNearX(ymax, NS);
- if (inYVec->value(i_bot) < ymin && i_bot < NSm1) { i_bot++; } //closest index above xmin
- if (inYVec->value(i_top) > ymax && i_top > 0) { i_top--; }
+ if (inYVec->value(i_bot) < ymin && i_bot < NSm1) {
+ i_bot++;
+ } // closest index above xmin
+ if (inYVec->value(i_top) > ymax && i_top > 0) {
+ i_top--;
+ }
- outXVec->resize(i_top - i_bot + 1,true); //initial resize. will trim later.
- outYVec->resize(i_top - i_bot + 1,true);
+ outXVec->resize(i_top - i_bot + 1, true); //initial resize. will trim later.
+ outYVec->resize(i_top - i_bot + 1, true);
outXArr = outXVec->value();
outYArr = outYVec->value();
@@ -287,11 +305,18 @@
}
}
- outXVec->resize(in,false);
- outYVec->resize(in,false);
+ if (in > 0) {
+ outXVec->resize(in, false);
+ outYVec->resize(in, false);
+ } else {
+ outXArr[0] = 0.0;
+ outYArr[0] = 0.0;
+ outXVec->resize(1, false);
+ outYVec->resize(1, false);
+ }
} else { //worst case scenario. could do more ifs on y->isRising();
- outXVec->resize(NS,true); //initial resize. will trim later.
- outYVec->resize(NS,true);
+ outXVec->resize(NS, true); // initial resize. will trim later.
+ outYVec->resize(NS, true);
outXArr = outXVec->value();
outYArr = outYVec->value();
@@ -301,9 +326,9 @@
for (long i=0; i<=NSm1; i++) {
if (!flagVec || !flagVec->interpolate(i,NS)) { //only the LHS should be evaluated if !flagVec.
double xv = inXVec->interpolate(i,NS);
- if ( (xmin <= xv) && (xmax >= xv) ) {
+ if (xmin <= xv && xmax >= xv) {
yv = inYVec->interpolate(i,NS);
- if ( (ymin <= yv) && (ymax >= yv) ) {
+ if (ymin <= yv && ymax >= yv) {
outXArr[in] = xv;
outYArr[in] = yv;
in++;
@@ -311,11 +336,20 @@
}
}
}
- outXVec->resize(in, false);
- outYVec->resize(in, false);
+
+ if (in > 0) {
+ outXVec->resize(in, false);
+ outYVec->resize(in, false);
+ } else {
+ outXArr[0] = 0.0;
+ outYArr[0] = 0.0;
+ outXVec->resize(1, false);
+ outYVec->resize(1, false);
+ }
}
unlockInputsAndOutputs();
+
return setLastUpdateResult(UPDATE);
}
@@ -541,5 +575,3 @@
}
#include "kstvectorview.moc"
-
-// vim: ts=2 sw=2 et
SVN commit 693070 by arwalker:
CCBUG:86915 SILENT only resize if necessary and no need to initialize during the resize
M +24 -12 kstvectorview.cpp
--- branches/work/kst/1.5/kst/src/libkstmath/kstvectorview.cpp #693069:693070
@@ -243,8 +243,12 @@
i_top--;
}
- outXVec->resize(i_top - i_bot + 1, true); //initial resize. will trim later.
- outYVec->resize(i_top - i_bot + 1, true);
+ if (i_top - i_bot + 1 > outXVec->length()) {
+ outXVec->resize(i_top - i_bot + 1, false); //initial resize. will trim later
+ }
+ if (i_top - i_bot + 1 > outYVec->length()) {
+ outYVec->resize(i_top - i_bot + 1, false);
+ }
outXArr = outXVec->value();
outYArr = outYVec->value();
@@ -255,7 +259,7 @@
double yv;
for (long i=i_bot; i<=i_top; i++) {
if (!flagVec || !flagVec->interpolate(i, NS)) { //only the LHS should be evaluated !flagVec
- yv = inYVec->interpolate(i,NS);
+ yv = inYVec->interpolate(i, NS);
if (ymin <= yv && ymax >= yv) {
outXArr[in] = inXArr[i];
outYArr[in] = yv;
@@ -278,14 +282,18 @@
int i_top = inYVec->indexNearX(ymax, NS);
if (inYVec->value(i_bot) < ymin && i_bot < NSm1) {
- i_bot++;
+ i_bot++;
} // closest index above xmin
if (inYVec->value(i_top) > ymax && i_top > 0) {
i_top--;
}
- outXVec->resize(i_top - i_bot + 1, true); //initial resize. will trim later.
- outYVec->resize(i_top - i_bot + 1, true);
+ if (i_top - i_bot + 1 > outXVec->length()) {
+ outXVec->resize(i_top - i_bot + 1, false); //initial resize. will trim later.
+ }
+ if (i_top - i_bot + 1 > outYVec->length()) {
+ outYVec->resize(i_top - i_bot + 1, false);
+ }
outXArr = outXVec->value();
outYArr = outYVec->value();
@@ -295,8 +303,8 @@
int in = 0;
double xv;
for (long i=i_bot; i<=i_top; i++) {
- if (!flagVec || !flagVec->interpolate(i,NS)) { //only the LHS should be evaluated !flagVec
- xv = inXVec->interpolate(i,NS);
+ if (!flagVec || !flagVec->interpolate(i, NS)) { //only the LHS should be evaluated !flagVec
+ xv = inXVec->interpolate(i, NS);
if ( (xmin <= xv) && (xmax >= xv) ) {
outXArr[in] = inYArr[i];
outYArr[in] = xv;
@@ -315,8 +323,12 @@
outYVec->resize(1, false);
}
} else { //worst case scenario. could do more ifs on y->isRising();
- outXVec->resize(NS, true); // initial resize. will trim later.
- outYVec->resize(NS, true);
+ if (NS > outXVec->length()) {
+ outXVec->resize(NS, false); // initial resize. will trim later.
+ }
+ if (NS > outYVec->length()) {
+ outYVec->resize(NS, false);
+ }
outXArr = outXVec->value();
outYArr = outYVec->value();
@@ -324,8 +336,8 @@
int in = 0;
double yv;
for (long i=0; i<=NSm1; i++) {
- if (!flagVec || !flagVec->interpolate(i,NS)) { //only the LHS should be evaluated if !flagVec.
- double xv = inXVec->interpolate(i,NS);
+ if (!flagVec || !flagVec->interpolate(i, NS)) { //only the LHS should be evaluated if !flagVec.
+ double xv = inXVec->interpolate(i, NS);
if (xmin <= xv && xmax >= xv) {
yv = inYVec->interpolate(i,NS);
if (ymin <= yv && ymax >= yv) {
SVN commit 693402 by arwalker:
CCBUG:86915 support edit multiple functionality for vector views
M +157 -30 kstvvdialog_i.cpp
M +16 -9 kstvvdialog_i.h
--- branches/work/kst/1.5/kst/src/libkstapp/kstvvdialog_i.cpp #693401:693402
@@ -1,10 +1,11 @@
/***************************************************************************
- kstvvdialog_i.h - Dialog for KstVectorView objects.
+ kstvvdialog_i.cpp - Dialog for KstVectorView objects.
-------------------
- begin :
- copyright : (C) 2007 Kst
+ begin : 2007
+ copyright : (C) 2007 by The University of British Columbia
email :
***************************************************************************/
+
/***************************************************************************
* *
* This program is free software; you can redistribute it and/or modify *
@@ -57,13 +58,11 @@
KstVvDialogI::KstVvDialogI(QWidget* parent, const char* name, bool modal, WFlags fl)
: KstDataDialog(parent, name, modal, fl) {
_w = new VectorViewDialogWidget(_contents);
- setMultiple(false);
+ setMultiple(true);
connect(_w->_xVector, SIGNAL(newVectorCreated(const QString&)), this, SIGNAL(modified()));
connect(_w->_yVector, SIGNAL(newVectorCreated(const QString&)), this, SIGNAL(modified()));
-
connect(_w->_FlagVector, SIGNAL(newVectorCreated(const QString&)), this, SIGNAL(modified()));
-
connect(_w->_xMinScalar, SIGNAL(newScalarCreated()), this, SIGNAL(modified()));
connect(_w->_xMaxScalar, SIGNAL(newScalarCreated()), this, SIGNAL(modified()));
connect(_w->_yMinScalar, SIGNAL(newScalarCreated()), this, SIGNAL(modified()));
@@ -87,6 +86,12 @@
QColor qc = _w->_curveAppearance->color();
_w->_curveAppearance->setValue(false, false, true, qc, 0, 0, 0, 1, 0);
+
+ // for multiple edit mode
+ connect(_w->_xMinCheckbox, SIGNAL(clicked()), this, SLOT(xMinCheckboxClicked()));
+ connect(_w->_xMaxCheckbox, SIGNAL(clicked()), this, SLOT(xMaxCheckboxClicked()));
+ connect(_w->_yMinCheckbox, SIGNAL(clicked()), this, SLOT(yMinCheckboxClicked()));
+ connect(_w->_yMaxCheckbox, SIGNAL(clicked()), this, SLOT(yMaxCheckboxClicked()));
}
@@ -102,17 +107,17 @@
{
QString old;
if (_w->_plotList->count()) {
- old = _w->_plotList->currentText();
+ old = _w->_plotList->currentText();
}
QStringList plots = KstData::self()->plotList();
_w->_plotList->clear();
for (QStringList::ConstIterator i = plots.begin(); i != plots.end(); ++i) {
- _w->_plotList->insertItem(*i);
+ _w->_plotList->insertItem(*i);
}
if (!old.isNull() && plots.contains(old)) {
- _w->_plotList->setCurrentText(old);
+ _w->_plotList->setCurrentText(old);
}
}
@@ -130,7 +135,9 @@
_w->_xVector->setSelection(vp->in_xVTag());
_w->_yVector->setSelection(vp->in_yVTag());
- if (vp->hasFlag()) { _w->_FlagVector->setSelection(vp->FlagTag()); }
+ if (vp->hasFlag()) {
+ _w->_FlagVector->setSelection(vp->FlagTag());
+ }
_w->_xMinCheckbox->setChecked(vp->useXmin());
_w->_xMaxCheckbox->setChecked(vp->useXmax());
@@ -145,7 +152,11 @@
} else if (*KST::scalarList.findTag(sc->tag().displayString())) {
_w->_xMinScalar->setSelection(sc->tag().displayString());
} else {
- _w->_xMinScalar->setSelection(QString::number(sc->value())); //our scalar has been removed from the global list... just put its current value into the scalar selector. warning: after edit it won't be updated anymore! the motivation for putting this in is to not lose scale information when a plot is deleted.
+ // our scalar has been removed from the global list...
+ // just put its current value into the scalar selector.
+ // warning: after edit it won't be updated anymore!
+ // the motivation for putting this in is to not lose scale information when a plot is deleted.
+ _w->_xMinScalar->setSelection(QString::number(sc->value()));
}
sc = vp->xMaxScalar();
@@ -364,27 +375,39 @@
}
if (_interpTypeDirty) {
- vvPtr->setInterp(KstVectorView::InterpType(_w->_interp->currentItem()));
+ if (_editMultipleMode) {
+ vvPtr->setInterp(KstVectorView::InterpType(_w->_interp->currentItem()-1));
+ } else {
+ vvPtr->setInterp(KstVectorView::InterpType(_w->_interp->currentItem()));
+ }
}
if (_xMinScalarDirty) {
KstScalarPtr s = _w->_xMinScalar->selectedScalarPtr();
- if (s) {vvPtr->setXminScalar(s); }
+ if (s) {
+ vvPtr->setXminScalar(s);
+ }
}
if (_xMaxScalarDirty) {
KstScalarPtr s = _w->_xMaxScalar->selectedScalarPtr();
- if (s) {vvPtr->setXmaxScalar(s); }
+ if (s) {
+ vvPtr->setXmaxScalar(s);
+ }
}
if (_yMinScalarDirty) {
KstScalarPtr s = _w->_yMinScalar->selectedScalarPtr();
- if (s) {vvPtr->setYminScalar(s); }
+ if (s) {
+ vvPtr->setYminScalar(s);
+ }
}
if (_yMaxScalarDirty) {
KstScalarPtr s = _w->_yMaxScalar->selectedScalarPtr();
- if (s) {vvPtr->setYmaxScalar(s); }
+ if (s) {
+ vvPtr->setYmaxScalar(s);
+ }
}
if (_FlagVectorDirty) {
@@ -418,11 +441,42 @@
bool KstVvDialogI::editObject() {
-
+ _FlagVectorDirty = _w->_FlagVector->_vector->currentItem() != 0;
+ _xVectorDirty = _w->_xVector->_vector->currentItem() != 0;
+ _yVectorDirty = _w->_yVector->_vector->currentItem() != 0;
+ _useXminDirty = _w->_xMinCheckbox->state() != QButton::NoChange;
+ _useXmaxDirty = _w->_xMaxCheckbox->state() != QButton::NoChange;
+ _useYminDirty = _w->_yMinCheckbox->state() != QButton::NoChange;
+ _useYmaxDirty = _w->_yMaxCheckbox->state() != QButton::NoChange;
+ _xMinScalarDirty = _w->_xMinScalar->_scalar->currentItem() != 0;
+ _xMaxScalarDirty = _w->_xMaxScalar->_scalar->currentItem() != 0;
+ _yMinScalarDirty = _w->_yMinScalar->_scalar->currentItem() != 0;
+ _yMaxScalarDirty = _w->_yMaxScalar->_scalar->currentItem() != 0;
+ _interpTypeDirty = _w->_interp->currentItem() != 0;
KstVectorViewList vvList = kstObjectSubList<KstDataObject,KstVectorView>(KST::dataObjectList);
if (_editMultipleMode) {
- //currently no edit multiple for vectorviews.
+ bool didEdit = false;
+ for (uint i = 0; i < _editMultipleWidget->_objectList->count(); i++) {
+ if (_editMultipleWidget->_objectList->isSelected(i)) {
+ // get the pointer to the object
+ KstVectorViewList::Iterator vvIter = vvList.findTag(_editMultipleWidget->_objectList->text(i));
+ if (vvIter == vvList.end()) {
+ return false;
+ }
+
+ KstVectorViewPtr vvPtr = *vvIter;
+
+ if (!editSingleObject(vvPtr)) {
+ return false;
+ }
+ didEdit = true;
+ }
+ }
+ if (!didEdit) {
+ KMessageBox::sorry(this, i18n("Select one or more objects to edit."));
+ return false;
+ }
} else {
KstVectorViewPtr vp = kst_cast<KstVectorView>(_dp);
// verify that the curve name is unique
@@ -436,19 +490,14 @@
_xVectorDirty = true;
_yVectorDirty = true;
_interpTypeDirty = true;
-
_useXminDirty = true;
_xMinScalarDirty = true;
-
_useXmaxDirty = true;
_xMaxScalarDirty = true;
-
_useYminDirty = true;
_yMinScalarDirty = true;
-
_useYmaxDirty = true;
_yMaxScalarDirty = true;
-
_FlagVectorDirty = true;
// then edit the object
@@ -456,18 +505,21 @@
return false;
}
}
+
emit modified();
return true;
}
+
void KstVvDialogI::updateButtons() {
- _w->_xMinScalar->setEnabled(_w->_xMinCheckbox->isChecked());
- _w->_xMaxScalar->setEnabled(_w->_xMaxCheckbox->isChecked());
- _w->_yMinScalar->setEnabled(_w->_yMinCheckbox->isChecked());
- _w->_yMaxScalar->setEnabled(_w->_yMaxCheckbox->isChecked());
+ _w->_xMinScalar->setEnabled(_w->_xMinCheckbox->state() != QButton::Off);
+ _w->_xMaxScalar->setEnabled(_w->_xMaxCheckbox->state() != QButton::Off);
+ _w->_yMinScalar->setEnabled(_w->_yMinCheckbox->state() != QButton::Off);
+ _w->_yMaxScalar->setEnabled(_w->_yMaxCheckbox->state() != QButton::Off);
}
+
void KstVvDialogI::realtimeClicked() {
Kst2DPlotPtr plot = Kst2DPlot::findPlotByName(_w->_plotList->currentText());
@@ -490,6 +542,7 @@
updateButtons();
}
+
void KstVvDialogI::currentClicked() {
Kst2DPlotPtr plot = Kst2DPlot::findPlotByName(_w->_plotList->currentText());
@@ -519,20 +572,94 @@
updateButtons();
}
-void KstVvDialogI::populateEditMultiple() {
-}
void KstVvDialogI::cleanup() {
+ if (_editMultipleMode) {
+ _w->_xMinCheckbox->setTristate(false);
+ _w->_xMaxCheckbox->setTristate(false);
+ _w->_yMinCheckbox->setTristate(false);
+ _w->_yMaxCheckbox->setTristate(false);
+ _w->_interp->removeItem(0);
+ }
}
+
+void KstVvDialogI::populateEditMultiple() {
+ KstVectorViewList vvlist = kstObjectSubList<KstDataObject,KstVectorView>(KST::dataObjectList);
+ _editMultipleWidget->_objectList->insertStringList(vvlist.tagNames());
+
+ // also intermediate state for multiple edit
+ _w->_xVector->_vector->insertItem("", 0);
+ _w->_xVector->_vector->setCurrentItem(0);
+ _w->_yVector->_vector->insertItem("", 0);
+ _w->_yVector->_vector->setCurrentItem(0);
+ _w->_interp->insertItem("", 0);
+ _w->_interp->setCurrentItem(0);
+ _w->_xMinCheckbox->setNoChange();
+ _w->_xMinScalar->_scalar->insertItem("", 0);
+ _w->_xMinScalar->_scalar->setCurrentItem(0);
+ _w->_xMaxCheckbox->setNoChange();
+ _w->_xMaxScalar->_scalar->insertItem("", 0);
+ _w->_xMaxScalar->_scalar->setCurrentItem(0);
+ _w->_yMinCheckbox->setNoChange();
+ _w->_yMinScalar->_scalar->insertItem("", 0);
+ _w->_yMinScalar->_scalar->setCurrentItem(0);
+ _w->_yMaxCheckbox->setNoChange();
+ _w->_yMaxScalar->_scalar->insertItem("", 0);
+ _w->_yMaxScalar->_scalar->setCurrentItem(0);
+ _w->_FlagVector->_vector->insertItem("", 0);
+ _w->_FlagVector->_vector->setCurrentItem(0);
+
+ _tagName->setText("");
+ _tagName->setEnabled(false);
+
+ // and clean all the fields
+ _xVectorDirty = false;
+ _yVectorDirty = false;
+ _interpTypeDirty = false;
+ _useXminDirty = false;
+ _useXmaxDirty = false;
+ _useYminDirty = false;
+ _useYmaxDirty = false;
+ _xMinScalarDirty = false;
+ _xMaxScalarDirty = false;
+ _yMinScalarDirty = false;
+ _yMaxScalarDirty = false;
+ _useFlagVectorDirty = false;
+ _FlagVectorDirty = false;
+
+ updateButtons();
+}
+
+
void KstVvDialogI::setXVector(const QString& name) {
_w->_xVector->setSelection(name);
}
+
void KstVvDialogI::setYVector(const QString& name) {
_w->_xVector->setSelection(name);
}
+void KstVvDialogI::xMinCheckboxClicked() {
+ _w->_xMinCheckbox->setTristate(FALSE);
+}
+
+
+void KstVvDialogI::xMaxCheckboxClicked() {
+ _w->_xMaxCheckbox->setTristate(FALSE);
+}
+
+
+void KstVvDialogI::yMinCheckboxClicked() {
+ _w->_yMinCheckbox->setTristate(FALSE);
+}
+
+
+void KstVvDialogI::yMaxCheckboxClicked() {
+ _w->_yMaxCheckbox->setTristate(FALSE);
+}
+
#include "kstvvdialog_i.moc"
-// vim: ts=2 sw=2 et
+
--- branches/work/kst/1.5/kst/src/libkstapp/kstvvdialog_i.h #693401:693402
@@ -1,8 +1,8 @@
/***************************************************************************
kstvvdialog_i.h - Dialog for KstVectorView objects.
-------------------
- begin :
- copyright : (C) 2007 Kst
+ begin : 2007
+ copyright : (C) 2007 by The University of British Columbia
email :
***************************************************************************/
@@ -47,15 +47,19 @@
private:
static QGuardedPtr<KstVvDialogI> _inst;
+
// the following are for the multiple edit mode
-
bool _xVectorDirty;
bool _yVectorDirty;
bool _interpTypeDirty;
-
- bool _useXminDirty, _useXmaxDirty, _useYminDirty, _useYmaxDirty;
- bool _xMinScalarDirty, _xMaxScalarDirty, _yMinScalarDirty, _yMaxScalarDirty;
-
+ bool _useXminDirty;
+ bool _useXmaxDirty;
+ bool _useYminDirty;
+ bool _useYmaxDirty;
+ bool _xMinScalarDirty;
+ bool _xMaxScalarDirty;
+ bool _yMinScalarDirty;
+ bool _yMaxScalarDirty;
bool _useFlagVectorDirty;
bool _FlagVectorDirty;
@@ -65,9 +69,12 @@
void updateButtons();
void setXVectorDirty() { _xVectorDirty = true; }
void setYVectorDirty() { _yVectorDirty = true; }
-
void realtimeClicked();
void currentClicked();
+ void xMinCheckboxClicked();
+ void xMaxCheckboxClicked();
+ void yMinCheckboxClicked();
+ void yMaxCheckboxClicked();
private:
static const QString& defaultTag;
@@ -78,4 +85,4 @@
};
#endif
-// vim: ts=2 sw=2 et
+
SVN commit 693408 by arwalker:
CCBUG:86915 ensure that the dialog functionality isn't broken in translated versions
M +12 -5 kstvvdialog_i.cpp
--- branches/work/kst/1.5/kst/src/libkstapp/kstvvdialog_i.cpp #693407:693408
@@ -523,7 +523,11 @@
void KstVvDialogI::realtimeClicked() {
Kst2DPlotPtr plot = Kst2DPlot::findPlotByName(_w->_plotList->currentText());
- if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "X Axis") {
+ //
+ // the following assumes that the combo box entries are as follows:
+ // XY Axes, X Axis, Y Axis
+ //
+ if (_w->_plotAxes->currentItem() == 0 || _w->_plotAxes->currentItem() == 1) {
_w->_xMinCheckbox->setChecked(true);
_w->_xMinScalar->setSelection((plot->scalars())["xmin"]->tag().displayString());
@@ -531,7 +535,7 @@
_w->_xMaxScalar->setSelection((plot->scalars())["xmax"]->tag().displayString());
}
- if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "Y Axis") {
+ if (_w->_plotAxes->currentItem() == 0 || _w->_plotAxes->currentItem() == 2) {
_w->_yMinCheckbox->setChecked(true);
_w->_yMinScalar->setSelection((plot->scalars())["ymin"]->tag().displayString());
@@ -545,11 +549,14 @@
void KstVvDialogI::currentClicked() {
Kst2DPlotPtr plot = Kst2DPlot::findPlotByName(_w->_plotList->currentText());
-
KstScalarPtr sp;
double v;
- if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "X Axis") {
+ //
+ // the following assumes that the combo box entries are as follows:
+ // XY Axes, X Axis, Y Axis
+ //
+ if (_w->_plotAxes->currentItem() == 0 || _w->_plotAxes->currentItem() == 1) {
_w->_xMinCheckbox->setChecked(true);
v = (plot->scalars())["xmin"]->value();
_w->_xMinScalar->setSelection(QString::number(v));
@@ -559,7 +566,7 @@
_w->_xMaxScalar->setSelection(QString::number(v));
}
- if (_w->_plotAxes->currentText() == "XY Axes" || _w->_plotAxes->currentText() == "Y Axis") {
+ if (_w->_plotAxes->currentItem() == 0 || _w->_plotAxes->currentItem() == 2) {
_w->_yMinCheckbox->setChecked(true);
v = (plot->scalars())["ymin"]->value();
_w->_yMinScalar->setSelection(QString::number(v));
SVN commit 706229 by arwalker: CCBUG:86915 start adding UI for fits to only visible portions of data. Also remove set and restore defaults from plot edit dialog as it does not support defaults in the same way other view objects do. Still need to enable default functionality for labels, or hide default buttons. M +1 -1 editviewobjectdialog.ui M +87 -32 kst2dplot.cpp M +4 -0 kst2dplot.h M +13 -7 ksteditviewobjectdialog_i.cpp M +3 -5 kstfitdialog_i.cpp M +1 -0 kstgfx2dplotmousehandler.cpp M +1 -1 kstgfxarrowmousehandler.cpp M +1 -0 kstgfxlinemousehandler.cpp M +10 -1 kstgfxpicturemousehandler.cpp M +1 -0 kstgfxrectanglemousehandler.cpp M +2 -1 kstgfxtextmousehandler.cpp M +7 -0 kstviewarrow.cpp M +1 -0 kstviewarrow.h M +7 -0 kstviewbox.cpp M +1 -0 kstviewbox.h M +7 -0 kstviewellipse.cpp M +1 -0 kstviewellipse.h M +7 -0 kstviewlabel.cpp M +1 -0 kstviewlabel.h M +7 -0 kstviewlegend.cpp M +1 -0 kstviewlegend.h M +7 -0 kstviewline.cpp M +1 -0 kstviewline.h M +9 -0 kstviewobject.cpp M +7 -5 kstviewobject.h M +9 -0 kstviewpicture.cpp M +1 -0 kstviewpicture.h This is complete. Any additional desirable functionality should be entered as new bug reports. |