Currently SWTChart uses a custom made framework to add/remove/mange Context menus.
JFace already offers a MenuManger that is more flexible using actions instead of plain listeners and manages adding/removal more gracefully, it also allows deeper nesting, enable/disable on demand and dynamic menu contributions.
Currently the SWTChart implementation suffers from most of these features so it would be best to switch over to the JFace Menumanager as it also allows more smooth integration with other components.

When Y axis title is drawn, SWT resource Transform is instantiated, but the resource is missed to be disposed.

Currently the Barplot can only be printed side-by-side. Sometimes it would be usefull to display bars over others (but not stacked!). This would also allow to provide a Mirrored Bar plot for comparison purpose.

JUnit tests for org.eclispe.swtchart are missing.

Note: I have written some tests, but not yet ready to share them since package name is not adapted, and also the tests depend on environment at the moment.

We should provide CodeFormater Templates for Eclipse that can be used to format the source-code of SWT Chart in a consitent way.

IPlotArea should contain a IPlotArea#getChart() method so it is possible to access the corresponding chart, this is especially useful for PaintLinsteners so the can be written without explicitly reference the chart.

Currently source bundles are not included, but this helps developers in debugging/developing things with swt-chart.

Currently menuitems are called in an indirect manner, also tootips are currently not supported

Currently, charts are redrawn several times when actions are applied on the chart. in most cases, the data doesn't need to be redrawn as it not has changed. This causes some performance issues, especially when handling large data sets with many distinct points or when trying to select a region. A smart solution to solve this problem could be to create a bitmap initially, which is displayed in 1:1 or zoomed modus.

Sometimes, errors occur when the chart is empty or when the user zooms in and then maximal out and tries to move the scrollbar.

!ENTRY org.eclipse.ui 4 0 2019-06-20 14:25:49.041
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.IllegalArgumentException: Illegal range: lower=NaN, upper=NaN
	at org.eclipse.swtchart.internal.axis.Axis.setRange(Axis.java:183)
	at org.eclipse.swtchart.internal.axis.Axis.setRange(Axis.java:165)
	at org.eclipse.swtchart.extensions.core.ScrollableChart$4.handleEvent(ScrollableChart.java:1235)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5227)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1340)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4561)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4151)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:693)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
	at org.eclipse.chemclipse.rcp.app.ui.internal.support.ApplicationSupportDefault.start(ApplicationSupportDefault.java:26)
	at org.eclipse.chemclipse.rcp.app.ui.Application.start(Application.java:61)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1492)

It seems there is a memory leak in the event processing somewhere in SWTChart, maybe a listener seems to hold reference to the compressor, so it creates over and over again data items that then fill up the whole heap.

Currently I see over 400 instance of the CompressScatterSeries taking up 1.5GB ob space for only the boolean arrays

java.lang.OutOfMemoryError: Java heap space
at org.eclipse.swtchart.internal.compress.CompressScatterSeries.addNecessaryPlots(CompressScatterSeries.java:46)
at org.eclipse.swtchart.internal.compress.Compress.compress(Compress.java:149)
at org.eclipse.swtchart.internal.series.SeriesSet.compressAllSeries(SeriesSet.java:308)
at org.eclipse.swtchart.internal.PlotArea.setBounds(PlotArea.java:113)
at org.eclipse.swtchart.internal.ChartLayout.layoutPlot(ChartLayout.java:413)
at org.eclipse.swtchart.internal.ChartLayout.layout(ChartLayout.java:138)
at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1744)
at org.eclipse.swt.widgets.Composite.layout(Composite.java:1056)
at org.eclipse.swt.widgets.Composite.layout(Composite.java:1007)
at org.eclipse.swt.widgets.Composite.layout(Composite.java:963)
at org.eclipse.swtchart.Chart.updateLayout(Chart.java:347)
at org.eclipse.swtchart.Chart.handleEvent(Chart.java:322)
at org.eclipse.swtchart.extensions.core.AbstractHandledChart.handleEvent(AbstractHandledChart.java:28)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5227)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1340)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1366)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1345)
at org.eclipse.swt.widgets.Control.setBounds(Control.java:1104)
at org.eclipse.swt.widgets.Composite.setBounds(Composite.java:1527)
at org.eclipse.swt.widgets.Control.setBounds(Control.java:931)
at org.eclipse.swt.layout.GridLayout.layout(GridLayout.java:693)
at org.eclipse.swt.layout.GridLayout.layout(GridLayout.java:197)
at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1744)
at org.eclipse.swt.widgets.Composite.setBounds(Composite.java:1530)
at org.eclipse.swt.widgets.Control.setBounds(Control.java:931)
at org.eclipse.swt.layout.GridLayout.layout(GridLayout.java:693)
at org.eclipse.swt.layout.GridLayout.layout(GridLayout.java:197)
at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1744)
at org.eclipse.swt.widgets.Composite.setBounds(Composite.java:1530)
at org.eclipse.swt.widgets.Control.setBounds(Control.java:931)
at org.eclipse.swt.layout.FillLayout.layout(FillLayout.java:204)

