rails-devel — List for discussion of Rails development

RE: [Rails-devel] Re: Separation of ORWindow Dependencies.

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

> Ok...  I've commited some additional changes that return the ORWindow
> to fully functioning.

I'm now getting a ClassCastException at UpgradesPanel.mouseClicked, line
216,
when the first tile is laid.
 
> I'm noticing a bit of flicker in StatusWindow.  I'll check and see if
> we're painting it too often.

I see this flickering only in the part of StatusWindow that overlaps with 
the StockChart window, and it seems to be caused by excessive repainting 
of the StockChart, even if nothing has changed there.

Erik.

[Rails-devel] Re: Separation of ORWindow Dependencies.

[brett l. <wak...@gm...>]

Ok...  I've commited some additional changes that return the ORWindow
to fully functioning.

I'm noticing a bit of flicker in StatusWindow.  I'll check and see if
we're painting it too often.


---Brett.


>
> Right now, resizing the ORWindow correctly repaints the window.
> Hopefully, I just need to add some more calls to repaint in the right
> spots to get the ORWindow fully working again.
>

[Rails-devel] Separation of ORWindow Dependencies.

[brett l. <wak...@gm...>]

Unfortunately, I haven't had a lot of time in the last week to finish
working on this.

Currently, all of the underlying methods seem to be working, the only
problem is fixing the many repaint/drawing bugs that have crept in
during this change.

I am going to commit this major change today, despite it not being
quite as seamless a change as I wanted it to be.  If anyone wants to
help squash the repainting bugs before I get to them, they're welcome
to jump on in.

I'm hoping to get some time this weekend to work on finishing off
these changes, if this damned head cold I've got allows me to do
anything.


A quick overview of what's changed:

I've removed all constructor arguments from ORWindow, ORPanel,
UpgradesPanel, and any other children of ORWindow.

I've reduced the visibility of GameUILoader's copy of MapPanel.
There's a suitable get method, but no direct access to mapPanel
anymore.

I've moved a ton of methods upward from sub-Containers into ORWindow.=20
There's still a few methods that I feel are out of place, and have
left comments on some of them, but most of the method placements seem
to fit better now.

The StatusWindow no longer "owns" the ORWindow. The ORWindow obtains
any necessary data from the game model objects rather than from the
StatusWindow.

Where possible, I've left many of the old sections of code commented
out just in case I've pruned too much and something is needed.



Right now, resizing the ORWindow correctly repaints the window.=20
Hopefully, I just need to add some more calls to repaint in the right
spots to get the ORWindow fully working again.


---Brett.

Re: [Rails-devel] Windows .bz2 utiltity?

[<sh...@co...>]

I've tried several methods of getting the CSV files off of Sourceforge.

1)  Tried the Tortoisecsv - couldn't get it to work.
2)  Tried CSV from the command line on my iBook running OS 10.4 - worked fine.
3)  Tried the Eclipse on both XP and Mac OS 10.4 - worked fine on both.  

If one is interested in participating in the project, I'd recommend using Eclipse.  If for no other reason than it is what most people seem to be using, and if you run into problems with it, there's a larger pool of people to draw on for help.

Steve Haugse

Re: [Rails-devel] Screen messages

[brett l. <wak...@gm...>]

On 2/8/06, Erik Vos <eri...@hc...> wrote:
> > The bigger issue that bothers me is that many of these classes have
> > constructors that are pulling data from other UI objects.
> >
> > This strikes me as something that severely breaks model/view
> > separation.
> >
> > For example, the ORWindow shouldn't be passed an OperatingRound, it
> > should be checking GameManager for what the current round is, and
> > whether it's an OperatingRound.
>
> That is right, or whether there isn't any round at all yet
> (which I believe is true when the window is created).
>
> > I've been looking at cleaning this up and making ORWindow behave a bit
> > more like StockChart, but it's looking like the changes are going to
> > be very invasive and require rewriting a bunch of areas of the UI.
>
> Talking about StockChart: a while ago I was getting pretty annoyed by
> double flickering in the StatusWindow after each share Sell or Buy action=
.
> This turned out to be just the area where StatusWindow overlapped
> StockChart.
> It looks like if StockChart is fully repainted twice after each action in
> StatusWindow,
> even if no price has changed at all!
>
> On this point I would prefer to have StockChart behave more like the othe=
r
> windows,
> where only parts are repainted where and when something has changed.
> That would speed up repainting too.


