Catching a possible NPE on linux systems that are caused by a bug in the java runtime.

For further information: JDK-6322854
Merge pull request #265 from mkaring/1.4

Catching a possible NPE on linux systems
Add LibGDX input forwarding customization.

Make it possible to forward input events unhandled by Nifty to multiple
custom LibGDX InputProcessor's. Currently, the GdxInputSystem used by
Nifty consumes all input. On the other hand, if you try and capture
input via LibGDX directly, for example to get input directly for your
game that is being rendered underneath the Nifty UI, then Nifty will not
receive any input.

The problem with the current setup is that it's an either-or approach,
so either 1) Nifty (the UI) will consume all input, or 2) some custom
InputProcessor set by the LibGDX method Gdx.input.setInputProcessor
(myCustomGameInputProcessor) will consume all input (the game).

What is needed is for Nifty to share nicely with others. ;-) So modify
GdxInputSystem to use LibGDX's InputMultiplexer, which supports multiple
InputProcessors simultaneously. Modify the GdxInputSystem constructor to
allow the optional addition of multiple custom InputProcessors. Add
methods to GdxInputSystem to append, insert, remove, clear, and get
custom InputProcessors.

The new way GdxInputSystem will work by default is that Nifty will get
first dibs on any input. If Nifty does not process the input, then any
custom InputProcessor's that are set will receive the input, in the same
order they were added / inserted.

However, there is now the possibility of specifying that Nifty will
receive input AFTER all of your custom input processors. (This is not
the default behavior as most use cases will have Nifty as a UI
overlaying a game, so it makes sense to allow the UI a chance to handle
the input before the game.) Add an additional constructor to
GdxInputSystem that allows passing in the enum NiftyReceivesInput.FIRST
/ NiftyReceivesInput.LAST. FIRST is default, if LAST is specified then
any custom input processors will receive first dibs on any input, and
only if it is not handled, that is the input handling method in the
InputProcessor returns false, then Nifty will receive it.
Merge pull request #266 from 3xp0n3nt/gdx-input-multiplexer

Add LibGDX input forwarding customization.
Add method to get panel background color.
Refactor element mouse interaction.

There is an ambiguously-named method in the Element class that spurred
on this refactoring: onClick.

Surely this method began long, long ago with good intentions...

But now that Nifty has separated the idea of a click from a release, now
that there exists multiclicks, primary clicks, secondary clicks,
tertiary clicks, and combinations of clicking and releasing, this method
is embarrassingly outdated.

What it actually does is simulate a click-release of the primary mouse
button. "Simulate" means that normally all mouse actions are handled via
events, but in this case, the event system is bypassed and the mouse
action is handled AS IF it received an event.

This simulation is useful when we want to cause mouse actions to occur
that are not originated by the user. The only actual INTERNAL use case
for this currently is handling NiftyStandardInputEvent.Activate events.

Not only is the Element.onClick method name ambiguous, but the method it
delegates to is also ambiguous; that is, ElementInteraction.activate,
and the method that that method delegates to is also ambiguous:
ElementInteractionClickHandler.activate, and finally this last method
also delegates to another ambiguously named method,
MouseClickMethods.activate.

Why are they ambiguous? Because these "activate" methods are really
simulating a primary mouse button click-release. This "activate" concept
is a bad abstraction because in all these classes it is surrounded by
other methods that very specifically refer to mouse related parts and
actions (wheels, buttons, clicks, etc).

It's very important to have a consistent level of abstraction here. So
the solution is to rename all these "activate" methods to what they are
so that they harmonize with the other methods there, which means using
the phrase "clickAndReleasePrimaryMouseButton" or similar wording as
appropriate.

This renaming revealed that there were some methods missing for
supporting simulating secondary and tertiary mouse button
click-releases, so add those methods as well (most of the framework was
already in place for secondary & tertiary mouse actions).

Now we have elegantly solved the ambiguity of Element.onClick while
simultaneously adding some interesting features:

Element.onClickAndReleasePrimaryMouseButton
Element.onClickAndReleaseSecondaryMouseButton
Element.onClickAndReleaseTertiaryMouseButton

Now we can directly cause a click-release for either of the three mouse
buttons supported by Nifty, without having to dig through the code to
interpret the meaning of bad abstractions (Element class already
contains much explicit mouse-related functionality, so the above three
methods are not out of place).

Because the Element.onClick method is public, deprecate it rather than
deleting it (in line with other past refactorings of public Element class
methods). Refer users via the onClick javadoc to
onClickAndReleasePrimaryMouseButton.

Make Element.onClick delegate to
Element.onClickAndReleasePrimaryMouseButton.

Add extensive javadoc to Element.onClickAndReleasePrimaryMouseButton,
Element.onClickAndReleaseSecondaryMouseButton, &
Element.onClickAndReleaseTertiaryMouseButton to explain what they do and
in what situations they won't work. (This information was missing on the
Element.onClick method, making it even worse).

