rails-devel

Re: [Rails-devel] Trains

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

We don't currently "tell" the UI about changes to companies.  

The Paint/Repaint methods are called to draw the UI whenever the values in our Stock model change. The UI then calls the appropriate get methods to obtain the current values of the model.


Also, I've noticed you've forked the API a bit for implementing the map.  Is there a reason we can't just replace the old methods with the newer ones?


---Brett


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Sep 18, 2005 3:00 PM
To: rai...@li...
Subject: [Rails-devel] Trains

I have added Trains. Most options related to buying trains
have been implemented, except
- buying "unlimited" trains,
- cheap exchange for first Diesel,
- train limits (will come when Phases are added),
- dual trains, like 18VA 4/3G or 18Scan 4/3+3.

I am thinking about ways to simplify keeping all data
shown in the UI up to date. Sometimes "deep" changes occur
(such as new trains becoming available), and now the UI
must poll each time a train is bought if such a change has occurred.
The same applies to share prices, cash amounts, and in fact all on-screen
items.

It could be easier to have the values "tell" the UI about any changes.
Two ways to achieve that are
1. Create an Event each time a values changes, and let each and every
UI field listen to changes of its underlying value.
2. An older and IMO simpler way is the Observer/Observable pattern.

The main hurdle is that each such value must get the capability to 
register its own listener(s).
I played a bit with Events and EventListeners but it looks rather heavy to
me.

The simplest solution might be to create Observable subclass types 
(ObservableInteger etc.) and embed values like cash amounts and share
percentages 
in such types.
The UI Field class should then implement Observer,
and each Field instance should register as an Observer of its own
Observable.

Any thoughts about this idea?

Erik.




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Trains

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

> Yes, but my question is if it would be beneficial to change that,
> at least partially: to keep the StatusWindow up to date if
> any action is performed in another window (StartRound, OR).
> So far I have added quite a number of methods to GameStatus
> to allow updates from other windows, and it's a bit of a mess now.
> No real problem, but I was thinking if another way to update 
> GameStatus would be more elegant. 


I'm not really sure it's necessary at this point.  Is there ever a point where the UI is out of sync with the model objects?

I think this might be something that's good to revisit after our initial release. For now, if it's working sufficiently, there's no reason to reinvent the wheel. There's plenty of other tasks needing completion. :-)

 
> Sure we can, but I did not want to destroy your code before mine
> would prove to be better :-)

That's the lovely thing about CVS. Once my code has been committed as a specific file revision number, it's always preserved.   We can always checkout previous versions of files even after you commit changes.  

So, please go ahead and just overwrite existing methods. Yours clearly are working much better. After all, they're correctly displaying the map layout. ;-)


---Brett.

RE: [Rails-devel] Trains

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

> > Sure we can, but I did not want to destroy your code before mine
> > would prove to be better :-)
> 
> That's the lovely thing about CVS. Once my code has been 
> committed as a specific file revision number, it's always 
> preserved.   We can always checkout previous versions of 
> files even after you commit changes.  
> 
> So, please go ahead and just overwrite existing methods. 
> Yours clearly are working much better. After all, they're 
> correctly displaying the map layout. ;-)

They did....

I fixed, committed and updated, and am now getting 
a compilation error in GUIEWHex.java:
"The field AffineTransformOp.TYPE_BICUBIC is not visible"
which prevents EW maps from being displayed.
I suppose this is work in progress.

Erik

RE: [Rails-devel] Trains

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

AH!   Your updates are colliding with mine slightly.   I'm working on getting tile images to display themselves.

Get an updated copy of GUIEWHex and comment out the new Paint() method that i've put there.  It's not quite "done" yet.

I'll commit a less intrusive version here shortly.

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Sep 20, 2005 6:22 PM
To: rai...@li...
Subject: RE: [Rails-devel] Trains

> > Sure we can, but I did not want to destroy your code before mine
> > would prove to be better :-)
> 
> That's the lovely thing about CVS. Once my code has been 
> committed as a specific file revision number, it's always 
> preserved.   We can always checkout previous versions of 
> files even after you commit changes.  
> 
> So, please go ahead and just overwrite existing methods. 
> Yours clearly are working much better. After all, they're 
> correctly displaying the map layout. ;-)

They did....

I fixed, committed and updated, and am now getting 
a compilation error in GUIEWHex.java:
"The field AffineTransformOp.TYPE_BICUBIC is not visible"
which prevents EW maps from being displayed.
I suppose this is work in progress.

Erik




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Trains

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

> We don't currently "tell" the UI about changes to companies.  
> 
> The Paint/Repaint methods are called to draw the UI whenever 
> the values in our Stock model change. The UI then calls the 
> appropriate get methods to obtain the current values of the model.

Yes, but my question is if it would be beneficial to change that,
at least partially: to keep the StatusWindow up to date if
any action is performed in another window (StartRound, OR).
So far I have added quite a number of methods to GameStatus
to allow updates from other windows, and it's a bit of a mess now.
No real problem, but I was thinking if another way to update 
GameStatus would be more elegant. 
 
> Also, I've noticed you've forked the API a bit for 
> implementing the map.  Is there a reason we can't just 
> replace the old methods with the newer ones?

Sure we can, but I did not want to destroy your code before mine
would prove to be better :-)

Erik.