fromheten / blacken Goto Github PK

The first step toward having a genuine display update protocol is having an 
update command queue that is used to send events from the terminal interface to 
the display interface.

It would allow us to work on the exact protocol, get some of the data 
structures worked out, then turning this in to a network-based protocol would 
be much easier.

Also, if we have anything more than one active, overlapping TerminalInterface 
(as you would have with Glass Pane support or something similar) the use of 
such a queue (or queues) would mean we could simplify the interaction between 
the terminal interfaces and the display interfaces. We would gain the capacity 
to fire-and-forget.

Please describe use-case:

To get an overview of the classes and how they interact it would be helpful to 
have a class diagram.

There should be tools we can use to generate one automatically.

Please describe use-case:

Problem 1.

When dealing with styled text, bolded and italicized text may fit a different 
cell size than standard text. We want to avoid cell overlap. This is hard to 
avoid when standard text should be close together, yet italic text normally 
leans in to the neighboring cell.

Ideally, we would have font styles which were individually resized to fit the 
grid cell.

Problem 2.

When using cell walls one of the walls can touch the glyph.

Ideally, we would want to use a slightly smaller font when cell walls are used.

Problem 3.

Some of these lame fonts don't have all the glyphs I want to use. I would like 
to use different fonts for different Unicode codepoint regions. You know, 
because the font with the best Ancient Egyptian Heiroglyphs might not be the 
best for APL symbols I want.

Ideally, you could assign different fonts to different Unicode regions. This 
way you could have a dedicated Ancient Egyptian Heiroglyph font, and a 
dedicated Bamum font.

Problem 4.

A system allowing Unicode code point groups to be specified manually allows for 
the specific glyphs I want when it matters, but is a lot of work when it 
doesn't matter.

Ideally, it would default to automatically selecting available fonts to fit all 
of the available Unicode regions.

This is complicated by the fact that as of Java 7, you would need to walk the 
entire set of valid Unicode codepoints.  (You know, because Java has super 
crappy support for Unicode properties.)

What steps will reproduce the problem?
1. Try to write something using the mouse
2. Notice there's no way to find out what button is acting
3. Notice there's no way to find out what other buttons are pressed

What is the expected output? What do you see instead?

I would expect the mouse to be usable if there are mouse calls.

Please describe use-case:

When a room or other region is entered/exited on a map, I would like to change 
the sound track, use an alternate palette, or present a message to the user.

While presenting messages is easily included as part of the object or terrain 
framework, music/palette triggers are not something commonly available.

Ideally, it could even be leveraged to start a predefined script using NPCs for 
actors. It could also be useful to mask the normally retained contents of a 
room. (The room has a "thing" in it, but when you leave the room you forget 
that fact. -- Such a feature would be a way to work with the 
room-specific-palette when outside of the room.)

Please describe use-case:

Line-drawing vector graphics that replace standard Unicode codepoints but can 
still be scaled with the font.

These add significant flexibility in terms of what can be done for the display. 
A missing glyph in an otherwise great font can easily be worked around.

Ideally, these would use a subset of SVG for the vector definition so that they 
would be easy to create.

Please describe use-case:

We have PerlinNoise (aka SimplexNoise).

It would be great to add fbmNoise.

Please describe use-case:

We have a BSP tree.

We need code to demonstrate how to use it.

This is complete with the 'dungeon' example and the support classes in the 
com.googlecode.blacken.dungeon package.

We need to finally add support for different cursor shapes.

Outline
Bar
Different block sizes.
Bottom Caret
Top Caret
Top+Bottom Caret
Crosshairs
X

We probably need to make sure different cursor colors and color operations are 
exposed.

We need to verify that full alpha support is enabled for cursors.

We could even support line and/or fill styles. These are far more important for 
cursors than they are for standard operations.

We need to plan for the framework to support multiple cursors even if we don't 
explicitly turn on this feature for this release.