We can just stop calling repaint the second time.  This should clear
up most of the issue.

Though, I do agree (and it's even recommended) to not call the
no-argument repaint(), but instead call one of the repaint methods
with an argument that specifies the region to be repainted.



>
> The ORWindow constructor is way too complicated as it is,
> no doubt it can be simplified.
>

I am working on it.  However, there's a lot of implications to this
change that affects many other areas.  In short, it's highly invasive.

Right now, I've got most of the changes in my local tree, but there's
still a lot of things within the ORWindow that have been broken.

If you like, I can commit my changes so you can help in reworking the
ORWindow, or I can keep working on them privately and commit them
after I've gotten more of the ORWindow working.


---Brett

RE: [Rails-devel] Screen messages

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

> The bigger issue that bothers me is that many of these classes have
> constructors that are pulling data from other UI objects.
> 
> This strikes me as something that severely breaks model/view 
> separation.
> 
> For example, the ORWindow shouldn't be passed an OperatingRound, it
> should be checking GameManager for what the current round is, and
> whether it's an OperatingRound.

That is right, or whether there isn't any round at all yet
(which I believe is true when the window is created).

> I've been looking at cleaning this up and making ORWindow behave a bit
> more like StockChart, but it's looking like the changes are going to
> be very invasive and require rewriting a bunch of areas of the UI.

Talking about StockChart: a while ago I was getting pretty annoyed by 
double flickering in the StatusWindow after each share Sell or Buy action.
This turned out to be just the area where StatusWindow overlapped
StockChart.
It looks like if StockChart is fully repainted twice after each action in
StatusWindow,
even if no price has changed at all!

On this point I would prefer to have StockChart behave more like the other
windows,
where only parts are repainted where and when something has changed.
That would speed up repainting too.

The ORWindow constructor is way too complicated as it is, 
no doubt it can be simplified.

Erik.

Re: [Rails-devel] Windows .bz2 utiltity?

[Jeffrey B. M. <mc...@br...>]

On Tue, Feb 07, 2006 at 10:47:58PM -0500, Dave Mitton wrote:
>=20
> Arggh... I guess that mutates the question to one of the best free=20
> Windows CVS utility?
> GUI preferred.

Snort.

If you don't want one integrated with Eclipse or anything, get

http://www.tortoisecvs.org

It is a set of shell extensions for Windows.  Sourceforge has instructions
directly about toroise on its site, also.

Jeff

--=20
----------------------------------------------------------------------------
Computer Science is as much about computers as astronomy is about telescopes
	-- Edsger Wybe Dijkstra (1930-2002)
----------------------------------------------------------------------------

Re: [Rails-devel] Windows .bz2 utiltity?

[John A. T. <ja...@ja...>]

On Tue, 7 Feb 2006, Dave Mitton wrote:

> Arggh... I guess that mutates the question to one of the best free Windows 
> CVS utility?
> GUI preferred.
>
> (the system I was trying to load this on already has ClearCase and Perforce)

I don't know if those have CVS support, but he mentioned several options 
earlier in his message.  If you are going to be working on Rails, I 
suggest getting Eclipse installed.  I have never tried it on Windows but I 
can't imagine it would be too difficult.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Windows .bz2 utiltity?

[Dave M. <da...@mi...>]

On 2/7/2006 10:12 PM, John A. Tamplin wrote:
>brett lentz wrote:
>
>>Or, you can just do a quick n' dirty mass renaming from the command
>>line to remove the ",v".
>>
>That won't compile, since the RCS file format (which is what CVS 
>uses to store individual files) contains a bunch of meta information 
>and the entire revision history of the file -- just renaming it 
>won't change it into a flat java file of the most recent version.
>
>You really should just use CVS to check it out directly from Sourceforge.
>
>--
>John A. Tamplin                                 ja...@ja...
>770/436-5387 HOME                               4116 Manson Ave
>                                         Smyrna, GA  30082-3723

