Enable scrollbars by refactoring ValueAxis#autoAdjustRange()

[Yuri-Blankenstein-TNO]

Dear JFreeChart,

I'm preparing the initial contribution of a new Eclipse project called TRACE4CPS. TRACE4CPS can be used to visualize execution traces of cyber-physical systems, for more information see https://projects.eclipse.org/proposals/eclipse-trace4cps. The visualization of these execution traces is based on JFreeChart. This fork contains some patches on JFreeChart that are needed to integrate it into the Eclipse UI framework. In order to be able to install JFreeChart in an Eclipse Environment, it has to be added to Eclipse Orbit. As such I would like to include these patches in the official version of JFreeChart such that the official version can be added to Orbit instead of some fork.

I hope that you are willing to support me on getting this awesome framework available to all those Eclipse developers out there.

Kind regards,
Yuri Blankenstein

[Yuri-Blankenstein-TNO]

To elaborate a bit more on this pull request. This pull request is all about panning and zooming, including support for scroll bars. It can be split up in the next categories of differences:

1. Enable scrollbars
   a. Refactored ValueAxis#autoAdjustRange() to calculate the maximum range to initialize scrollbars
   b. Add a notification to ChartPanel when a new chart is being set, such that scrollbars can re-initialize
2. Limiting zoom by specifying a minimum range on ValueAxis
3. Add a RangeAlign that specifies how to align the fixed auto range if set
4. Providing more control over mouse events
   a. Using predicates in ChartPanel instead of masks also allows to e.g. only accept events with Ctrl and not Shift pressed.
   b. Consuming events indicate to listeners - that are later in the notification chain - that the event is already handled
   c. Add support for only zooming/panning domain or range

[jfree]

This looks good but I'm thinking it might need the version number bumped to 1.6.x because of the API changes. I'm figuring out how to do this...maybe I release 1.5.4 on the current branch without this PR, then create a v1.6x branch and we go from there?

[Yuri-Blankenstein-TNO]

maybe I release 1.5.4 on the current branch without this PR, then create a v1.6x branch and we go from there?

That sounds like a solution to me. For me it is important to just have a version based on Java8 for now. Please notify me when you have prepared the 1.6.x branch. Then I will adapt this pull request to solve the merge conflicts.

PS: Maybe the 1.6.x branch is also a good solution to be able to merge #224 into, as that is also a slightly larger pull request?

[Yuri-Blankenstein-TNO]

I just saw #221, where I also suggested to create a 1.6 release, so we could re-open that pull request then as well.

[Yuri-Blankenstein-TNO]

This looks good but I'm thinking it might need the version number bumped to 1.6.x because of the API changes. I'm figuring out how to do this...maybe I release 1.5.4 on the current branch without this PR, then create a v1.6x branch and we go from there?

@jfree , do you already have an idea if and when you plan to give a follow up on this? If I can be of any help on this, please let me know. If the v1.6x branch has been created I can update #220, #221 and #224 to that branch and then we would be able to release v1.6.0.