I'm using zircon as my main graphics in a game, but when i close the terminal and java exits, The audio thread has not been closed, and is likely still running.I have no direct control over the audio thread, so I can't get the thread to check if it's closed. Could a terminal.onClosed(event), or even just an additional InputType to support "terminal closed" be created?

Bug in window sizing: when starting SwingApplication it sometimes starts smaller

Expected behavior

SwingApplication size should have always the same size

Actual behavior

With no changes is code, the window is sometimes smaller. Added '#' printing to better show the difference:

Steps to reproduce the bug

It happens even in the simplest possible config, with about 20% chance:

fun main() {
    SwingApplications.startApplication()
}

Environment

Linux Arch: 5.1.3-arch2-1-ARCH Desktop environment: KDE5 Zircon version: 2019.1.2-PREVIEW

Request for a table control

A simple table control, which displays content in cells. Only basic features and no fancy stuff in the beginning (like cells spanning mutliple columns and so forth)

Rationale

• useful for dev tools within Zircon and
• of course also for games (e.g. inventory, loadout view)

Suggested way of implementing

• a cell could embed any Zircon controls and facilitating the usage of text (similar like the log control)

A new pair of behaviors (FontOverrideSupport and FontOverride) will be introduced.

FontOverrideSupport will be implemented in Layerable, Terminal and Screen while FontOverriede will be implemented in Component, Layer and Terminal.