I see that Eclipse swtchart version released is 0.7 but latest sourceforge version is 0.10 . It would make sense to use bigger version than the sourceforge version to make it clear that it's newer.

Currently examples are provided as a launch-config. Launch configs are sensible to projects in workspace, available target platforms and even eclipse installs. Thus it is not reliable to use this across different setups.

SWT-Chart should instead provide a product file that is packed as part of the normal build process to ensure everything is working fine.

The Updatesite is already generated as part of the buil, but currently not uploaded to an official location.
If Eclipse itself does not offer support, we might can use github-pages for this.

Currently the whole Charting Component is very monolithic and implementors are accessing it in a way that makes it impossible to extend or replace the rendering (e.g. for 3D/OpenGL Support).
There is already an interface IPlotArea but it is not used consistently.
The idea is, that the Chart itself does not know much about the Plotting but only contains an area that might be injected from the outside, so users of the chart can choose the proffered rendering method.

https://ci.eclipse.org/swtchart/job/build/job/develop/ fails seems to be an outdated update site https://download.eclipse.org/tools/orbit/downloads/drops/S20190819183153/repository

It should be possible to mark a Series as "mirrored", this would simply paint all values as if they are multiplied by -1. The axis should then be painted twice but not with negative values!

After Jenkins has been enabled for SWTChart, bundle-signing should be activated.

LabelMarker currently calculates positions and draws empty labels. As this has no visual effect the operation can be skipped.

For the display of NMR data, the axis needs to be shown in reverse order. Positive x values left, negative x values right.

When numbers that can not be transformed to int type are used, scrolling of appropriate axes does not work

The existing scrollbar calculation could lead to wrong calculations as partly negative values are set:

sliderHorizontal.setThumb(...)
sliderHorizontal.setSelection(...)

The Linux JRE seems to be more lenient when doing things wrong than the Windows JRE.

Currently it is a little bit cumbersome to work with actual series objects, because the Extended Charting is working mostly with ids

Often keyboard and mouse events are used. Hence, support for A, a and the mouse events have been added to make the code easier to read. Currently, they are listed in BaseChart.

int KEY_CODE_A = 65;
int KEY_CODE_a = 97;

To make it easier to read and show that it is a static field, the following adjustments shall be applied (UC - upper case, LC - lower case):

int KEY_CODE_UC_A = 65;
int KEY_CODE_LC_A = 97;

Furthermore, keyboard and mouse events shall be separated from BaseChart, so that they can be re-used.