Arggh... I guess that mutates the question to one of the best free 
Windows CVS utility?
GUI preferred.

(the system I was trying to load this on already has ClearCase and Perforce)

Dave. 

Re: [Rails-devel] Windows .bz2 utiltity?

[John A. T. <ja...@ja...>]

brett lentz wrote:

>Or, you can just do a quick n' dirty mass renaming from the command
>line to remove the ",v".
>  
>
That won't compile, since the RCS file format (which is what CVS uses to 
store individual files) contains a bunch of meta information and the 
entire revision history of the file -- just renaming it won't change it 
into a flat java file of the most recent version.

You really should just use CVS to check it out directly from Sourceforge.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Windows .bz2 utiltity?

[brett l. <wak...@gm...>]

That is, in fact, the correct extension because it's just a raw backup
of the CVS repository filesystem.

For checking the files out of CVS, Sourceforge has a pretty decent
how-to written up.

Eclipse has a handy CVS plug-in. For Windows, there's WinCVS or the
Cygwin utilities as well.

Or, you can just do a quick n' dirty mass renaming from the command
line to remove the ",v".

---Brett


On 2/7/06, Dave Mitton <da...@mi...> wrote:
> Guys,
>         I downloaded your compressed archive, to my XP system, but I didn=
't
> have a utility that could handle .bz2 files.
>
>         I got a copy of QuickZip, but it extracted the files into
> *.java,v   files which don't run well. (yes, the comma and v are in
> the file names!)
>
>         What are you using to pack and unpack these files?
>
> Dave.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Windows .bz2 utiltity?

[Dave M. <da...@mi...>]

Guys,
	I downloaded your compressed archive, to my XP system, but I didn't 
have a utility that could handle .bz2 files.

	I got a copy of QuickZip, but it extracted the files into 
*.java,v   files which don't run well. (yes, the comma and v are in 
the file names!)

	What are you using to pack and unpack these files?

Dave.

Re: [Rails-devel] Screen messages

[brett l. <wak...@gm...>]

On 2/4/06, Erik Vos <eri...@hc...> wrote:
> > I think maybe I'm talking about one thing and meaning another. I
> > tossed off that reply rather quickly from work yesterday, so it
> > probably didn't get as much thought as I should have put into it.
> >
> > I realize that we need to track the state of the UI somehow.  I'm more
> > looking at the organization of the ORWindow.
> >
> > Right now things are a bit of a mess between HexMap, UpgradePanel, and
> > ORWindow.  We have HexMap manipulating things in the UpgradePanel, and
> > UpgradePanel calling a processDone method in HexMap.
> >
> > It's all a bit too... incestuous.
>
> Yes, absolutely.
>
> > I think that HexMap shouldn't need to know about UpgradePanel, and
> > UpgradePanel shouldn't need to know about HexMap. The ORWindow should
> > be taking care of governing that when actions are taken, the proper
> > information is propagated downward to each Panel that needs affecting.
>
> ORWindow is a newcomer, so it's not surprising that its role is limited s=
o
> far.
>
> I agree that these things can best be controlled form one place,
> and I had in fact in mind to choose HexMap for that place, because
> that is where the action is as it comes to tile and token laying.
> Besides, HexMap is guaranteed to survive whatever UI reorganisation we ma=
y
> do
> in the future.
>
> ORPanel is another option, as it has the closes ties to the
> real state machine in the background: OperatingRound. And ORPanel is
> also the place where some of the action buttons are (and I think
> we should move the UpgradesPanel buttons there too, opening UpgradePanel
> only if there are tiles to show).
>
> But I have no real objection against using ORWindow.
>


The bigger issue that bothers me is that many of these classes have
constructors that are pulling data from other UI objects.

This strikes me as something that severely breaks model/view separation.

For example, the ORWindow shouldn't be passed an OperatingRound, it
should be checking GameManager for what the current round is, and
whether it's an OperatingRound.

