Make DisplaySettings use Application instead of ActionApplication

[jcfandino]

• So other applications can use this class

[stephengold]

The intent is for applications that use Acorus to extend ActionApplication.
This is an assumption made throughout the library.
What applications can't extend ActionApplication?

[jcfandino]

The intent is for applications that use Acorus to extend ActionApplication.

That's unfortunate IMO.
Except for this dependency on ActionApplication this DisplaySettings is highly cohesive, it is a single unit with a well defined functionality.
The strong coupling with ActionApplication forces the client to become dependent on another part of the library and without any benefit.

Extending a class is perhaps the strongest coupling relation in java. So if I have to extend my main class it has to be for a very good reason.
ActionApplication brings a lot of functionality that I don't need so I want to avoid extending it. Maybe I will extend it in the future but that should be independent of using DisplaySettings or maybe I want to extend another abstract Application made by someone else.

What applications can't extend ActionApplication?

I'm working on an AppState that I intent to use first with my game and then others. So I want it to be as self-contained as possible, so it consists of a simple nifty-gui with some generic options.
So to follow the current library's design I should downcast the Application in the initialize() to an ActionApplication. And also I need to force every game I add this AppState to extend ActionApplication, otherwise I would get a runtime class cast exception.

The client of my app state shouldn't need to know about Acorus, for them it's just an implementation detail. They should just attach the state and done deal, everything is taking care of.
But if I were to leak this dependency I would totally break the high-cohesion/low-coupling I try to keep in my design.

[stephengold]

Thank you for your contribution. I'll put out a new release soon.