Restructure UI classes

[Baret]

The UI classes should be well structured and not as cluttered as the GameView currently is. It creates components and fragments and puts them all together. And it handles some user input while other input is handled by a fragment itself. All that should be unified.

In principle the classes should be structured like that:

View -> Components -> Fragments

Where each part is self-contained and reusable.

A view creates custom components and passes each component all parameters it needs. It should also handle keyboard and mouse events but more to that later.

A component is a container that is directly fit into a view (may also be used by different views). It assembles itself from different fragments. There is a problem though. In Zircon you may not implement a Component yourself, i.e. directly extend Panel. This is because all implementations need to be of type InternalComponent, which resides in the internal packache which we do not want to use. Zircon's way of "custom components" is to use Fragments (just the way we already do it in the fragments package). But you always need a container around a fragment. In a view it would be easiest to compose it by simply calling screen.addComponents(CommandFragment(), GameSpeedFragment(), SomeOtherFragment()). I started to think about a woraround for this in #95 and came up with this which is called like this. We might need to find something more elegant to wrap a "CustomComponent" (which is actually a Fragment) into a Component.

A fragment then is a small part displaying exactly one information or providing one kind of input for the user (or both).

Input handling

Having all components and/or fragments handle keyboard and mouse inputs might get rather chaotic. So theses events should be handled on the top level (in the view) and then passed on to the relevant components. This opens the chance to create an own abstraction layer for unified user input events.

I think in the GameView the most mouse input will be on the map, either by hovering or left or right clicking. Now, what fragments are most interested in is "what coordinate has been clicked?" and "which button was clicked or is it being hovered?" to get information from the world at that coordinate. And while the interested fragment surely does not even know about the map component we need to pass that event over anyways.

An example: The user right clicks on the map. The view handles this event, calculates the clicked Coordinate (the event holds the absolute Position of the click, so you need to subtract the position of the map component and then ask it for the visible coordinate at that position) and creates a SecondaryMapAction which is then passed to all interested components. Every component then passes it on to their fragments listening to that action.

For map inputs there might be

• PrimaryMapAction -> left click
• SecondaryMapAction -> right click
• MapHover

Fragments and custom components can then listen for these actions/events (whatever we will call it).

Hint: This does not cover ComponentEvents like button clicks. These will probably need to stay inside the fragment creating the button. But maybe there needs to be a way for a fragment to "throw" these inputs further up?