FontOverrideSupport is an internal interface which is responsible for knowing what Font Size can be used in them (this comes from the TerminalBuilder which a Terminal is built from and can't be changed later).

FontOverride holds a reference to a Font object which will be used when drawing. If you try to add / draw / etc an object which implements FontOverride to an object which implements FontOverrideSupport, the Font's size will be checked against the information in the object implementing FontOverrideSupport. If the Size does not fit the object will throw an exception.

The current rule is that there can be one font Size for each Terminal object and every other object must use Fonts with that size.

As a later feature half-width fonts will be also supported (eg. 16x16 + 8x16).

I'm trying to add Maven dependencies zircon-core-jvm 2020.1.0-RELEASE and zircon.jvm.swing 2020.1.0-RELEASE to a new Maven Java project using Eclipse, but an error occurs:

Missing artifact org.jetbrains.kotlinx:kotlinx-collections-immutable-jvm:jar:0.3

I'm not good at using Maven. Anytime I need to use Maven, I just follow instructions. So it may be just a silly question.

Fixes #77.

This creates a private Canvas subclass that invokes an onPaint callback.

This also removes canvas.ignoreRepaint = true. I remember reading somewhere in the Swing docs (can't seem to find it now) that it recommended canvas.setIgnoreRepaint(true), but I believe this is only necessary for real-time rendering. I'm not sure how zircon handles animations, as this library is still new to me, but it definitely doesn't render in real-time when there are no animations playing, so repainting is needed on some platforms.

Edit: Do you know if there's any other importance to ignoring repaint?

Summary

A "Log" refers to a GUI component, often used in roguelike games to display information to the user about a variety of events.

A dedicated "Log" Component would be a useful way to easily provide this functionality in a GUI.

Example

The Orc's attack hits! The Orc attacks you! You missed... You attacked the Orc!

Work Around

The current work around is to use a TextImage:

1. Create TextImage for your preferred size
2. Draw a box around it via BoxBuilder
3. Update TextImage with each of your log messages via TextImage's putText() method

For Example

public class Playground {

    public static void main(String[] args) {
        final Terminal terminal = TerminalBuilder.newBuilder()
                .font(CP437TilesetResource.REX_PAINT_20X20.toFont())
                .initialTerminalSize(Size.of(10, 5))
                .build();

        final TextImage img = TextImageBuilder.newBuilder()
                .size(Size.of(10, 5))
                .build(); // we create a new image to draw onto the terminal

        img.setForegroundColor(ANSITextColor.WHITE);
        img.setBackgroundColor(ANSITextColor.BLUE); // `putText` will use these

        BoxBuilder.newBuilder()
                .boxType(BoxType.DOUBLE)
                .size(Size.of(10, 5))
                .style(StyleSetBuilder.newBuilder()
                        .foregroundColor(ANSITextColor.CYAN)
                        .backgroundColor(ANSITextColor.BLUE)
                        .build())
                .build()
                .drawOnto(img, Position.DEFAULT_POSITION); // we create a box and draw it onto the image

        final List<String> logElements = new ArrayList<>();
        logElements.add("foo");
        logElements.add("bar"); // our log entries

        for(int i = 0; i < logElements.size(); i++) {
            img.putText(logElements.get(i), Position.OFFSET_1x1.withRelativeRow(i)); // we have to offset because of the box
        }

        terminal.draw(img, Position.DEFAULT_POSITION); // you have to draw each time the image changes

        terminal.flush();
    }
}

Right now classes like AppConfig and ShortcutsConfig have Builder classes that should be used exclusively for constructing instances of those classes, but this isn't guaranteed because the constructors are public, so users could actually use either. Some functionality, like that introduced in #381, assumes users will be using the Builders. Plus it'd be nice to have one Right Way to do things.

Potentially every class with a builder in our Builders package needs to be examined, but the builders themselves also need to be examined. AppConfigBuilder, for example, itself has a public constructor.

The end goal here is for there to be one way to build these things, for simplicity for the builder and to make things easier for the Zircon maintainers. Every public API class in Zircon should conform to one of the following patterns:

1. It has a public constructor and no builder, or
2. It has an internal constructor, a corresponding builder class (which itself has an internal constructor), and the way you construct the instance is by calling a public TheClass.newBuilder().build() method.

Phase 0

1. Identify all classes/constructors/methods that need updating.
2. If there's a code style guide, we should add what we're doing to it. If there isn't, we should create one.
3. (Optional) Look into tools available for Kotlin/Java that document API changes between versions.

Phase 1

1. Add a @Deprecated annotation to all constructors/methods that are currently public, but shouldn't be.
2. Add KDoc to each affected class indicating the recommended way of constructing that class.

Phase 2 (next major version?)

1. Remove @Deprecated annotations added in Phase 1.
2. Make constructors/methods internal that should be.

Describe the bug MouseEventType.MOUSE_WHEEL_ROTATED_UP is not getting triggered, whereas MouseEventType.MOUSE_WHEEL_ROTATED_DOWN works just fine. I tried both 'handleMouseEvents' and 'processMouseEvents' but nothing seems working.

To Reproduce Steps to reproduce the behavior:

1. Go to 'ScrollBarExample.kt' provided in examples
2. Add handleMouseEvents or processMouseEvents on scrollbar1
3. Run the example
4. See if MouseEventType.MOUSE_WHEEL_ROTATED_UP is triggered when scroll wheel is scrolled up

Expected behavior MouseEventType.MOUSE_WHEEL_ROTATED_UP should be triggered

Screenshots NONE

Desktop (please complete the following information):

• OS: ZorinOS based on Ubuntu 18.04.1
• JDK Version: OpenJDK version "1.8.0_252"
• Version: Linux Kernel 5.4.0-42-generic

Smartphone (please complete the following information): NONE

Additional context I tried using LibgdxApplications in place of SwingApplications but still same result moreover now MOUSE_WHEEL_ROTATED_DOWN is also broken.

Request for feature MultiSelect

I would like to see a small Component to select one value out of a list of possible values. The typical UI-Element would be a drop down menu, but that would need an overlay for the value list, so the simpler way would be to have a left-button and a right-button to scroll through the values. Or speaking in images, two examples:

Rationale

There are quite some Components provided by Zircon but none to have a simple way of selecting one value of a fixed list of possibilities. There are radio buttons, but you have to put those together yourself and it takes a lot of space. When you only have one line and a specific width, the MultiSelect like proposed is an easy solution.

Suggested way of implementing

I already implemented it in my project as Fragment, but I would expect it to be available in the Components class. It wouldn't be hard to provide it as both, a Component and a Fragment. I am ready to provide a pull reqeust for this feature soon.

Introduction of a group component

Current behavior

Currently it is difficult to apply styles to components, which share the same semantics but are not under the same panel or generally speaking, share the same component hierarchy.

Improved behavior

You can use a group component to group components together, which share common properties, like styles.

Suggested way of achieving the improvement

The group component shall be invisible but else act as a standard container.

Describe the bug A ConcurrentModificationException from the ArrayList data structure when running. (Also, the screen is 90% of the time completely white when I try running the project on Windows, but fine and doesn't run into any of these issues on my Mac).

To Reproduce I'm following the Caves of Zircon tutorial right now, and I'm about halfway through Part 11, so:

1. Clone my progress at https://github.com/fancyplants/zircon-tut
2. Run the game as usual (there's also a bigger issue that the window most of the time is completely white in both PlayView and StartView.
3. Press movement keys and see this exception get thrown in a coroutine.
4. Note: the game still continues running after this point (but it is hard to tell, since the screen is white most of the time as well).

checkForComodification:1013, ArrayList$Itr (java.util)
next:967, ArrayList$Itr (java.util)
filterTo:805, TurnBasedEngine$executeTurn$1 (org.hexworks.amethyst.internal)
filter:714, TurnBasedEngine$executeTurn$1 (org.hexworks.amethyst.internal)
invokeSuspend:22, TurnBasedEngine$executeTurn$1 (org.hexworks.amethyst.internal)
lambda 'with' in 'resumeWith':33, BaseContinuationImpl (kotlin.coroutines.jvm.internal)
resumeWith:29, BaseContinuationImpl (kotlin.coroutines.jvm.internal)
lambda 'withCoroutineContext' in 'run':56, DispatchedTask (kotlinx.coroutines)
withCoroutineContext:45, DispatchedTask (kotlinx.coroutines)
run:42, DispatchedTask (kotlinx.coroutines)
runSafely:571, CoroutineScheduler (kotlinx.coroutines.scheduling)
executeTask:738, CoroutineScheduler$Worker (kotlinx.coroutines.scheduling)
runWorker:678, CoroutineScheduler$Worker (kotlinx.coroutines.scheduling)
run:665, CoroutineScheduler$Worker (kotlinx.coroutines.scheduling)

Expected behavior I expect it to run nominally on Windows the same way it runs on Mac (no screen flickering, no exceptions), but it does not.

Screenshots What the game looks like most of the time:

I try to take a screenshot of the game nominally, but as soon as I get a good frame for a few seconds it reverts back to a white screen.

Desktop (please complete the following information):

• OS: Windows 10
• Version 19043.2130

Additional context Let me know if there's any other way I can help (more info, a live debug session, or even guidance on how I can fix this myself and submit the fix to the repository), since I've tried a bunch of different ways to make roguelikes and this is the one I wanna build my first game idea on!

When running the code from PlayerMoveExampleJava.java, I consistently get this exception.

To reproduce, start the program and hold a direction key (e.g. left) so the character moves all the way across the screen, switch to the other direction if you get near the edge of the screen.

Within maybe 10-20 seconds of holding down a key like this, the exception will be thrown.

[DefaultDispatcher-worker-1] ERROR SwingApplication - Render failed
java.lang.InterruptedException
        at java.base/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:418)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:190)
        at co.touchlab.stately.isolate.BackgroundStateRunner.stateRun(BackgroundStateRunner.kt:18)
        at co.touchlab.stately.isolate.IsoStateKt.createState(IsoState.kt:49)
        at co.touchlab.stately.collections.IsoMutableMap.<init>(IsoMutableMap.kt:8)
        at co.touchlab.stately.collections.IsoMutableMap.<init>(IsoMutableMap.kt:7)
        at io.github.reactivecircus.cache4k.RealCache.<init>(RealCache.kt:39)
        at io.github.reactivecircus.cache4k.RealCache.<init>(RealCache.kt)
        at io.github.reactivecircus.cache4k.CacheBuilderImpl.build(Cache.kt:141)
        at org.hexworks.zircon.internal.util.DefaultCache.<init>(DefaultCache.kt:17)
        at org.hexworks.zircon.internal.util.DefaultCache.<init>(DefaultCache.kt)
        at org.hexworks.zircon.internal.util.DefaultCache.<init>(DefaultCache.kt:9)
        at org.hexworks.zircon.api.util.Cache$Companion.create(Cache.kt:35)
        at org.hexworks.zircon.api.tileset.base.BaseCP437Tileset.<init>(BaseCP437Tileset.kt:42)
        at org.hexworks.zircon.internal.tileset.Java2DCP437Tileset.<init>(Java2DCP437Tileset.kt:27)
        at org.hexworks.zircon.api.SwingApplications$createDefaultFactories$1$1.invoke(SwingApplications.kt:200)
        at org.hexworks.zircon.api.SwingApplications$createDefaultFactories$1$1.invoke(SwingApplications.kt:199)
        at org.hexworks.zircon.internal.tileset.impl.DefaultTilesetFactory.create(DefaultTilesetFactory.kt:16)
        at org.hexworks.zircon.internal.tileset.impl.DefaultTilesetLoader.loadTilesetFrom(DefaultTilesetLoader.kt:26)
        at org.hexworks.zircon.internal.renderer.SwingCanvasRenderer.drawTiles(SwingCanvasRenderer.kt:192)
        at org.hexworks.zircon.internal.renderer.SwingCanvasRenderer.render(SwingCanvasRenderer.kt:150)
        at org.hexworks.zircon.internal.application.impl.BaseApplication.doRender(BaseApplication.kt:130)
        at org.hexworks.zircon.internal.application.impl.BaseApplication.access$doRender(BaseApplication.kt:23)
        at org.hexworks.zircon.internal.application.impl.BaseApplication$startRenderLoop$1.invokeSuspend(BaseApplication.kt:77)
        at org.hexworks.zircon.internal.application.impl.BaseApplication$startRenderLoop$1.invoke(BaseApplication.kt)
        at org.hexworks.zircon.internal.application.impl.BaseApplication$startRenderLoop$1.invoke(BaseApplication.kt)
        at org.hexworks.zircon.internal.application.impl.BaseApplication$1.invokeSuspend(BaseApplication.kt:52)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

Is your feature request related to a problem? Please describe. The event bus was moved from the singleton object Zircon and onto the application state instead. I am following the cavesofzircon tutorial and I am trying to figure out how to create the logging system using the event bus

Describe the solution you'd like A way to have the application be a singleton in the game

Describe alternatives you've considered I was going to create a singleton class myself that just slapped the app into it and just query from there, but it seems rudimental and wrong

Is your feature request related to a problem? Please describe. GameArea instances currently hold data about the world (GameBlock collection) as well as the view. (Scrollable) This means that if you need to change the view, you need to copy whole object with the complete GameBlock data.

Describe the solution you'd like I propose to separate GameArea from the Scrollable implementation:

• Add a GameAreaView or GameAreaCamera, that handles the Scrollable logic, but does not hold any world data and only points to an existing GameArea
• Either remove the Scrollable interface from GameArea, or give each GameArea a default view/camera to preserve backwards compatibility
• Let GameAreaComponentRenderer take a view/camera instead of a GameArea

Describe alternatives you've considered Making the visible part of a GameArea dynamically resizable would also mean that the world data does not have to be copied, but this would miss out on the cool features listed below. While making the views/cameras resizable would also not hurt, the decoupling makes it fairly easy to create a new view/camera, so the actual resizing support can go down in priority.

Additional context This separation would enable a lot of cool picture-in-picture game features, for example:

• Item description panels can include an extra 5by5 view of the item and its surroundings, that also updates the same way as the main view.
• Follow-cams for characters. Surveillance simulator, anyone?
• Dialogue boxes showing the character you speak to, maybe even using a different projectionMode than the main view.

This is a prerequisite for making Zircon truly multi-platform. All code in the jvmMain module needs to be reviewed and either needs to go to commonMain to the platform package or should be left there if it is only for jvm (File handling for example).