I've been looking at cleaning this up and making ORWindow behave a bit
more like StockChart, but it's looking like the changes are going to
be very invasive and require rewriting a bunch of areas of the UI.


---Brett.

[Rails-devel] Game end & fixes

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

I have committed code that implements an first version of the Game End
logic.

1. The broken status of the Bank is detected in the Bank class.

2. GameManager checks at the end of each OR, or at the end of
the set of ORs (that is game-dependent) whether the bank has
been broken at any time before (Bank.isBroken()). If so,
the gameOver flag is set.

3. ORPanel.updateStatus() now checks each time whether the
Bank has broken (by calling Bank.isJustBroken()). 
If true, a pop-up is shown with the message 
"Bank is broken. The game will be over after the current set of ORs."
(this message is of course not applicable in all cases, I will fix that
later).

4. ORPanel.updateStatus() now also checks each time when the game has ended
by calling GameManager.isGameOver(). If true, a pop-up "GAME OVER" is shown.
Further wrapping up (such as displaying the player ranking and stopping the
program)
still to be done.

This is a very simple and not yet complete approach of the game end;
we will see if it works or should become a bit more sophisticated. 
Please note that Bankruptcy is not handled yet.

In addition, I have fixed some issues in the ORWindow, such as the
disappearing
message bar and the not-showing of laid tile and token locations.

Erik.

RE: [Rails-devel] End game.

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

> 
> See... I have exactly two problems with the side of the fence the
> three of you are on...
> 
> 1.  The addCash() method is a part of the CashModel, and not the Bank
> object. This means that this boolean is for both breaking the bank AND
> triggering forced purchase/sale actions for players.
> 
> 2. This is not how the current code works. We've been value checking
> things outside of the container classes for a very long time now. If
> you look at Bank, CashModel, and Portfolio, you'll see that none of
> them do this.
> 
> I do think that the approach you guys are advocating is a sound
> approach AND my changes don't disallow it. In fact, it shouldn't be
> difficult to use my change as the first step in building the rest of
> the bank breaking mechanism.

That is what I am doing now, in fact.

Just discovered that the criterion is (or can be) game-dependent,
although I have not yet seen cases where "runs out" is not used.
(I suppose you have followed the discussion in the 18xx group).
I make that the default (so the check will become <0).

Erik.

Re: [Rails-devel] End game.

[brett l. <wak...@gm...>]

On 2/5/06, ia...@co... <ia...@co...> wrote:
> Erik wrote:
> > >
> > > brett lentz wrote:
> > >
> > > It sounds like you are suggesting adjustMoney returns a flag and Bank
> > > doesn't keep any state that it is broken, so it is up to all
> > > the callers
> > > to check the return value and propagate that information to anything
> > > that needs to know it.  Since there are very few places that need to
> > > know the bank is broken (which will also need to check other game-end
> > > conditions), it seems to make more sense to have the Bank object keep
> > > track of whether it is broken and have those few things that
> > > care check
> > > for it rather than checking after every adjustment to the
> > > bank balance.
> > >
> >
> > I agree with John, which is how I would approach it.
> >
> > We also need a mechanism to inform the user that the bank has
> > "just" broken (e.g. via a pop-up). That could be a method that
> > returns true exactly once (Bank.isJustBroken()), but that method should
> > then be called after every action. It's perhaps easier to have
> > the Bank send out an Event or an Observer update call
> > (I prefer the latter, as the mechanism is already being used).
> >
> > Erik.
>
> I agree, the Bank should make the current balance an observable property.=
 A 'GameEndMonitor' can then register itself as a listener of that property=
 of the bank, and if the balance ever goes negative, set the game end flag.=
 This would allow other game end conditons (e.g. player bankruptcy) to be c=