It breaks compatibility with the 1.x line so we should try to fit the framework 
in to 2.x even if some functionality slips.

Please describe use-case:

With Blacken 1.0 we had one function ColorHelpers.saturatePalette() that could 
take a color transformation and apply it to an entire palette.

However, with additional color transformations we should have a more general 
method of applying transformations across a palette.

Please describe use-case:

Right now there are two keys that are used to signal special events in the 
Boarder demo.

They need to be removed.

Instead it should require the mouse to change the keyboard layout and the mouse 
to exit.

Please describe use-case:

Right now the initial window size starts out the same size regardless of 
monitor size. That's a bit overly simplistic.

The idea is to support users with 640x480 displays on 30 inch televisions due 
to vision problems. To support both the low resolution on a massive monitor and 
a super-high resolution on a large high quality monitor the best answer is to 
default to at least a percentage of the window size.

This needs to happen.

We remove the headache of a tiny default window and the headache of a developer 
selecting a default window size that works for them on their 30 inch monitor 
but not the person with the 800x600 display if we use  an enum instead of 
opening up the window bounds. 

The idea is:

START_TINY: ~30% of X/Y; ~10% of display; should be usable next to MEDIUM window

START_SMALL: should be usable 80x25 when 2x2; 25% of display; ~50% of X/Y

START_MEDIUM: ~50% display; ~70% of X/Y

START_LARGE: ~80% display; ~90% X/Y (usable with other large windows that are 
not in focus)

START_MAX: a maximized window

START_FULLSCREEN: a fullscreen window

The default should be usable for the nearly blind, but for folks with full 
vision or massive monitors there's no reason you can't have multiple windows a 
la Angband.

Please describe use-case:

We want to support functional internationalization of Blacken applications.

Roguelike games frequently use a large collection of key-based commands. One 
command == one key.

Additionally, not all keyboards are the same. What are functional keys for one 
keyboard may be unusable on the other. The traditional "roguelike" movement 
keys only make sense on a QWERTY keyboard, though that doesn't mean that having 
movement restricted to the number pad (or cardinal directions) is the best 
choice for the user. (On a laptop neither may be available.)

We have a number of issues:

1. Everyone has their favorite large Roguelike with their preferred keyboard 
mapping. (Nethack, Angband, TOME, ADOM, Larn, Omega, etc.)

2. International users may want to opt for the "feel" of a Roguelike keybinding 
with a US keyboard, even when the actual keys are different.

3. International users may already have an established keybinding for an 
internationalized version of a game.

4. The user may have always exclusively played with a hand-designed keybinding. 
If someone has been playing with hand created keybindings -- while we cannot 
directly support another application's keybinding, we can very easily reduce 
the number of times a Blacken keymap needs to be defined down to one.

The idea is that you would getch(), then pass the codepoint through some sort 
of KeyCommandService that would take that codepoint and convert it to a CMD_* 
codepoint.

I've already given some thought to this. The goal is to both reduce the amount 
of work for developing keymaps as well as the amount of work to implement them. 
Standardization helps.

I'm not even saying that the documentation for a function needs to be 
consistent for a key across all games. Not all functions map cleanly. It's 
possible to overcome this, though. 

The benefits of this are too great to ignore. 

So, game Foobar ships with a custom keymap because the developers think they 
have the best idea for how things should be mapped. Are they going to ship just 
one keymap -- the one for plain-jane QWERTY US? Probably. Should that shut out 
the international market? No it shouldn't. 

Plus, if that keymapping is so great, why should it be restricted to that one 
game? We get cross-game sharable keymaps if we get this right.

I think it's possible to get this right.

Please describe use-case:

It would be nice to be able to easily perform word-wrap -- what with out window 
width potentially being larger than 80 columns.

It would also be nice to have a StringViewer class that automatically wrapped 
the line text.

Please describe use-case:

The AWT Font object is tied directly to the AWT and shouldn't be used in the 
generic interface. As such, we need to support a font name to be given at 
construction so that a "not crappy" font can be used.

