Summary: | New tool: differentiate curves | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | Nicolas Brisset <nicolas.brisset> |
Component: | general | Assignee: | kst |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | ||
Priority: | NOR | ||
Version: | 1.x | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Nicolas Brisset
2005-06-24 23:16:01 UTC
*** Bug 107930 has been marked as a duplicate of this bug. *** SVN commit 472131 by arwalker: CCBUG:108084 Proposed UI for curve differentation tool. If there are no comments I'll implement the functionality at some point A curvedifferentiate.ui Thanks for taking care of that feature :-) May I suggest to rather use the two-list widget as in the monochrome print configuration implemented by Rick ? I think it is not more complicated for the user, and offers more possibilities (like ordering which properties to cycle first). I find Rick's implementation for monochrome printing excellent. I like the additional options (max curve width and point density), which must be preserved. The only things it lacked (in my opinion) were: 1) the ability to cycle curve colors (not surprising for monochrome printing!), possibly with an option to select the palette to cycle through directly here when colors should be cycled as well (I know you've also added it to kst settings, but the user might want to override default settings temporarily here) 2) the ability to cycle plot-wise, window-wise or session-wise (which you have thought of) 3) the scope of application (should possibly be plot, window, all windows to be consistent with 2) above, but then it requires a plot list in some cases) I am not sure 3) is worth the effort though, as we have to look at all possible combinations with 2), some of which might be inconsistent (like applying window-wise cycling to a single plot). This probably requires further thought... I slightly prefer the radio box to the 2list box. The point density and max width should be added. I assume the idea here is to permanently assign the new curve properties to the curves. This could be useful. My worry is that curve properties are related to curves, not to plots, and a curve may appear in more than one plot. How will you deal with this? Good question... Maybe "mark" curves as treated while processing the list, and ignore those that have been treated before ? Regarding the listbox vs radiobuttons (by the way, it should be checkbuttons as they are not exclusive !), I think setting the order can really be important: not only because different users may have different tastes, but also because it may depend on what task you are doing (for instance looking at a screen or printing, see bug #112140) or local "standards". It is probably not much more work to develop, not really more complicated for the user and much more powerful. I suspect that the problems with Curves indicates a problem in the underlying architecture. Would it not be better if we had the concept of a Curve and a Curve Instance. The former holds the vectors of the Curve, while the latter holds the properties (color, line style, etc) and knows how to draw a Curve. This way the user can have the same Curve with different properties. The Curve could hold default properties which would be used when a Curve Instance is created, essentially acting as sticky properties. There could also be the conpect of a copy of a Curve Instance in which modifying one Curve Instance would also impact the copies. In the interim, I would propose that we simply cycle through the Curves. We could "mark" Curves as treated (as Nicolas suggests) but this represents more code and it doesn't really matter if we set the Curve properties based on the first or the last instance that we meet (which would be essentially random anyway). Incidentally, I'd like to change the two list boxes around in the "Monochrome Print Configuration" as the Available and Selected are opposite to the way they work in the Plot Dialog Content tab working on Curves. Forgot to add the following message with the last commit: Update curve differntiation tool UI based on feedback. If there are no more comments I'll implement the functionality. SVN commit 472494 by arwalker: CCBUG:108084 Add icon for differentiate curves tool M +1 -1 Makefile.am AM kst_differentiatecurves.png --- trunk/extragear/graphics/kst/kst/pics/Makefile.am #472493:472494 @@ -13,7 +13,7 @@ kst_gfx_rectangle.png kst_gfx_rounded_rectangle.png \ kst_gfx_ellipse.png kst_gfx_polyline.png kst_gfx_polygon.png \ kst_gfx_arrow.png kst_gfx_picture.png kst_choosecolor.png \ - kst_csdnew.png + kst_csdnew.png kst_differentiatecurves.png ** trunk/extragear/graphics/kst/kst/pics/kst_differentiatecurves.png #property svn:mime-type + application/octet-stream SVN commit 472497 by arwalker: CCBUG:108084 Add UI for this feature. Still time to comment before the functionality is added. M +19 -0 kst.cpp M +9 -0 kst.h A kstcurvedifferentiate_i.cpp [License: GPL (v2+)] A kstcurvedifferentiate_i.h [License: GPL (v2+)] M +2 -1 kstui.rc --- trunk/extragear/graphics/kst/kst/kst.cpp #472496:472497 @@ -50,6 +50,7 @@ #include "kstchangefiledialog_i.h" #include "kstchangenptsdialog_i.h" #include "kstchoosecolordialog_i.h" +#include "kstcurvedifferentiate_i.h" #include "kstcurvedialog_i.h" #include "kstcsddialog_i.h" #include "kstdatamanager_i.h" @@ -146,6 +147,7 @@ viewFitsDialog = new KstViewFitsDialogI(this); changeFileDialog = new KstChangeFileDialogI(this); chooseColorDialog = new KstChooseColorDialogI(this); + differentiateCurvesDialog = new KstCurveDifferentiateI(this); changeNptsDialog = new KstChangeNptsDialogI(this); graphFileDialog = new KstGraphFileDialogI(this); vectorSaveDialog = new VectorSaveDialog(this); @@ -580,6 +582,15 @@ "based on data file.")); /************/ + DifferentiateCurvesDialogAction = new KAction(i18n("&Differentiate Between Curves..."), + "kst_differentiatecurves", 0, this, + SLOT(showDifferentiateCurvesDialog()), + actionCollection(), + "differentiatecurves_action"); + DifferentiateCurvesDialogAction->setWhatsThis(i18n("Bring up a dialog box\n" + "to differentiate between curves.")); + + /************/ ViewScalarsDialogAction = new KAction(i18n("View &Scalar Values"), 0, 0, this, SLOT(showViewScalarsDialog()), @@ -1941,6 +1952,11 @@ } +void KstApp::showDifferentiateCurvesDialog() { + differentiateCurvesDialog->showCurveDifferentiate(); +} + + void KstApp::showChangeNptsDialog() { changeNptsDialog->showChangeNptsDialog(); } @@ -2063,6 +2079,9 @@ if (!onlyVisible || chooseColorDialog->isShown()) { chooseColorDialog->updateChooseColorDialog(); } + if (!onlyVisible || differentiateCurvesDialog->isShown()) { + differentiateCurvesDialog->updateCurveDifferentiate(); + } if (!onlyVisible || changeNptsDialog->isShown()) { changeNptsDialog->updateChangeNptsDialog(); } --- trunk/extragear/graphics/kst/kst/kst.h #472496:472497 @@ -44,6 +44,7 @@ class KstChangeFileDialogI; class KstChangeNptsDialogI; class KstChooseColorDialogI; +class KstCurveDifferentiateI; class KstDataManagerI; class KstDataNotifier; class KstDebugDialogI; @@ -306,6 +307,9 @@ /** just calls chooseColorDialog->showChooseColorDialog(0) */ void showChooseColorDialog(); + /** just calls chooseColorDialog->showChooseColorDialog(0) */ + void showDifferentiateCurvesDialog(); + /** just calls viewScalarsDialog->showViewScalarsDialog(0) */ void showViewScalarsDialog(); @@ -407,6 +411,9 @@ /* Dialog for choosing curve color per file */ KstChooseColorDialogI *chooseColorDialog; + /* Dialog for differentiating between curves */ + KstCurveDifferentiateI *differentiateCurvesDialog; + /* Dialog for changing the Sample ranges for Vectors */ KstChangeNptsDialogI *changeNptsDialog; @@ -501,6 +508,8 @@ KAction *ChangeFileDialogAction; /** Choose Color Action: brings up the choose color dialog box */ KAction *ChooseColorDialogAction; + /** Differentiate Curves Action: brings up the differentiate curves dialog box */ + KAction *DifferentiateCurvesDialogAction; /** Change npts Action: brings up the change data range dialog box */ KAction *ChangeNptsDialogAction; /** GraphFileDialogAction: Brings up the graphics file export window */ --- trunk/extragear/graphics/kst/kst/kstui.rc #472496:472497 @@ -43,7 +43,8 @@ <Action name="datawizard_action"/> <Action name="changefiledialog_action"/> <Action name="changenptsdialog_action"/> - <Action name="choosecolordialog_action"/> + <Action name="choosecolordialog_action"/> + <Action name="differentiatecurves_action"/> </Menu> <Menu name="plots"><text>&Plots</text> <Action name="plotdialog_action"/> That looks _very_ good :-) Thinking about all this again, I came to the idea that it could be useful to have this in general kst settings as well, so that users can define the default cycling behavior instead of just changing it afterwards with this tool. Imagine someone who would want to work in B&W for some reason: he should be able to specify default settings. To sum up, the question would be how to provide a tool to change these properties at any time AND also some way of setting default values... SVN commit 472790 by arwalker: CCBUG:108084 Remember dialog settings. M +91 -43 kstcurvedifferentiate_i.cpp M +15 -2 kstcurvedifferentiate_i.h SVN commit 473433 by arwalker: CCBUG:108084 First draft of functionality M +34 -0 kstcolorsequence.cpp M +4 -1 kstcolorsequence.h M +96 -18 kstcurvedifferentiate_i.cpp M +13 -1 kstcurvedifferentiate_i.h M +1 -0 kstlinestyle.h M +30 -19 kstnumbersequence.cpp M +12 -12 kstnumbersequence.h No complaints so I assume all are happy. I have tested this a bit and I find it very useful, once you understand that you can "reset" some properties using the multiple edit mode. I wonder what's better for this tool: start from default values (like e.g. black, 0 width, continuous line, no points) and set all properties according to user settings in the dialog, or only change the selected ones ? Beyond that question, there are a few quirks/open points left to discuss: - it does not seem to respect the max line width set (bug) - sometimes plot legends are not updated when properties are changed with this tool, but it is not always the case. Needs further investigation (lurking bug) - how about the idea of adding this to kst settings to influence the way curves are initially created (feature) ? |