Change all internal callers of Element.onClick to use
Element.onClickAndReleasePrimaryMouseButton. Now, Element.onClick has no
uses internally and is ready to be deleted after the next release of the
library.

Element.onClickAndReleasePrimaryMouseButton is used internally to handle
NiftyStandardInputEvent.Activate events. The name of the new method is
self-documenting and should eliminate confusion for users implementing
custom controls and/or custom input mapping. They also now have the
option of mapping to secondary and/or tertiary mouse button
click-releases.

When Element.clickAndReleasePrimaryMouseButton is called, now not only
will a NiftyMousePrimaryClickedEvent be generated as before, but ALSO a
NiftyMousePrimaryReleaseEvent. The same applies for secondary & tertiary
mouse button click-releases. This was actually a preexisting bug that
has been fixed.

Other changes:

Remove all other methods from the Element class that were deprecated in
the previous version of Nifty. It should be safe to remove them now that
they are deprecated in the current release version of Nifty. None of
these methods were in use internally.

The multiclick mouse code was poorly written, not conforming to the
library's code style, contained spelling errors and poorly written
comments. This has been improved although it is still far from complete.
The logic of the multiclick code has not been changed.

All unit tests are passing, and integration testing was successful.
Rename jogl2 to jogl.

Rename nifty-renderer-jogl2 to nifty-renderer-jogl. Rename the actual
module directory and its reference in the main parent pom.

Why have version numbers in the module name? It makes no sense. Not only
would it be tedious to maintain as the version changed, but it's
inconsistent with all the other rendering modules. The whole point of
each module having it's own pom file is to specify the current version
in there.
Refactor Nifty Examples.

- Move all LWJGL content in nifty-examples module to it's own new
  module, nifty-examples-lwjgl. LWJGL isn't special - it can have its own
  examples module just like everyone else.

- Remove nifty-renderer-lwjgl dependency from nifty-examples.

- Refactor LWJGL initialization code in nifty-examples-lwjgl to make it
  stupid-easy to load & run any NiftyExample in one line of code (hint:
  it's easier than Slick2D, and that's difficult to beat)

- nifty-examples-lwjgl now implements every single example found in
  nifty-examples

- Cleanup & refactor the code in many of the examples in nifty-examples.
  TODO: Many more examples still need a ton of cleanup though!

- Delete the "issues" package & classes out of nifty-examples:

  This has got to be the most horrible idea I've seen in Nifty in a long
  time. It reeks of laziness. First of all, there's the problem of
  unsustainability. What's going to happen as the number of these issues
  keeps growing? At some point it's going to get nasty. It increases the
  size of the Nifty Gui library as well.

  Secondly, all those issues have been resolved! Who wants to see a bunch
  of code demonstrating non-existent problems? Probably no one.

  Who's going to want to maintain & update code for non-existent issues in
  the future when the examples or other code needs refactoring? *Cricket,
  cricket* That's what I thought. I've refactored the Nifty examples, and
  in the process, I've broken these stupid issues classes. Guess how much
  motivation I have to fix them?

  If you want to create demonstrations of bugs, please maintain your own
  repository for such things. In fact, why not have a public nifty-issues
  repository for this? There, problem solved.

- Delete the top-secret, uber-special "meins" file. It's from 2008, and
  it looks like @void256's personal notes or something? Doesn't belong
  in Nifty Gui.

- Add some missing examples to nifty-examples-slick2d (tutorial,
  multiclick, healthimage), since it's insanely easy to add new examples
  (thanks to @mkaring).

- Unrelated: Fix Slick2D naming inconsistencies. Some modules / packages
  / comments / etc use the word "slick", some use the word "slick2d",
  and still others use the word "slick2D". Rename comments & text mentions
  Slick2D, for package names & module names that require lowercase, use
  slick2d everywhere.

- Note: Slick2D still has some pre-existing unresolved issues, such as
  certain examples crashing due to "java.lang.NoClassDefFoundError:
  com/jcraft/jorbis/Info" (music issue?).

- Unit tests & integration tests are successful (excluding all the
  pre-existing examples issues - what I mean is that the changes did not
  introduce any bugs / regressions as far as could be tested).
Merge pull request #273 from 3xp0n3nt/get-panel-background-color

Add method to get panel background color.
Merge pull request #275 from 3xp0n3nt/refactor-mouse-element-interaction

Refactor element mouse interaction.
Merge pull request #278 from 3xp0n3nt/rename-jogl2-to-jogl

Rename jogl2 to jogl.
Merge pull request #279 from 3xp0n3nt/refactor-nifty-examples

Refactor Nifty Examples.
[Button] MoveCursorDown and MoveCursorUp don't check parent anymore

NextInputElement and PrevInputElement didn't check the parent of the
elements they change focus to/from. There is no known reason why it
should not be the same for MoveCursorDown and MoveCursorUp.