On Mac OS (this is what I have experienced), when you choose to save chart as image, this image is flipped vertically. It must be flipped again to retrieve a nice chart image. I have changed the save method in chart.java to solve the problem (hint from http://www.java2s.com/Tutorial/Java/0300__SWT-2D-Graphics/WriteanImagetoaPNGfile.htm). Here is the changed source code :

/**
* Saves to file with given format.
* 
* @param filename
*            the file name
* @param format
*            the format (SWT.IMAGE_*). The supported formats depend on OS.
*/
public void save(String filename, int format) {
        Image image = new Image(Display.getDefault(), getBounds());
        GC gc = new GC(image);
	print(gc);
	gc.dispose();
	ImageData imageData = image.getImageData();
	
        ///CHANGES START HERE<<<<<<--------
	String osName = System.getProperty("os.name").toLowerCase();
	boolean isMacOs = osName.startsWith("mac os x");
	if (isMacOs) {
		//Flip image vertically when Mac Os 
		int bytesPerPixel = imageData.bytesPerLine / imageData.width;
		int destBytesPerLine = imageData.width * bytesPerPixel;
		byte[] newData = new byte[imageData.data.length];
		for (int srcY = 0; srcY < imageData.height; srcY++) {
			for (int srcX = 0; srcX < imageData.width; srcX++) {
				int destX = 0, destY = 0, destIndex = 0, srcIndex = 0;
				destX = srcX;
				destY = imageData.height - srcY - 1;
				destIndex = (destY * destBytesPerLine) + (destX * bytesPerPixel);
				srcIndex = (srcY * imageData.bytesPerLine) + (srcX * bytesPerPixel);
				System.arraycopy(imageData.data, srcIndex, newData, destIndex, bytesPerPixel);
			}
		}
		// destBytesPerLine is used as scanlinePad to ensure that no padding is required
	        imageData = new ImageData(imageData.width, imageData.height, imageData.depth, 
                imageData.palette, destBytesPerLine, newData);
	}
	////CHANGES END HERE<<<<<<--------
    
	ImageLoader loader = new ImageLoader();
	loader.data = new ImageData[]{imageData};
	loader.save(filename, format);
	image.dispose();
}

Do you think it could be useful to include it in SWTChart ?

https://ci.eclipse.org/swtchart/job/build/ contains only latest version but we would need builds for banches as well, it seems the multibranch pipeline is not setup for automatic scans in the job, for example her it is configured to scan at least once an hour

Currently the data of a series is defined (mostly) by two double arrays (xdata/ydata) this has several drawbacks:

1. all data must be copied to new arrays, for safety reasons the series also copies the data again
2. Data integrity can't be archived since at least two calls must be made to reach a consistent state (in fact, currently it is assumed that first x-data is set, then y-data)
3. We can't use business objects as the backing store in a natural way since we have to transfer back and forth between the two domains (array-index vs domain object)
4. extending is hindered (e.g. for the 3d domain, custom colors for each datapoint, custom labels ...) because we are limited to the double array storage or must extend the series model for each different use case
5. We can't display dynamic data (like data acquired from a source of datapoints) without recreating the whole data arrays over and over again
6. Currently it is impossible to represent "missing data" in a reliable way (even though it would be possible to use NaN for that)
7. Because of all these limitations, code often tends to use internal packages to directly call/enhance the series implementation.

The idea is to introduce a datamodel the series uses and acquires necessary information from it, we can easily supply a DoubleArrayDatamodel for supporting backward compatible behavior.

Since this is a larger refactoring, we can improve this step-by-step in an evolutionary manner:

• First we leave the API as is but deprecate methods, old methods would call new API in a compatible way
• We can now start to replace old calls with new ones

https://bugs.eclipse.org/bugs/show_bug.cgi?id=547955

Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at org.eclipse.swtchart.internal.series.BarSeries.getRiserWidth(BarSeries.java:382)
at org.eclipse.swtchart.internal.series.BarSeries.getAdjustedRange(BarSeries.java:336)
at org.eclipse.swtchart.internal.axis.Axis.adjustRange(Axis.java:345)
at org.eclipse.swtchart.internal.axis.AxisSet.adjustRange(AxisSet.java:273)
at org.eclipse.swtchart.extensions.core.AbstractExtendedChart.adjustRange(AbstractExtendedChart.java:369)

Currently, if a chart has disabled tooltips, the hand-cursor is still shown, also on each mousemove all series are checked for matching coordinates..

This wastes CPU Time and confuses the user, since he van't really understand why there is a Hand-Cursor displayed sometimes

org.eclipse.swtchart.internal.series.BarSeries.setBarWidth(int) checks for ipadding <= 0 but mut check for width

!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.IllegalArgumentException: Illegal range: lower=0.1234375, upper=0.0
at org.swtchart.internal.axis.Axis.setRange(Axis.java:200)
at org.swtchart.internal.axis.Axis.setRange(Axis.java:180)
at org.eclipse.eavp.service.swtchart.core.AbstractExtendedChart.adjustMinMaxRange(AbstractExtendedChart.java:224)
at org.eclipse.eavp.service.swtchart.core.AbstractExtendedChart.setRange(AbstractExtendedChart.java:179)
at org.eclipse.eavp.service.swtchart.events.ZoomEvent.handleEvent(ZoomEvent.java:77)
at org.eclipse.eavp.service.swtchart.core.BaseChart.handleEventProcessors(BaseChart.java:637)
at org.eclipse.eavp.service.swtchart.core.BaseChart.handleEvent(BaseChart.java:605)
at org.eclipse.eavp.service.swtchart.core.BaseChart.handleMouseWheel(BaseChart.java:575)
at org.eclipse.eavp.service.swtchart.core.ScrollableChart.handleMouseWheel(ScrollableChart.java:346)
at org.eclipse.eavp.service.swtchart.core.IEventHandler.handleEvent(IEventHandler.java:47)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5227)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1340)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1366)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1349)
at org.eclipse.swt.widgets.Control.sendMouseEvent(Control.java:4133)
at org.eclipse.swt.widgets.Control.gtk_scroll_event(Control.java:3581)
at org.eclipse.swt.widgets.Scrollable.gtk_scroll_event(Scrollable.java:300)
at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2009)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:5827)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5498)
at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9545)
at org.eclipse.swt.widgets.Display.eventProc(Display.java:1275)
at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2495)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4149)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1121)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1022)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:150)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:693)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:610)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148)
at org.eclipse.chemclipse.rcp.app.ui.internal.support.ApplicationSupportDefault.start(ApplicationSupportDefault.java:26)
at org.eclipse.chemclipse.rcp.app.ui.Application.start(Application.java:61)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
at org.eclipse.equinox.launcher.Main.main(Main.java:1492)