ollected in the same place. You can then easily display the game status ('e=
nding after this OR set'), and you don't need to worry about which action c=
ould cause the bank-breaking event.
>
> Iain.
>


See... I have exactly two problems with the side of the fence the
three of you are on...

1.  The addCash() method is a part of the CashModel, and not the Bank
object. This means that this boolean is for both breaking the bank AND
triggering forced purchase/sale actions for players.

2. This is not how the current code works. We've been value checking
things outside of the container classes for a very long time now. If
you look at Bank, CashModel, and Portfolio, you'll see that none of
them do this.

I do think that the approach you guys are advocating is a sound
approach AND my changes don't disallow it. In fact, it shouldn't be
difficult to use my change as the first step in building the rest of
the bank breaking mechanism.


---Brett.

RE: [Rails-devel] End game.

[<ia...@co...>]

Erik wrote:
> > 
> > brett lentz wrote:
> > 
> > It sounds like you are suggesting adjustMoney returns a flag and Bank 
> > doesn't keep any state that it is broken, so it is up to all 
> > the callers 
> > to check the return value and propagate that information to anything 
> > that needs to know it.  Since there are very few places that need to 
> > know the bank is broken (which will also need to check other game-end 
> > conditions), it seems to make more sense to have the Bank object keep 
> > track of whether it is broken and have those few things that 
> > care check 
> > for it rather than checking after every adjustment to the 
> > bank balance.
> > 
> 
> I agree with John, which is how I would approach it.
> 
> We also need a mechanism to inform the user that the bank has
> "just" broken (e.g. via a pop-up). That could be a method that
> returns true exactly once (Bank.isJustBroken()), but that method should 
> then be called after every action. It's perhaps easier to have
> the Bank send out an Event or an Observer update call
> (I prefer the latter, as the mechanism is already being used).
> 
> Erik.

I agree, the Bank should make the current balance an observable property. A 'GameEndMonitor' can then register itself as a listener of that property of the bank, and if the balance ever goes negative, set the game end flag. This would allow other game end conditons (e.g. player bankruptcy) to be collected in the same place. You can then easily display the game status ('ending after this OR set'), and you don't need to worry about which action could cause the bank-breaking event.

Iain.

RE: [Rails-devel] End game.

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

> 
> brett lentz wrote:
> 
> >>Rather than checking it in every place, it seems like it
> >>would be better
> >>to have the Bank object (or whatever implements the bank)
> >>keep track of
> >>whether it is broken.  Then at the end of an OR you can check
> >>that flag
> >>and end the game or give a warning message.
> >>    
> >>
> >
> >
> >Who said the return value needs to be checked everywhere?
> >
> >There are plenty of transactions already happening that don't check
> >the return value and won't ever need to.
> >  
> >
> If you don't check it, you may miss a case where the bank 
> breaks.  For 
> example, in one step you pay money from the bank and break 
> it.  If that 
> one place doesn't check the return value, a later payment to the bank 
> might hide the fact that the result went negative.
> 
> I am assuming I misunderstand what you intend since otherwise I can't 
> believe you are arguing this point.
> 
> What I have in mind is a singleton class like this (and I 
> have no idea 
> how it is currently implemented):
> 
> public class Bank {
> 	int	balance;
> 	boolean	broken;
> 
> public Bank(int size) {
> 	balance=size;
> 	broken=false;
> }
> 
> public void Bank.adjustMoney(int amount) {
> 	if(balance<amount) {
> 		broken=true;
> 	}
> 	balance-=amount;
> }
> 
> public boolean Bank.isBroken() {
> 	return broken;
> }
> };
> 
> It sounds like you are suggesting adjustMoney returns a flag and Bank 
> doesn't keep any state that it is broken, so it is up to all 
> the callers 
> to check the return value and propagate that information to anything 
> that needs to know it.  Since there are very few places that need to 
> know the bank is broken (which will also need to check other game-end 
> conditions), it seems to make more sense to have the Bank object keep 
> track of whether it is broken and have those few things that 
> care check 
> for it rather than checking after every adjustment to the 
> bank balance.
> 

I agree with John, which is how I would approach it.

We also need a mechanism to inform the user that the bank has
"just" broken (e.g. via a pop-up). That could be a method that
returns true exactly once (Bank.isJustBroken()), but that method should 
then be called after every action. It's perhaps easier to have
the Bank send out an Event or an Observer update call
(I prefer the latter, as the mechanism is already being used).

Erik.

Re: [Rails-devel] End game.

[John A. T. <ja...@ja...>]

brett lentz wrote:

>>Rather than checking it in every place, it seems like it
>>would be better
>>to have the Bank object (or whatever implements the bank)
>>keep track of
>>whether it is broken.  Then at the end of an OR you can check
>>that flag
>>and end the game or give a warning message.
>>    
>>
>
>
>Who said the return value needs to be checked everywhere?
>
>There are plenty of transactions already happening that don't check
>the return value and won't ever need to.
>  
>
If you don't check it, you may miss a case where the bank breaks.  For 
example, in one step you pay money from the bank and break it.  If that 
one place doesn't check the return value, a later payment to the bank 
might hide the fact that the result went negative.

I am assuming I misunderstand what you intend since otherwise I can't 
believe you are arguing this point.

What I have in mind is a singleton class like this (and I have no idea 
how it is currently implemented):

public class Bank {
	int	balance;
	boolean	broken;

public Bank(int size) {
	balance=size;
	broken=false;
}

public void Bank.adjustMoney(int amount) {
	if(balance<amount) {
		broken=true;
	}
	balance-=amount;
}

public boolean Bank.isBroken() {
	return broken;
}
};

It sounds like you are suggesting adjustMoney returns a flag and Bank 
doesn't keep any state that it is broken, so it is up to all the callers 
to check the return value and propagate that information to anything 
that needs to know it.  Since there are very few places that need to 
know the bank is broken (which will also need to check other game-end 
conditions), it seems to make more sense to have the Bank object keep 
track of whether it is broken and have those few things that care check 
for it rather than checking after every adjustment to the bank balance.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

RE: [Rails-devel] Screen messages

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

> I think maybe I'm talking about one thing and meaning another. I
> tossed off that reply rather quickly from work yesterday, so it
> probably didn't get as much thought as I should have put into it.
> 
> I realize that we need to track the state of the UI somehow.  I'm more
> looking at the organization of the ORWindow.
> 
> Right now things are a bit of a mess between HexMap, UpgradePanel, and
> ORWindow.  We have HexMap manipulating things in the UpgradePanel, and
> UpgradePanel calling a processDone method in HexMap.
> 
> It's all a bit too... incestuous.

Yes, absolutely.
 
> I think that HexMap shouldn't need to know about UpgradePanel, and
> UpgradePanel shouldn't need to know about HexMap. The ORWindow should
> be taking care of governing that when actions are taken, the proper
> information is propagated downward to each Panel that needs affecting.

ORWindow is a newcomer, so it's not surprising that its role is limited so
far.

I agree that these things can best be controlled form one place,
and I had in fact in mind to choose HexMap for that place, because
that is where the action is as it comes to tile and token laying.
Besides, HexMap is guaranteed to survive whatever UI reorganisation we may
do
in the future. 

ORPanel is another option, as it has the closes ties to the
real state machine in the background: OperatingRound. And ORPanel is
also the place where some of the action buttons are (and I think
we should move the UpgradesPanel buttons there too, opening UpgradePanel
only if there are tiles to show).

But I have no real objection against using ORWindow.

Erik.

Re: [Rails-devel] Screen messages

[brett l. <wak...@gm...>]

> > > 4. The tile and token laying steps are now explicitly
> > defined (in HexMap),
> > > and the messages are directly related to these steps. The
> > code is somewhat
> > > reorganised around these steps.
> > >
> >
> > I saw this...  I'm not sure I completely agree with the
> > implementation details.
> >
> > I think it may be time to move toward using AbstractActions rather
> > than static integers to interact with the state of the model.
>
> Huh? The integers *are* (better: represent) the state
> (not of the model but of the UI, see below).
> Actions are fine and we already have some. I'm not sure how more
> actions would help us, but I'm open to suggestions.
>


I think maybe I'm talking about one thing and meaning another. I
tossed off that reply rather quickly from work yesterday, so it
probably didn't get as much thought as I should have put into it.

I realize that we need to track the state of the UI somehow.  I'm more
looking at the organization of the ORWindow.

Right now things are a bit of a mess between HexMap, UpgradePanel, and
ORWindow.  We have HexMap manipulating things in the UpgradePanel, and
UpgradePanel calling a processDone method in HexMap.

It's all a bit too... incestuous.

I think that HexMap shouldn't need to know about UpgradePanel, and
UpgradePanel shouldn't need to know about HexMap. The ORWindow should
be taking care of governing that when actions are taken, the proper
information is propagated downward to each Panel that needs affecting.

---Brett.

Re: [Rails-devel] End game.

[brett l. <wak...@gm...>]

On 2/4/06, Erik Vos <eri...@hc...> wrote:
> > brett lentz wrote:
> >
> > >To allow the end game conditions to be detected, I'm changing the
> > >return types to various cash transferring methods from void to
> > >boolean.
> > >
> > >
> > Rather than checking it in every place, it seems like it
> > would be better
> > to have the Bank object (or whatever implements the bank)
> > keep track of
> > whether it is broken.  Then at the end of an OR you can check
> > that flag
> > and end the game or give a warning message.
>


Who said the return value needs to be checked everywhere?

There are plenty of transactions already happening that don't check
the return value and won't ever need to.


---Brett.

RE: [Rails-devel] Screen messages

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

> > 1. A new, low line near the top of the OR Window, in which 
> one-line messages
> > are displayed
> > about what the player can do at each moment in the game. 
> Currently, this
> > message line
> > disappears between token laying and train buying; I don't 
> understand why,
> > but that will no doubt be sorted out in due time.
> 
> 
> Looks like it doesn't disappear completely, it just gets resized very
> very small.

Yes, and I think it's because (against my intentions) an empty
message is displayed. I will sort it out.
 
> I suspect we may need a more formal layout for the ORWindow than
> BoxLayout.  As painful as GridBag is to deal with, it provides the
> most control.

So far BoxLayout looks OK to me.
But, if needed, I'm not afraid of GridBagLayout (as used in the other
windows). 