If we're going to have it at constructor time, we should support changing the 
font without restarting, too. What's the worst that will happen? The 
rows/columns will change -- possibly resulting in a font-size change. We treat 
it like any other RESIZE event. 

While we can't really support the sorts of font-changing user-interfaces folks 
see with GUI applications, the user's application should be able to present a 
list of viable font candidates and have the user try them out WITHOUT 
restarting.

Please describe use-case:

Simple single-type dungeons are great for digging dungeons.

They're also great for hand-drawn levels.

They tend to suck for actual play, though. For play you usually want a separate 
"thing" assigned to Terrain Item and Monster.

So we should create a TIM (terrain-item-monster) cell and have code to convert 
simple single-type Grids in to full-fledged TIM grids.

Dead keys don't generate usable events right now. 
Compose keys don't generate usable events right now. 
Windows Alt-KeyPad doesn't produce usable events right now.

All of these should produce valid Unicode sequences, but no KeyDown events.

The key event listener needs to be more pragmatic and grab what it needs to 
from the correct location.

Please describe use-case:

Roguelike games tend to feature a lot of dungeons.

BSP trees aid in the development of interesting dungeons.

LibTCOD has BSP tree support.

We need BSP tree support

XLambda, I'm creating this issue so I can reference it in the Blacken 1.1 
release notes.

Add support for a transparent panel which sits above the normal panel which can 
have text with a different resolution (and font size).

Please describe use-case:

We want to be able to easily replace font glyphs with specialized imagery. 
Ideally, this would be glyphs not yet in a particular font.

Looking at the Batik APIs, it looks like you can either use a SVGCanvas -- 
implying a single SVG image in the canvas and not a repeatable SVG image along 
with other SVG images, graphics and fonts -- or you can convert it to a raster 
image.

http://xmlgraphics.apache.org/batik/using/transcoder.html

I think converting it to a raster image may be a good idea. It does mean we'd 
be left with a graphical tile-based game as a possibility. The infrastructure 
to support cached images from the SVG renderings could easily be used to 
support other raster images.

This is acceptable. The fact that it is SVG means the images will normally 
scale cleanly, so if folks really need tile-based graphics, at least they can 
use some that actually look good.

Scren flickers with content for a moment then goes totally grey in OSX.  Moving 
the mouse off the window and back will show content for one frame then back to 
grey

What steps will reproduce the problem?
1. run any of the examples
2. wait a fraction of a second

Attached is a screenshot

Please describe use-case:

Introspection in Java is slow.

The way we copied cells in the Grid class required both introspection and a 
little try-and-fallback.

There are faster ways if we know what type we're copying.

We should have a way of specifying specific cell copiers so that we can speed 
things up.

This is done, but I didn't have a ticket for it.

What steps will reproduce the problem?
1. Try to use the AwtTerminalInterface example
2. Notice that only a small region of the window appears to update

What is the expected output? What do you see instead?

I would expect the window to be minimally useable.

This broke at some point during the "let's take the CursesLikeAPI out of the 
TerminalInterface" changes. Perhaps it fixed itself. Probably not.

More to the point, I want to normalize the AwtTerminalInterface and bring it 
in-line with the primary TerminalInterface. This is sort of a precursor to 
expanding the TerminalInterface away from AWT altogether.

Please describe use-case:

The standard Curses "gets" function is useless because while you're waiting for 
that to return you cannot:

1. handle RESIZE events
2. handle action keys unrelated to input
3. handle mouse events

As such, we need a Blacken getString function that solves these problems -- by 
way of a callback interface.

This was initially started when we got the Blacken 1.0 bug, but it hadn't been 
fleshed out.

Fullscreen functionality is not only an attractive feature to have, but also 
increases libtcod compliance.

Please describe use-case:

We need a reusable pager to display text without overwriting the custom
border.

There are two pieces required for this:

