RE: [Rails-devel] OR updates

[Brett L. <wak...@ea...>]

>> My main point was that the process of changing the model, 
>> then redrawing the affected UI components ought to be just 
>> fine for the ORWindow.  If the game-specific logic is getting 
>> in the way of the drawing code, that could be moved into a 
>> separate controller class, so that the drawing code just 
>> reflects decisions made in the controller class. 
>> 
>> Enabling and disabling panels and buttons automatically calls 
>> the objects' repaint() method. I don't see why redrawing the 
>> window is a thing to be avoided.

>It could be a matter of taste, but I find redrawing not very pretty
>for the eye. I fact, earlier this week I discovered, that the StartWindow
>(and perhaps also the ORWindow) were completely recreated after each
>action, because of a bug in StartWindow. 
>I have fixed that and to me it looks a lot quieter now.
>I admit that repaint() is probably not as bad as such a complete
>replacement.
>But I also think that in the StockChart it does not matter much 
>because its squares have a fixed size, but that is not so in the other
>windows.


This is exactly the right sort of optimizations needed to make repainting fast.

The way repaint() is intended to work is to draw only the segments that need updating, and to leave the rest as is.

HexMap's painting methods signals to each GUIHex to have each hex paint itself based on the rectangular bounding box that surrounds the hex.

Every time we repaint the map, we're repainting every single hex.



>> However, I really hope you're not proposing to start 
>> refactoring our code into client and server before the game 
>> code is complete.

>Hmm, to me this is exactly what we have been preparing ourselves
>for from the start by applying a strict model/view separation!

Agreed, but I'm hoping you'll wait to start writing networking code until after we've gotten the hotseat game working. ;-)

> And to enable use of repaint() in the Status, Start and OR windows
> I'll have to do some changes anyway.

This is probably a good thing to do.  It makes sense to leverage the infrastructure Sun has built for us rather than to reinvent the wheel.

Take note of Sun's guidelines for painting: http://java.sun.com/products/jfc/tsc/articles/painting/index.html

The custom drawing code should be placed into paintComponent(), which is one of the three methods that calls to paint() and repaint() are factored into.

I'm fairly certain that HexMap and GUIHex work in this fashion.


>All variable screen elements in these windows are classes in the ui.elements
>package, and each one could repaint() itself if it would know where to find
>its value. Currently these elements have no reference to a model class, 
>so the value to paint must be provided from the outside.


That's fine.  When painting is requested, we can either pass the elements the location of the information, or they can be taught to know where it is on their own.  I think either method is acceptable.


>It seems to me that both in your approach and in mine each screen element
>*needs* a reference to a model class, where it could retrieve its
>value from: 
>- in your approach to retrieve the value it should display on a repaint,
>- in mine to retrieve a new value to display after a signal from the model
>(to which it has registered as an Observer before).

>So I think both approaches would benefit from a model/view connection on
>a granular level, i.e. for each value to be displayed.

>Seen this way, the Observer pattern would be just a slight extension
>from a model/view connection that we have to create anyway!

>My proposal is that I rework the three windows mentioned to use repaint(),
>passing each field an additional reference to a model class embedding
>the value to be displayed. So that would streamline things your way.
>And I can throw away the laborious partial window update methods
>that I have been creating up to now, and that I want to get rid of.

>Once that is done, it would be a minor extension to add the Observer pattern
>on top of that. If only as an experiment so see if it makes any difference.

>How about that?

Sounds good.  Once you start working with using repaint() I think you'll find that adding on Observers will be unnecessary because the painting system already provides the notification to each object that uses the common painting methods. 

In other words, when we set a HexMap as visible, HexMap's paint() method is invoked. Because HexMap is a JFrame, it also invokes the paint() method of every Swing object beneath itself. So, HexMap will call the paint() method of the JScrollPane we use, and in turn, the JScrollPane will call the paint() method of the JPanel contained within its Viewport, which in turn calls the paint() methods of each GUIHex in the panel.

So, as you can see, the fundamental question that you're trying to answer for ORWindow, "When do I draw things?" is answered with, "Whenever someone calls your paint() method."

Does that make sense?

---Brett.