> > 4. The tile and token laying steps are now explicitly 
> defined (in HexMap),
> > and the messages are directly related to these steps. The 
> code is somewhat
> > reorganised around these steps.
> >
> 
> I saw this...  I'm not sure I completely agree with the 
> implementation details.
> 
> I think it may be time to move toward using AbstractActions rather
> than static integers to interact with the state of the model.

Huh? The integers *are* (better: represent) the state 
(not of the model but of the UI, see below).
Actions are fine and we already have some. I'm not sure how more
actions would help us, but I'm open to suggestions. 

Actions and states are different things, I trust I don't need to elaborate
on that.

What I have done is making the UI-specific states in tile laying more
explicit
for the immediate purpose of displaying the right prompt.
These states are UI-specific because these are not represented in the Model.
(All actions in tile laying are provisional until the "Lay Tile"
button is pressed; only then the Model is informed.
In a future on-line gaming version that would mean, that a player
can toy around with the tiles until the decision is made final.
Only then will the server and the other players be informed.
Does that sound right?)

I know that you have approached token laying differently
(the Model is informed about all actions). I still believe we should change 
this approach at some point in time, and so I've nevertheless
included the (two) token laying substeps in the UI state 'machine'.

Erik.

RE: [Rails-devel] End game.

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

> brett lentz wrote:
> 
> >To allow the end game conditions to be detected, I'm changing the
> >return types to various cash transferring methods from void to
> >boolean.
> >  
> >
> Rather than checking it in every place, it seems like it 
> would be better 
> to have the Bank object (or whatever implements the bank) 
> keep track of 
> whether it is broken.  Then at the end of an OR you can check 
> that flag 
> and end the game or give a warning message.

I agree. 
Erik.

Re: [Rails-devel] End game.

[John A. T. <ja...@ja...>]

brett lentz wrote:

>To allow the end game conditions to be detected, I'm changing the
>return types to various cash transferring methods from void to
>boolean.
>  
>
Rather than checking it in every place, it seems like it would be better 
to have the Bank object (or whatever implements the bank) keep track of 
whether it is broken.  Then at the end of an OR you can check that flag 
and end the game or give a warning message.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723