1. A TerminalView which restricts writes within a subsection of a Terminal

2. A simple pager that uses the Terminal View to display a string.

This is useful to display the Blacken Notices file -- required for the Apache 
2.0 license -- when running via JNLP where the end-user doesn't get any 
non-compiled files installed.

What steps will reproduce the problem?
1. Notice that other similar libraries distance themselves from Curses.
2. Notice that Blacken 1.0 tries to mimic the Curses API.
3. Suspect that makes Blacken harder to use than other APIs.

What is the expected output? What do you see instead?

Most of the curses-like functions are implemented using simpler calls.

Split out the Curses-like functions to an overlay that rests on top of a 
simpler terminal interface.

What steps will reproduce the problem?
1. Start a Blacken app
2. Notice initial window size is postage stamp

What is the expected output? What do you see instead?

We expect a window we can immediately use.

Please use labels and text to provide additional information.

If we had a JComponent per AwtCell we could support tooltips on a cell-by-cell 
basis. 

It might be cool to support native tool-tips with cell details for the map.

More importantly, it looks like Java breaks down updates to the smallest number 
of complete components. If this is correct, we would support partial-window 
updates (instead of whole-window refreshes) when the window was partially 
obscured and made visible.

So, if there's a performance boost for this, it should be done. If there's not 
a performance boost the tool-tip thing alone isn't worth it.

This could significantly increases the complexity, though. We would need to add 
or remove children components when the window is resized. 

What steps will reproduce the problem?
1. In any blacken-based application, attempt to print the character U+2588 
(full box, \u2588). 

What is the expected output? What do you see instead?
The character, as well as every other box-drawing character, is printed wider 
than all other characters, not adhering to the fixed width, instead being 
printed in a square shape.

Please describe use-case:

We need global and local configuration file support.

Ideally we need feature-parity in this regard with libtcod.

What steps will reproduce the problem?

1. Notice that Blacken is kind of jerky, skipping screen updates.

What is the expected output? What do you see instead?

I would expect it to update the screen every time I request the screen to be 
updated.

What steps will reproduce the problem?
1. Open a Blacken application
2. resize the window so that it is wide and short (to highlight issue)
3. Move the window so that the top of the window is near the top of the screen
4. Resize the window Up until we hit the Windows Maximize Vertically trigger 
(the window outline will flash the full windows height)
5. Notice that the window is larger, but the contents are the same
6. The application continues to function as if it hasn't been vertically 
maximized at all

What is the expected output? What do you see instead?

I would expect maximizing vertically to work.

This is a bug with some releases of Java 7. (Known to exist at least in 
1.7.0_05 aka "Java 7u5".) 

The exact same steps reproduce the problem in NetBeans.

What steps will reproduce the problem?
1. Notice Blacken is a Maven application
2. Use Maven in your own application
3. Want to leverage the power of Maven to import the correct version of Blacken
4. Find out Blacken isn't in a public Maven repository

What is the expected output? What do you see instead?

We would expect to find Blacken -- the stable releases if not the snapshot -- 
located in a public Maven repository.

Please describe use-case:

Someone writes a roguelike game and wants folks to easily be able to start it 
from a web page.

Please use labels and text to provide additional information.

This looks well-documented online. It is just a matter of implementing it.

What steps will reproduce the problem?
1. Start a Blacken application via JNLP
2. Hit Alt-Enter to go to fullscreen mode
3. Watch the application die.

What is the expected output? What do you see instead?

I expected it to go in to fullscreen mode.

At the very least, I expected it to not die.

Please describe use-case:

Right now we have a basic Perlin Noise function.

We need better texture generation controls.

The texture generation needs to support driving both colors as well as 
monochrome values that can be used to pick terrain features.

There's an LGPL'ed Java texture engine that can be mined for ideas:

http://kenai.com/projects/jtexgen/pages/Home

I don't exactly like some of the approaches it has taken, the license precludes 
its use in closed-source web games (or could at any moment), and so I'm less 
inclined to use the library as-is.