As part of GSoC 2019, I am working on extending the export options to support vector graphics (.svg) . To do this I am creating a java.awt.Graphics2D object which is an exact copy of the chart already displayed on the users screen.
I am able to plot the chart without using any restricted API. However, the main problem is with labels and grids.
With what I did initially, I could make an exact vector replica of the chart displayed on user's screen using the same values of tick's labels, positions which are on the chart. As you can see here https://github.com/mavrk/swtchart/blob/3133f04a9b3bbb80b49f7d5b754012a54344e4ad/org.eclipse.swtchart.export/src/org/eclipse/swtchart/export/core/BaseChartToGraphics2D.java#L275 However this is a restricted API.
To by pass this problem I propose to move BaseChartToGraphics2D class to an internal package. This will not involve adding additional dependencies as this class's sole purpose is to create a java.awt.Graphics2D object and it is not dependent on Batik or XMLGraphics project. We can then use this internal class to create a Graphics2D object.

Add an option to show/hide the title via the IChartSettings instance.

IAxisTick xTick = chart.getAxisSet().getXAxis(0).getTick();
DateFormat format = new SimpleDateFormat("y/M/d");
xTick.setFormat(format);

We have an application with SWT chart. Now we are deploying the application to Brazil. But we found out that users in Brazil does not see the chart details.

The chart in all timezones (except Brazil) looks like:

In Brazil timezone it looks like:

The above screenshots above are created with the same data and source but with another timezone configured.

Tycho can also use a target platform definition to resolve dependencies. From my point of view, the advantage is that the very same target definition is used during the build as well as when developing inside the Eclipse IDE.

If you are interested, I can prepare a change that a) updates Tycho to the latest version and b) introduces the target platform file that is used during the build and inside the IDE. Let me know.

Eclipse SWTChart is part of this years GSoC 2019 initiative:
https://summerofcode.withgoogle.com/projects/#4820028082356224

A task is to enhance the export options.
Hence, all export related functionality shall be placed in a separate bundle to enhance the maintainability of SWTChart.

Please add support for Java 8 dates (LocalDate, LocalDateTime, ...) to make an application java 8+ compatible without using old (almost depricated) dates.

As mentioned in the Eclipse proposal, we'd like to use the EPL v2:
https://projects.eclipse.org/proposals/eclipse-swtchart

EPL v2
https://www.eclipse.org/legal/epl-2.0
https://www.eclipse.org/legal/epl-2.0/faq.php

Currently, the following chart types are available:

• BarChart
• ScatterChart
• LineChart

Support for a new chart type "ScatterChart" shall be added. It is principally available already. When adding series, the following setting needs to be activated:

• lineSeriesSettings.setEnableStep(true);

This could be done by the "ScatterChart" automatically when adding new data "addSeriesData(...)".

At least some pointer to github would be nice.

For my project, I used to rely on ISeries#setXDateSeries(Date[] series). This method seems to be gone. What do you propose to do? Most of my compile errors are due to the get/setXDateSeries change and I am wondering how to best refactor my code.

I know I could convert myself to double via Date#toTime. Is that the proposed solution?

Do you plan to provide a model implementing CartesianSeriesModel also for Date (or even LocalDate)? And then provide the setXDateSeries methods for backwards compatibility. I believe it could be beneficial also for other adopters to keep the changes to the API changes fairly small.

What are your plans on API compatibility? I know SWTChart never was a 1.x release and by moving to Eclipse and naming it 0.7.0, there is no necessity on API compatibility. I am trying to understand if and how I can help.

BTW, I see the documentation still contains the reference to setXDateSeries: http://swtchart.org/doc/index.html#Axis_Tick_Format

SWT Chart plugins should use Internationalization.

I will provide a PR to propose changes in order to implement these changes

I will have a look at this issue at the next Eclipse Hackathon:
https://wiki.eclipse.org/Hackathon_Hamburg_2019_Sept

Hello,
I'm building a standalone SWT application with Gradle and I can't figure out how to add this wonderful library as a dependency. From what I can tell, swtchart isn't published to any Maven repo. Usually with GitHub this is also possible using JitPack or the Gradle gitRepository function but neither works here. Are there any plans to enable this?

When a new Menu is created, the old one is not disposed. This leads to hard references to the MenuItem Handlers, so the cannot be garbage collected.