Merge pull request #26 from mkaring/1.3

Added missing event publishing to the tab control.
#3520041: Window DragNDrop multiplies events

In general when a popup is being shown (nifty.showPopup()) all of the
controls it contains are initialized (and in case of the button
control are registered with the EventBus). When the popup is closed
all controls are automatically removed from the EventBus. So popups work
in the general case correctly.

But when a drag operation starts the content of the draggable was being
moved to a newly created popup (with a call to markForMove()) and after
that the popup was displayed (using nifty.showPopup()). So in that case
all the controls - the content of the draggable that have been
initialized already - would be registered AGAIN when the content moves
to the popup! And because when the drag operation ends the content is
moved back and then the popup is closed - and since the content is
already gone the popup when being closed doesnt contained any elements
anymore. So the removal from the EventBus in the button case didn't work
at all too :)

So after the long explanation the fix actual was easy: when the drag
operation starts we will now show the popup first and THEN move the
content to the popup! This way no duplicate registering with the
EventBus is happening and everything should work as expected again!

PS: Another bug has been fixed as well: when the drag operation ends
Nifty looks for droppables at the current position. While doing this
Nifty didn't check if the droppables are visible! So it was possible
that you have some hidden droppable and when you incidentally drop
something at that position it would be possible to drop a draggable to a
hidden droppable - with the effect of your droppably disappearing! Crap!
But thats fixed now! :)
screen.debugOutputFocusElements() added to output focus information

This is helpful to get a debug string of all elements that are currently
focusable.
improved exception Logging and Element move focushandler fix

- improved logging of exceptions especially of exception stacktrace
- when elements are being moved from one parent to another the elements
are removed from the focushandler of the old parent and are now again
added to the focushandler of the new parent
addElementAfter() added to the FocusHandler
experimental change for mouse event handling

The old way of handling mouse events had some problems especially with
EventBus events.

Here is a (long) explanation:

When you use the <interact /> callback methods like <interact
onClick="..." /> everything is fine. Mouse events will travel down all
elements that are visibleToMouse="true" until some element has been
found with an <interact /> kind event handler set. When the event
handler is found this mouse event is consumed and is not send to any
other elements "below" the element. All is fine.

However there is a problem with this approach especially with EventBus
events. EventBus events are published and because of their very nature
are not able to provide any information if the event has been consumed
by anybody or not at all. This is a problem when you imagine overlayed
elements, like a button on a panel and you have a <interact
onClick="..." /> on the panel but you're using the Eventbus
ButtonClickedEvent for the button.

So when Nifty processes the mouse click event it will be first sent
to the Button (because it is "above" the panel) which publishes it to
the EventBus event AND then the event will be forwarded to the panel
below as well. The panel has the <interact onClick="..." /> event
handler set which is executed and event handling stops at the panel
level.

The problem is that we've now executed two event handlers (for the
button and the panel) even though we'd probably expect only the top most
element to be called.

This behaviour has now been changed like so:

To keep things simple Nifty will now stop processing directly when it
encounters the first visibleToMouse="true" element. This means events
will now don't travel any further. When you have two elements above each
other that both have visibleToMouse="true" then only the topmost element
will now get the event.

Please Note:

To make this work some of the default controls need to be changed
slightly. It might be necessary to change your code slightly as well!
Especially you must now be careful where you add visibleToMouse="true"
because this can now really block events from travelling down the
element tree.

We're not sure if this will solve all problems but it it at least a
straightforward simple solution. There is no second guessing anymore
where events hit elements and so on. We're not too happy with this but
we'll need to check this in practice (therefore the commit).
#3473823: SetWidth methods not so friendly

added static factory methods to create px and percent more easily
and readable:

public static SizeValue px(final int pixelValue);
public static SizeValue percent(final int percentage);
public static SizeValue wildcard();
introduction of first naive margin implementation
added some margin magic to the tabs control (work in progress)
#3521444: Add method to Nifty to request the build version

Added new public String getVersion() method to the main Nifty class that
returns the version of Nifty and the time of the build.
fix failing test
equals() method added to SizeValue and changed test to junit4 syntax
fixed auto-resize-if-all-childs-have-fixed-px-size mode

When all child elements of a parent element have a fixed width or height
value and the parent does not have any width or height constraints set
then Nifty will automatically resize the parent to the sum or the max
width or height value of all child elements. The specifiy Layoutmanager
(vertical, horizontal or center) decides if sum or max is used when
calculating the parent size.

Additionally another problem has been fixed:
when the auto-resize-if-all-childs-have-fixed-px-size mode has
calculated a new constraint for the parent and later the child elements
change in a way that doesn't allow Nifty to calculate a constraint (like
one child is removed or added or a constraint is changed from px to
percent) then the calculated width/height constraint for the parent will
be removed.
test example changed to demonstrate the auto calc mode for parents
version-feature: make sure to create the correct directory in ant task
#3522365: Javadoc addition (with patch)

added a JavaDoc to findNiftyControl() method that explains how this
method works especially that the method returns NullObjects when no
control can't be found
before applying a style the effect of that style is removed now

this fixes a problem when cloning an ElementType where it was possible
that the same style was applied twice
new feature: element attribute "renderOrder" to modify the render order

Elements will be rendered ascending by the renderOrder value which must
be an int value. The default value for "renderOrder" is 0 which means
that the original render order of the elements will be used. The render
order is relevant for the child elements of the same parent.

Internally the index in the elements list is used as the
default renderOrder value when you don't set a value. So when you have a
panel with 3 child elements and you don't set a specific renderOrder
value then internally they will automatically get the values 0, 1 and 2.
Rendering occurs in this order then.

You can change the renderOrder value to some high value, like 10000 to
enforce this element to be rendered above all of the other elements or
some very small number like -10000 to render it below all others. You
can even take control of the render order for all elements if you
provide a renderOrder value for all child elements.

Please note: When you use the same renderOrder for two elements then the
id will be used for comparison. If the elements don't have ids or the
same id then object.toString() is being compared (the reference in
memory).
actually compare renderOrder values like described in last comment :)
removed debug call the screen.debugOutput()