Re: [Rails-devel] delurking with a quick ReportWindow fix

[Erik V. <eri...@hc...>]

Thanks. I'll try it out in the coming days, but on first sight the code
looks good.
I remember I had tried JTextArea before, but can't remember why I abandoned
it. We'll see.

Some answers below.

> > If you know a better way than a JLabel to achieve the same 
> effect, I'd like
> 
> > to know it. This was the only way I could manage it.
> 
> OK, done (appended) and it was much easier than I thought.  
> In the process I destaticified some things, which felt like 
> the right thing to do but please check it over.

Yes, I want to get rid of (most) statics.
 
> > I think a separate and well-readable window report is 
> needed for various
> > reasons, not the least one being that, certainly in 
> internet play, players
> > would like to see a written account of the game actions, 
> not cluttered by
> > other log info. 
> > The format is like game reports I have seen published on 
> the Internet, and
> > indeed intended to be suitable for saving, emailing (PBEM), 
> publishing etc.
> 
> I think a next step might be to have the "game report" be 
> separated from other debug logging by having it be completely 
> regenerable from the same game history that undo uses.  I've 
> lost track--does the undo trail now include the entire game, 
> or are there still unundoable actions that cause it to be truncated?

The fact that the report messages are also added to the log (as INFO)
looks logical to me. I don't see why that should be avoided.

The undo trail indeed covers the whole game, but the actions
contained in it are much more granular: just the movements of 
the game pieces (cards, tokens) and cash, and status variable changes.
I don't think the report messages can be reconstructed from such
low-level movements.

Saving the high-level game actions (PossibleAction instances) 
would have been another option, but that would have required lots
of code to figure out the detailed consequences of those actions
(and undoing these) from a different (post-action) game state 
than is now done from the pre-action state. I did not consider
that to be a viable option.

As undo/redo works now, it's pretty much invisible to the main code.
All that needs be done is to make sure that all changes are applied
by creating an instance of a Move subclass, or by calling a setter
in a State subclass, and to call MoveSet.start() and MoveSet.finish() 
at the right moments. 
The internals of the move package handle all the rest of it.

BTW Talking about reports and undo: currently Undo and Redo just 
write these words to the report. In stead, I would like Undo to 
remove the corresponding lines from the report. But *not* by 
keeping all versions of the whole report window in memory!
I'm looking for a somewhat more intelligent way of linking 
ReportBuffer with MoveSet, so that each MoveSet contains
just the latest addition(s) to the report window.
It should not be too difficult, but I haven't got to it yet.
 
Erik.