rails-devel

[Rails-devel] Screen messages

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

I have committed stuff around messages to be displayed during the game.
For now, during the OR only. Aspects are:

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.

2. The messages are internationalised by defining these in a
language-dependent
properties file. The default file is LocalisedText.properties. Versions for
any
language/country can be added with names like LocalisedText_en_US.properties
or LocalisedText_fr.properties.
In the code, localised messages can be obtained by calling
Game.getText(messageKey).

3. Messages about special properties that can be exercised will be added
later,
I propose in a somewhat lighter colour.

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.

Erik.

Re: [Rails-devel] Screen messages

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

I finally got a chance to check out the changes...

Overall, I like the helper text bar. It's exactly what the UI was needing.

More comments below...


On 2/2/06, Erik Vos <eri...@hc...> wrote:
> I have committed stuff around messages to be displayed during the game.
> For now, during the OR only. Aspects are:
>
> 1. A new, low line near the top of the OR Window, in which one-line messa=
ges
> 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.

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.


> 2. The messages are internationalised by defining these in a
> language-dependent
> properties file. The default file is LocalisedText.properties. Versions f=
or
> any
> language/country can be added with names like LocalisedText_en_US.propert=
ies
> or LocalisedText_fr.properties.
> In the code, localised messages can be obtained by calling
> Game.getText(messageKey).
>

Uh oh.  You've let the genie out of the bottle. ;-)

Now we're going to have to go through and internationalize all of our strin=
gs.

There's a few new people to the list... this would be a GREAT project
for a newbie. It would provide them a good opportunity to learn their
way around our code.


>
> 3. Messages about special properties that can be exercised will be added
> later,
> I propose in a somewhat lighter colour.
>
> 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 somewha=
t
> reorganised around these steps.
>

I saw this...  I'm not sure I completely agree with the implementation deta=
ils.

I think it may be time to move toward using AbstractActions rather
than static integers to interact with the state of the model.


---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] 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] 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...>]

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.

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] 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