You can also check the version via looking into what has been deposited in your .m2 directory...
I have another problem with autoscaling the y axes of plots. I tried all the setAutoScale commands and also notify the DataSet Listener manually (did not change). The y Axes don't autoscale - maybe there is an obvious error in this code? I set them up the same way than in the RollingBufferSample. There Autoscaling seems to work.
I suspect that the Renderer is not actually using the axis you configured and added to the chart. Can you try
renderer.getAxes().setAll(xAxis, yAxis)? This should normally work but is hard to get right for all cases as axes can be set up from fxml, code or from our defaults.
The maven syntax is sort-of similar to
make. The common mvn commands (in build order) that I often use mvn clean compile test package install. You can leave out also the previous ones. With the exception of mvn clean... mvn test implies compile and, for example mvn install implies compile, test, and package... hope this helps.
found it: mvn clean install -DskipTests=true
I'm trying to make a dataset editable via EditDataSet. The code looks like there is support for dragging points, but I can't seem to figure out how. The EditDataSetSample only lets me add points. Am I misunderstanding how it's supposed to work, or is there maybe a bug in there?
The points need to be marked first (ie. <ctrl>+<zoom drag>). Then the mouse should show the drag hand symbol when hovering overing the points. Clicking and draging should work from then onwards... importance is that the points are marked.
@wirew0rmalso commented that there is an overlap w.r.t. key short-cuts movements (notably with the zoom functionality)... unfortunately still unresolved.
The editing functionality is still a bit coarse...
Is there by any chance a callback with information about the actual change? I'd like to implement a ctrl-z undo/redo for manual changes
Unfortunately not yet. However, this could be done, for example, similarly to the zoom history in the
Zoomer plugin.
As mentioned earlier, the edit plugin is still very basic. We haven't spent more time on this because we have an existing/legacy Swing-based editor and haven't gotten around to migrating that application to JavaFX yet.
I deleted my earlier message because I thought it was an implementation issue on my end, but it looks like there is a bug when combining range growing with padding: GSI-CS-CO/chart-fx#465
Thanks a lot for the bug report and excellent documentation/MVP! 👍️ We will follow this up as soon as possible.
Florian Enner: I think your probem should be fixed in GSI-CS-CO/chart-fx#466 Please take a look and verify if the fix is sufficient or if you encounter any other problems with it :-)
Thanks! It fixed the initial problem, but it unfortunately still doesn't work the way I'd expect. Screenshots are in the PR
(Or maybe I'm misunderstanding how the grow ranging is supposed to work)
right... meant to do this earlier... will do by Monday.
1 reply
@dedeibel: created the new tag/release yesterday
1 reply
no worries, we meant to release this earlier but simply forgot. should be public now (v11.2.6): https://search.maven.org/search?q=de.gsi
There seems to be some Y-Axis issue with v11.2.6 and
setForceZeroInRange(true)
same chart on v11.2.5:
I currently don't have the time look further into this though. I'll try to put together a minimum viable sample sometime, but I probably won't get to it until next week
I'm using a custom Y-Axis, but for the above screenshots I commented out everything and I'm just running the default NumericAxis w/ setForceZeroInRange
Hello Florian, happy new year and sorry for the late reply, just returning from vacation over here. I'm trying to find out what is happening there, but I could not reproduce the issue by switching the axes in our samples to forceZeroInRange. I found some other strange behavior with some axes in the samples, but there I believe it has to do with some incomplete DataSet implementations which return incoherent range information. Just to be sure, what kind of DataSet are you using?
I wrote the following code as an example for this question:
package matt.play
import de.gsi.chart.XYChart
import de.gsi.chart.axes.spi.DefaultNumericAxis
import javafx.application.Application
import javafx.scene.Scene
import javafx.stage.Stage
fun main(args: Array<String>) {
Application.launch(ChartFXTestApp::class.java)
}
class ChartFXTestApp: Application() {
override fun start(primaryStage: Stage?) {
Stage().apply {
scene = Scene(
XYChart(
DefaultNumericAxis(
"X",
1.0,
20.0,
5.0
),
DefaultNumericAxis(
"Y",
0.0,
100.0,
10.0
)
)
)
}.show()
}
}
I was hoping the final argument of
DefaultNumericAxis would control which major ticks were displayed. For example, on the Y axis I was hoping for a tick at 10, 20, 30 etc. Maybe I am misunderstanding?
@mgroth0: the default axis tries to minimise collision between ticks and may skip some if they overlap with their neighbouring one. Also, if memory serves me right, it aims at always drawing the first and last ticks... thus this funny behaviour. If you want a different behaviour you may derive your own axis implementation and overwrite the tick computation with your own/preferred one...
This worked perfectly :)
import de.gsi.chart.axes.spi.AxisRange
import de.gsi.chart.axes.spi.DefaultNumericAxis
class ControlledNumericAxis(
label: String,
min: Double,
max: Double,
): DefaultNumericAxis(
label,
min,
max,
5.0
) {
var controlledTickValues: MutableList<Double>? = null
override fun calculateMajorTickValues(axisLength: Double, axisRange: AxisRange?): MutableList<Double> {
return controlledTickValues ?: super.calculateMajorTickValues(axisLength, axisRange)
}
}