Plus, I think ColorPalette support could be useful.

Please describe use-case:

I'm not sure if UnboundTerminal can be shaped or not.

They need to be shape-able.

I think UnboundTerminal supports this, but this means it also needs to support 
the standard copy-from/copy-into operators.

Please describe use-case:

We need that various core classes to have serialization that can grow and 
change without the sharp limitations of the default Java implementation.

What steps will reproduce the problem?
1. Clear the screen to a c-cedilla as a decomposable character sequence: 
"c\u0327" - note this is correctly rendered on screen
2. Change the "c" to an "o" so that it should render a cedilla on an "O" 
character: "o\u0327" - note that this is valid Unicode and according to the 
Unicode standard such things should be supported.

What is the expected output? What do you see instead?

The combining cedilla character has been confirmed as correct, as it worked 
correctly with the "c" character. When it was combined with the "o" character, 
it appears that it is treating the combining cedilla character as a spacing 
cedilla character. This is a violation of the Unicode standard, and does not 
appear to be happening within Blacken itself but some other component of the 
system.

Interestingly, Eclipse shows the expected problem in the Console output, but 
not in the Debug variable views. Something about the Debug variable view is 
causing it to work correctly.

Please describe use-case:

Java loads slowly.

Splash screens help.

What steps will reproduce the problem?

The current fix to support the display speedup requires additional work to 
unbreak the font attributes. The AttributedString turned in to a total waste of 
time/energy.

What is the expected output? What do you see instead?

I'm thinking of a font container that can appropriately resize the fonts. The 
italic and bold fonts may need to be slightly smaller to support being inside a 
cell. We can also think about supporting different fonts for different Unicode 
block regions. We should be able to handle it in a manner in which we can keep 
the glyph well within bounds of our cell.

Please describe use-case:

Dialogs are pretty common features. We should have a call or two to assist with 
them at some point.

What steps will reproduce the problem?
1. Open a blacken example.
2. Before the window appears, change focus to another window.
3. Try to use the keyboard for input.

What is the expected output? What do you see instead?
It should react to the input, but doesn't.

Please use labels and text to provide additional information.
This has been an issue with libjcsi as well. It can be critical if the 
application has a longer loading time, with many people doing something else 
while waiting for the window to pop up.

This may or may not be related to my platform - I'm running a x64 Win7 with 
JDK7u6.

Please describe use-case:

LibTCOD defines some colors with unique names.

Since adding new color names is easy, this should be done.

Please describe use-case:

It would be really great if we could use palettes that were not in
a proprietary (though really awesome) format.

What about being able to read palettes in the Gimp's palette files?

Please describe use-case:

Add "shadowed" text support.

I expect it to be implemented much like the original xterm bold text. First 
draw black text, then draw the appropriate color on top.

What steps will reproduce the problem?
1. Start the 'dungeon' example
2. Notice that it creates weird two-segment doors instead of one door properly.

What is the expected output? What do you see instead?

I would expect real room doors.

What steps will reproduce the problem?
1. try to use line-drawing characters
2. notice that they don't fit the available space

What is the expected output? What do you see instead?

The expected output is usable line-drawing characters. While the cell walls 
provide an alternative to line-drawing characters, they will remain very 
popular.

The problem stems from the use of the Java default MONOSPACE font. The source 
of the glyphs used for the ASCII letters is different than the source used by 
the line-drawing characters. (MONOSPACE is a composite font, so different 
glyphs come from different source fonts.)

The solution is to default to a single font -- which will give a better result 
for all glyphs -- instead of defaulting to the composite MONOSPACE font.

Please describe use-case:

Frequently there are background animations that can be done. We don't actually 
want to wait forever for a keystroke, we want to wait for a bit, then signal 
that nothing was provided and open the way for some other action.

Instead of having the actual Curses halfdelay function, we can have:

public int getch(int millis);
public boolean keyWaiting();