https://bugs.kde.org/show_bug.cgi?id=389855
--- Comment #14 from Alexander Semke <alexander.se...@web.de> --- (In reply to Matthew Trescott from comment #13) > I recorded a screen capture of an example with two Y axes in Logger Pro. > It's on my Google Drive because of the size limit on Bugzilla: > https://drive.google.com/open?id=1jf8bl6CPxstT6VC_s_8_lmiDEhW9bcHX Thanks for the video. The behavior you've shown here is also the behavior that is documented in my links posted above for Origin, Mathematica and Matlab. We actually didn't support this workflow in LabPlot yet at all. When posting those links I didn't realize they were referring to something different. In you video and in the links above it's about plotting different data sets of two different scales in the same plot - the second scale is set by the properties of the second axis. I meant actually the ability to add an _arbitrary_ number of axis, like in the example with Gri http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/037/3743/3743f4.jpg . Anyway, this feature (two different scales in one plot) is something that we should add soon, too. > I think there's another angle though: the user who needs advanced features > will be smart enough (for lack of a better phrase) to find and enable them. > The user who does not need them may simply be overwhelmed and give up if > advanced formatting features are enabled by default. I can see that LabPlot > has smart features, but it just hasn't yet learned to be smart on the user's > behalf. ;) It's not only about using advanced features it's also about having different workflows. A user who needs an application with abilities to modify every single details of a plot and to produce a PDF-export to be embedded into the latex file for the next publication has totally different perspective and demands on us than a user who just wants to quickly plot some external data. With stated with the first perspective and adding now features to support also the other perspective. And yes, I agree, we need to find out how to make the usage of the application for different users comfortable. > > I think that two design choices mentioned here are kinda related. > > - The plot scales down to fit the data, rather than the worksheet expanding > to fit it. This is the default behavior in LabPlot. The plot we create has on default the data range set to "auto" and the axes added to the plot ("box plot" with 4 axes, etc.) have also "Auto fit" option set to "on". With this settings all the data is shown, also automatically on new data changes - the plot adjusts to the new ranges. The only think that caused here a bit confusion and that is different compared to other tools is the difference between the worksheet view having fixed size (e.g. 15cm x 15cm) or having and infinite size (i.e. the view fills out the whole available window space). The latter can be achieved by using "view size" for the worksheet size and can be saved as default settings if the user needs this kind of behavior all the time. > This is understandable, since with massive numbers it would be > unrealistic to grow the worksheet to fit the data. (But then it causes ticks > to have non-whole-number labels). However, with panning and zooming, it > would not be so surprising if the user wished to pan and zoom to various > parts of the graph on his own. In this case, having the plot constantly > autoscale while adding data points could be undesirable, so maybe > autoscaling should by default only. As mentioned above, this is the default behavior - the default plot auto adjusts to the data. With zooming and panning the user can navigate into a certain region in the data. The user can also switch off the auto-mode and set the ranges to fixed values manually - this is actually the more frequent use case for people working on the plots for publications. For panning we have the buttons in the plot toolbar at the moment (shift left X, etc.). Panning with the mouse is being implemented now. I added the first code already for this recently. It works already but needs to be finalized yet. > - The number of ticks is fixed. Here, I think, is the problem. The user > shouldn't have to guess-and-check how many ticks are needed. It should be > possible for LabPlot, by default, to find a value equal to or higher than > the maximum value on a given axis that is a whole-number multiple of some > reasonable tick increment. (The tick increment would be based on the size of > the plot on the screen.) Of course, advanced users might want to adjust the > distance between ticks manually, but I think even that would be very much > preferable to changing the _number_ of ticks. > > The above method describes roughly what Logger Pro does, although if LabPlot > supported manually setting the tick increment it would actually have another > feature that Logger Pro does not. In LabPlot you can set the number of ticks for every axis separately. You can * either specify the total number of ticks and LabPlot will re-calculate their values on zooming, panning or rescaling of the plot when new data added * or you can specify the "increment" (i.e. the distance between two ticks) and LabPlot will re-calculate the number of ticks all the time you zoom, pan, etc. * or you can specify a column with values where the ticks have to be placed - this is useful if you need to have the ticks at some certain positions only. The settings for this can be found in the axis properties dock -> Ticks -> Type. The settings can be done for major and for minor ticks separately. Matthew, I'm very thankful you for your feedback and for this discussion. User's feedback is very important for us. But having this kind of discussion in a bugzilla ticket is a bit hard. Can we close this ticket, if the original problem is fixed for you, and move the further discussions to kde-edu mailing list or to the private email conversion? -- You are receiving this mail because: You are watching all bug changes.
