rails-devel — List for discussion of Rails development

Re: [Rails-devel] rails-package rails.ui.swing SVG revenue

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

 

> > IMHO the package name changes (prepending 'rails.')
> > is worth doing now, better than later.

<snip>

> > However, I leave the decision to Brett.
> > One of us should do it, as only the two of us can commit code now.
> > I'm prepared to do the package name changes next Sunday,
> > but it's equally fine to me drop the whole issue.
> >
 
> I might have time this weekend to do it. If not, it can 
> happen next weekend.

Brett, I haven't heard your verdict on this one,
and I'm staying away from the code until I know
if and when this will be done (by you or me).

Erik.

Re: [Rails-devel] Comments on Patch for Disclaimer, UserConfirmation and new Main-Class

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

(Some parts removed)

> I have need the LocalizedText to get the language. There are 
> instance-ethods
> to get it, but since you never instanciated the class, I 
> could not used it.
> Since I try to avoid a complete refatoring, I used this work-a-round
> instead.

OK.
 
> > 
> >When creating a server (see below) we might want to create an
> >instance 
> >(or a Properties map) per locale, but even then all of this should
> >IMO be 
> >managed internally. 
> >
> So a german and an japanese user could not play together? - 
> no good idea.

I said: per locale, not: per game.

But you make a very good point.
Nothing prevents us to send different players of the same game
messages in their own languages. It only means, that we will
have to postpone localisation of messages generated in the
server. 

> >> - getLogger() 
> >> Can be also in Util. I put it in here, because it is a 
> >> rails-spezifig way 
> >> to log. 
> >> Find the Logger over a Method makes it easiar to change the
> >fist 
> >> desission to log on package-level. 
> > 
> >Sorry, I don't understand at all what you are trying to say here. 
> When you start to introduce log4j in devel-rails, you talk about the
> posibility to create a logger for each class (or even instance),
> but for rails, it should be enough, to have a logger at package-level.
> 
> To create a logger on a defined way would be a good think, I 
> thought. So why
> writting at each class the same code to get the package name 
> and create a
> logger, 
> if we can write a central method, with just need the class or 
> an instance of
> it, to get the logger?

Aha, so you replace Logger.getLogger(Classname.class.getPackage().getName())
by Util.getLogger(Classname.class)?

I can't deny that it looks a bit better. On the other hand, 
creating a separate utility for saving two method calls
per class hierarchy does not really looks like worth the effort to me.
(It does not occur in each class, only in top-level classes.)
But if you feel better with this utility, no problem.
 
> > 
> >> - VERSION 
> >> Final variables should be written in upper letters
> >(Sun-Conversion) 
> > 
> >I thought that *constants* should be written in upper case. 
> >The question is whether 'version' is really a constant. 
> >One can also see it as a variable that, once assigned, cannot be
> >changed - 
> >but the value is different in each release. 
> > 
> >But if you say that this is nitpicking, I agree, 
> >and I have no real problem with making it upper case. 
> >
> It was just an example. If you look at the code, you find 
> diffrent styles
> and naming-praxis, with makes it harder to understand it.

Absolutely. Brett and I have quite different styles,
and I'm certainly not as consistent as I should be.
We are learning...

> Writing constants in upper letter is just one think, with 
> should know most
> coders and most coders follows.
> Anyway, when I will come to the project, you will see that I 
> will make such
> easy avoidable mistakes also. - don't bother.

Yes, we all do.

> >> - Config (comment) 
> >> - Much better not as static class, So you can have userConfig
> >and 
> >> systemConfig. Both should than accessed by RailsSystem or maybe
> >better 
> >> Util-Methods 
> > 
> >I was thinking it would be easier to have all (user and system) 
> >properties in one Properties map, so that the programmer need 
> >not worry about where a property is exactly defined. 
> >We could then also easily move properties between property files 
> >if that would suit us better. 
> > 
> >We definitely need static access to properties, otherwise we'll 
> >have to push around another instance reference. 
> >I have no real problem to replace Config.get() by Util.getConfig(), 
> >but I don't see the benefit either. To me, it's just an extra layer 
> >of indirection. 
> >
> If we need system.properties we should not put it into the 
> user.properties,
> becouse the user should normaly not see it or change it.

I don't want to merge property files. 
I do want to read their contents into the same map.
That is a different thing. Why would we not do that?

> >> - Where do you define the default-values? (if the file is 
> >> coruppted by 
> >> the user) 
> > 
> >Where needed, defaults are specified where the properties are used 
> >when they turn out to be null or empty. 
> > 
> So if you need the default more then ones, you defined it 
> more then ones? -
> Bad idea.

No, then I would encapsulate the property.
Come on, you are jumping to wrong conclusions much too easily.

> >Not every property has an explicit and fixed default value. 
> >The default money amount format is game-dependent. 
> >The default language is (British) English, because the default 
> >resource bundle is written in that language. 
> >The default log4j properties are (by definition) empty. 
> >Etc. 
> If there are no defaults - OK, but if there are, why not using a
> property-file for it too.
> the resource bundle has a default one (with no language extension).

Of course we could create a file with default property values.
It looks like overkill to me, compared with hardcoding defaults,
(also because users can tweak a defaults file too) but maybe I'm wrong.  

> >> - CodeStyle (comment) 
> >> - public and protected variables: You are much to 
> >> broadminded with it. 
> >> You should capsulate as much as possible, using getter- and 
> >> setter-methods 
> >> for access. 
> > 
> >One problem I have with Java is, that you cannot distinguish 
> >between variables that may only be visible to subclasses, 
> >and variables that may be visible to all classes within a package. 
> >Both are "protected". 
> - protected: means only for subclasses
> - private: only for class and private or anonym classes in 
> the same file
> - 'none': package wide with does not include subclasses in 
> other packages

The Sun Java Tutorial says: 
The protected modifier specifies that the member can only be accessed 
within its own package (as with package-private) and, in addition, 
by a subclass of its class in another package.

That "within its own package" I don't like, so that it why I use 
getters within a package too.
 
> >I agree that in principle there should not be public variables. 
> >Do we really have sinned as much as you seem to imply? 
> >It is possible that I have not always been consistent, 
> >so I would appreciate your examples of wrong use of public etc. 
> For example, all windows (views) are public, so I guess you 
> call them direct
> from the gmae-classes (model).

No, the UI classes are in control, and pull all info from the game classes.
The only exception is the use of the Observer pattern
to keep the UI fields up to date. But here also the UI Observer
must register at the game Observable. 

So it might very well be true that the UI classes don't need to be public.
Your fault, Brett... ;-)

> >Several parts of the code need to be able to find out in which turn, 
> >round or phase the game is (this all may have changed 
> >any moment, e.g. while processing a train buy). 
> >So there must be some central point of inquiry about all 
> >aspects of the game state.
> A central controller and interfaces

Yes. 

In the game package we are in fact not far from having a controller,
I think we only have to reorganise the Game and GameManager 
static and instance methods, and make clear which one the real 
controller is (I think it is GameManager).

In the UI I suppose we need a separate controller (if only
to work towards a client/server system), and that could be harder.
The UI control functions are pretty much a mess now.

I'm currently redoing the UI/game interfaces partly to try cleaning that up.

> >In my experience, things usually become clear when the time is ripe. 
> Thats the way I have coded in the 80's. On a very large 
> project (and I think
> this is a large project - at least what the final vision is),
> I was stucked in the code, with becomes unchangeable and had 
> to start from
> the beginning again, 

In principle true, but in reality I don't have such bad
experiences. I keep refactoring, and I also like to think
that I have a pretty good intuition for good structure. 
(Not that it always shows, you will respond, and you're right!)

Erik.

[Rails-devel] Patch for Disclaimer and new Main-Class

[Rainer M. <rai...@we...>]

### Eclipse Workspace Patch 1.0
#P rails
Index: util/LocalText.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/rails/18xx/util/LocalText.java,v
retrieving revision 1.5
diff -u -r1.5 LocalText.java
--- util/LocalText.java	18 Jan 2007 18:12:10 -0000	1.5
+++ util/LocalText.java	22 Jan 2007 20:42:32 -0000
@@ -19,6 +19,40 @@
=20
 	protected static Logger log =3D =
Logger.getLogger(LocalText.class.getPackage().getName());
=20
+   public LocalText(){
+      // do nothing
+   }
+
+   public static ResourceBundle getLocalisedText(){
+      /* Load the texts */
+      if (localisedText =3D=3D null)
+      {
+         /* Check what locale has been configured, if any.
+          * If not, we use the default assigned above.
+          */
+         String item;
+         if (Util.hasValue(item =3D Config.get("language"))) {
+            language =3D item.toLowerCase();
+         }
+         if (Util.hasValue(item =3D Config.get("country"))) {
+            country =3D item.toUpperCase();
+            localeCode =3D language + "_" + country;
+         }
+         if (Util.hasValue(item =3D Config.get("locale"))) {
+            localeCode =3D item;
+            if (localeCode.length()>=3D2) language =3D =
localeCode.substring(0,2);
+            if (localeCode.length()>=3D5) country =3D =
localeCode.substring(3,5);
+         }
+         log.debug ("Language=3D"+language+", country=3D"+country
+               +", locale=3D"+localeCode);
+        =20
+         /* Create the locale and get the resource bundle. */
+         locale =3D new Locale(language, country);
+         localisedText =3D ResourceBundle.getBundle("LocalisedText", =
locale);
+      }
+      return localisedText;
+   }
+
 	public static String getText(String key) {
 	    return getText (key, null);
 	}
@@ -34,32 +68,6 @@
 		if (key =3D=3D null || key.length() =3D=3D 0)
 			return "";
=20
-		/* Load the texts */
-		if (localisedText =3D=3D null)
-		{
-			/* Check what locale has been configured, if any.
-			 * If not, we use the default assigned above.
-			 */
-			String item;
-			if (Util.hasValue(item =3D Config.get("language"))) {
-				language =3D item.toLowerCase();
-			}
-			if (Util.hasValue(item =3D Config.get("country"))) {
-				country =3D item.toUpperCase();
-				localeCode =3D language + "_" + country;
-			}
-			if (Util.hasValue(item =3D Config.get("locale"))) {
-				localeCode =3D item;
-				if (localeCode.length()>=3D2) language =3D =
localeCode.substring(0,2);
-				if (localeCode.length()>=3D5) country =3D =
localeCode.substring(3,5);
-			}
-			log.debug ("Language=3D"+language+", country=3D"+country
-					+", locale=3D"+localeCode);
-		=09
-			/* Create the locale and get the resource bundle. */
-			locale =3D new Locale(language, country);
-			localisedText =3D ResourceBundle.getBundle("LocalisedText", locale);
-		}
=20
 		/* If the key contains a space, something is wrong, check who did =
that! */
 		if (key.indexOf(" ") > -1)
@@ -77,7 +85,7 @@
 		/* Find the text */
 		try
 		{
-			result =3D localisedText.getString(key);
+			result =3D LocalText.getLocalisedText().getString(key);
 		}
 		catch (MissingResourceException e)
 		{
Index: util/Util.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/rails/18xx/util/Util.java,v
retrieving revision 1.9
diff -u -r1.9 Util.java
--- util/Util.java	18 Jan 2007 18:12:10 -0000	1.9
+++ util/Util.java	22 Jan 2007 20:42:32 -0000
@@ -82,4 +82,17 @@
 			return null;
 		}
 	}
+  =20
+   /**
+    * Are two objects equal?
+    * You will not get a NullPointerException if value is null, as you =
get by value.equals(equalValue))
+    * @param value
+    * @param equalValue
+    * @return true, if value.equals(equalValue) or both are null
+    */
+   public static boolean isEqual(Object value, Object equalValue)
+   {
+      return (value =3D=3D equalValue || (value !=3D null && =
value.equals(equalValue)));
+   }
+
 }
Index: ui/StatusWindow.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/rails/18xx/ui/StatusWindow.java,v
retrieving revision 1.59
diff -u -r1.59 StatusWindow.java
--- ui/StatusWindow.java	12 Jan 2007 22:51:31 -0000	1.59
+++ ui/StatusWindow.java	22 Jan 2007 20:42:32 -0000
@@ -9,6 +9,8 @@
 import java.awt.event.*;
 import javax.swing.*;
=20
+import rails.ui.swing.AboutDialog;
+
 import java.util.List;
=20
 import util.LocalText;
@@ -30,6 +32,7 @@
     protected static final String SELL_CMD =3D "Sell";
     protected static final String DONE_CMD =3D "Done";
     protected static final String SWAP_CMD =3D "Swap";
+    protected static final String ABOUT_CMD =3D "About";
=20
 	private JPanel buttonPanel;
 	private GameStatus gameStatus;
@@ -58,7 +61,7 @@
 	JPanel pane =3D new JPanel(new BorderLayout());
=20
 	private JMenuBar menuBar;
-	private static JMenu fileMenu, optMenu, moveMenu;
+	private static JMenu fileMenu, optMenu, moveMenu, helpMenu;
 	private JMenuItem menuItem, undoItem, redoItem;
=20
 	/**
@@ -75,10 +78,12 @@
 		fileMenu =3D new JMenu(LocalText.getText("FILE"));
 		optMenu =3D new JMenu(LocalText.getText("OPTIONS"));
 		moveMenu =3D new JMenu(LocalText.getText("MOVE"));
+      helpMenu =3D new JMenu(LocalText.getText("MenuHelp"));
=20
 		fileMenu.setMnemonic(KeyEvent.VK_F);
 		optMenu.setMnemonic(KeyEvent.VK_O);
 		moveMenu.setMnemonic(KeyEvent.VK_M);
+      helpMenu.setMnemonic(KeyEvent.VK_H);
=20
 		menuItem =3D new JMenuItem(LocalText.getText("SAVE"));
 		//menuItem.setName(SAVE_CMD);
@@ -153,14 +158,21 @@
 	=09
 		menuBar.add (moveMenu);
=20
+      menuItem =3D new =
JMenuItem(LocalText.getText("MenuItemAboutRails"));
+      menuItem.setActionCommand(ABOUT_CMD);
+      menuItem.setMnemonic(KeyEvent.VK_A);
+      menuItem.addActionListener(this);
+      helpMenu.add(menuItem);
+
+      menuBar.add(helpMenu);
+
 		setJMenuBar(menuBar);
 	}
=20
 	public StatusWindow()
 	{
 		cm =3D Game.getCompanyManager();
-		companies =3D (PublicCompanyI[]) cm.getAllPublicCompanies()
-				.toArray(new PublicCompanyI[0]);
+		companies =3D (PublicCompanyI[]) =
cm.getAllPublicCompanies().toArray(new PublicCompanyI[0]);
 		ipo =3D Bank.getIpo();
 		pool =3D Bank.getPool();
=20
@@ -487,7 +499,11 @@
 		    MoveSet.redo();
 		    updateStatus();
 			return;
-		}=20
+		} else if (actor.getActionCommand().equals(ABOUT_CMD))
+		{
+         new AboutDialog(this, true);
+         return;
+      }
=20
 		ReportWindow.addLog();
=20
Index: LocalisedText.properties
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/rails/18xx/LocalisedText.properties,v
retrieving revision 1.24
diff -u -r1.24 LocalisedText.properties
--- LocalisedText.properties	18 Jan 2007 18:12:09 -0000	1.24
+++ LocalisedText.properties	22 Jan 2007 20:42:32 -0000
@@ -1,3 +1,7 @@
+AboutDialogNameLabel=3DProgram name
+AboutDialogVersionLabel=3DVersion
+AboutDialogDisclaimerLabel=3DDisclaimer
+AboutDialogCloseButton=3DClose
 ALL=3DAll
 ALL_PASSED=3DAll players have passed.
 ALSO_GETS=3D{0} also gets {1}
@@ -80,6 +84,7 @@
 ComponentManagerNotReconfigured=3DCannot reconfigure the =
ComponentManager.
 ComponentManagerNotYetConfigured=3DComponentManager has not yet been =
configured.
 ConfirmToken=3DPress Lay Token to confirm token, click another city =
hex, or press the No Token button.
+Disclaimer=3DRails is a Java clone of the '18xx'-style games produced =
by \nMayfair Games(tm), Avalon Hill(tm), David Hecht, John Galt, Francis =
Tresham, and various other authors. \nAll rights reserved by the =
respective owners. \nNo challenge to their status is intended. \n\nRails =
is intended as a play aid for owners of each respective boardgame. =
\n\nIf you are a copyright owner of one of the games, \nand want us to =
remove the version of your game from this program, \nplease write an =
email to rai...@so.... \n We will remove your version as =
soon as posible.
 DoesNotExist=3DItem does not exist
 DoesNotHaveTheShares=3DDoes not have the shares
 Done=3DDone
@@ -136,6 +141,8 @@
 LaysTileAtFor=3D{0} lays tile #{1} at hex {2} for {3}
 MAP=3DMap
 MARKET=3DStock Market
+MenuHelp=3DHelp
+MenuItemAboutRails=3DAbout Rails
 MINIMUM_BID=3D<html>Min.<br>Bid</html>
 MOVE=3DMove
 NegativeAmountNotAllowed=3DNegative amount {0} not allowed
@@ -253,6 +260,7 @@
 UnnamedStockSpace=3DUnnamed stock space found.
 UnnamedStockSpaceType=3DUnnamed stock space type found.
 UpgradeNotFound=3DTile {0}: upgrade {1} not found
+UserConfirmation=3DI own the choosen boardgame and will use the =
programm as a play aid.
 VariantIs=3DVariant is {0}.
 WHICH_PRICE=3DWhich price?
 WHICH_PRIVATE=3DWhich Private?
Index: README
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/rails/18xx/README,v
retrieving revision 1.1
diff -u -r1.1 README
--- README	7 Mar 2005 23:39:13 -0000	1.1
+++ README	22 Jan 2007 20:42:32 -0000
@@ -14,3 +14,18 @@
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, =
USA.
+
+
+Disclaimer:
+Rails is a Java clone of the '18xx'-style games produced by
+Mayfair Games(tm), Avalon Hill(tm), David Hecht, John Galt,=20
+Francis Tresham, and various other authors.
+All rights reserved by the respective owners.
+No challenge to their status is intended.
+
+Rails is intended as a play aid for owners of each respective =
boardgame.
+
+If you are a copyright owner of one of the games,
+and want us to remove the version of your game from this program,
+please write an email to rai...@so....
+We will remove your version as soon as posible.
\ No newline at end of file
Index: rails/ui/swing/AboutDialog.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: rails/ui/swing/AboutDialog.java
diff -N rails/ui/swing/AboutDialog.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ rails/ui/swing/AboutDialog.java	1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,158 @@
+package rails.ui.swing;
+
+import java.awt.AWTEvent;
+import java.awt.Color;
+import java.awt.Container;
+import java.awt.GridBagConstraints;
+import java.awt.GridBagLayout;
+import java.awt.Insets;
+import java.awt.event.ActionEvent;
+import java.awt.event.ActionListener;
+import java.awt.event.WindowAdapter;
+import java.awt.event.WindowEvent;
+
+import javax.swing.JButton;
+import javax.swing.JDialog;
+import javax.swing.JFrame;
+import javax.swing.JLabel;
+import javax.swing.JPanel;
+import javax.swing.JTextArea;
+
+import rails.RailsSystem;
+import util.LocalText;
+
+/**
+ * Shows the About Dialog
+ * @author Rainer
+ *
+ */
+public class AboutDialog extends JDialog
+{
+
+   /**
+    ** Creates new About Dialog
+    */
+   public AboutDialog(JFrame parent, boolean modal)
+   {
+      super(parent, modal);
+      this.initGUI();
+      this.pack();
+      this.setVisible(true);
+   }
+
+   /**
+    ** This method is called from within the constructor to initialize =
the dialog.
+    */
+   private void initGUI()
+   {
+      // Dialog
+      this.setTitle(LocalText.getText("MenuItemAboutRails"));
+      this.setResizable(false);
+
+      Container contentPane =3D getContentPane();
+      contentPane.setLayout(new GridBagLayout());
+
+      // Picture
+      JLabel picture =3D new JLabel(RailsSystem.getRailsImage());
+      contentPane.add(picture, new GridBagConstraints(0, 0, 1, 1, 0.0, =
0.0,
+                                                      =
GridBagConstraints.CENTER, GridBagConstraints.NONE,
+                                                      new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                 =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_NONE),
+                                                      0, 0));
+
+      // Informationen
+      JPanel infoPane =3D new JPanel();
+      infoPane.setLayout(new GridBagLayout());
+     =20
+      JLabel    prgNameLabel =3D new =
JLabel(LocalText.getText("AboutDialogNameLabel") + ":");
+      JTextArea prgNameInfo  =3D new JTextArea(RailsSystem.getName());
+      prgNameInfo.setEnabled(false);
+      prgNameInfo.setDisabledTextColor(Color.BLACK);
+      infoPane.add(prgNameLabel, new GridBagConstraints(0, 0, 1, 1, =
0.0, 0.0,
+                                                        =
GridBagConstraints.NORTHWEST, GridBagConstraints.NONE,
+                                                        new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                   =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_NONE),
+                                                        0, 0));
+      infoPane.add(prgNameInfo , new GridBagConstraints(1, 0, 1, 1, =
1.0, 0.0,
+                                                        =
GridBagConstraints.NORTHWEST, GridBagConstraints.HORIZONTAL,
+                                                        new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                   =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_NONE),
+                                                        0, 0));
+
+      JLabel    versionLabel =3D new =
JLabel(LocalText.getText("AboutDialogVersionLabel") + ":");
+      JTextArea versionInfo  =3D new =
JTextArea(RailsSystem.getVersion());
+      versionInfo.setEnabled(false);
+      versionInfo.setDisabledTextColor(Color.BLACK);
+      infoPane.add(versionLabel, new GridBagConstraints(0, 1, 1, 1, =
0.0, 0.0,
+                                                        =
GridBagConstraints.NORTHWEST, GridBagConstraints.NONE,
+                                                        new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                   =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_NONE),
+                                                        0, 0));
+      infoPane.add(versionInfo , new GridBagConstraints(1, 1, 1, 1, =
1.0, 0.0,
+                                                        =
GridBagConstraints.NORTHWEST, GridBagConstraints.HORIZONTAL,
+                                                        new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                   =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_NONE),
+                                                        0, 0));
+
+      JLabel    disclaimerLabel =3D new =
JLabel(LocalText.getText("AboutDialogDisclaimerLabel") + ":");
+      JTextArea disclaimerInfo  =3D new =
JTextArea(LocalText.getText("Disclaimer"));
+      disclaimerInfo.setEnabled(false);
+      disclaimerInfo.setDisabledTextColor(Color.BLACK);
+      infoPane.add(disclaimerLabel, new GridBagConstraints(0, 2, 1, 1, =
0.0, 0.0,
+                                                        =
GridBagConstraints.NORTHWEST, GridBagConstraints.NONE,
+                                                        new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                   =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_NONE),
+                                                        0, 0));
+      infoPane.add(disclaimerInfo , new GridBagConstraints(1, 2, 1, 1, =
1.0, 0.0,
+                                                        =
GridBagConstraints.NORTHWEST, GridBagConstraints.HORIZONTAL,
+                                                        new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                   =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_NONE),
+                                                        0, 0));
+
+
+      contentPane.add(infoPane, new GridBagConstraints(1, 0, 1, 1, 1.0, =
1.0,
+                                                       =
GridBagConstraints.CENTER, GridBagConstraints.BOTH,
+                                                       new =
Insets(SwingUtil.INSETS_TL_MEDIUM, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                  =
SwingUtil.INSETS_BR_NONE, SwingUtil.INSETS_BR_MEDIUM),
+                                                                  0, =
0));
+
+      // okButton
+      JButton okButton  =3D new =
JButton(LocalText.getText("AboutDialogCloseButton"));
+      okButton.setSelected(true);
+      okButton.setDefaultCapable(true);
+      okButton.addActionListener(new PrivateActionListener());
+
+      contentPane.add(okButton, new GridBagConstraints(0, 1, 2, 1, 0.0, =
0.0,
+                                                       =
GridBagConstraints.CENTER, GridBagConstraints.NONE,
+                                                       new =
Insets(SwingUtil.INSETS_TL_LARGE, SwingUtil.INSETS_TL_MEDIUM,=20
+                                                                  =
SwingUtil.INSETS_BR_MEDIUM, SwingUtil.INSETS_BR_MEDIUM),
+                                                       0, 0));
+      this.getRootPane().setDefaultButton(okButton);
+
+      // Windows-Listener
+      this.addWindowListener(new PrivateWindowListener());=20
+
+   }
+
+   /**
+    * Closes the dialog
+    * @param Event, who wants the closing of the dialog
+    */
+   private void closeDialog(AWTEvent evt)
+   {
+      this.setVisible(false);
+      this.dispose();
+   }
+
+   private class PrivateActionListener implements ActionListener{
+      public void actionPerformed(ActionEvent evt){
+         closeDialog(evt);
+      }
+   }
+
+   private class PrivateWindowListener extends WindowAdapter{
+      public void windowClosing(WindowEvent evt){
+            closeDialog(evt);
+      }
+   }
+}
Index: rails/ui/swing/RailsSwing.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: rails/ui/swing/RailsSwing.java
diff -N rails/ui/swing/RailsSwing.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ rails/ui/swing/RailsSwing.java	1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,99 @@
+/**
+ *=20
+ */
+package rails.ui.swing;
+
+import java.util.ArrayList;
+import java.util.List;
+
+import javax.swing.JOptionPane;
+
+import org.apache.log4j.Logger;
+
+import rails.RailsSystem;
+
+import game.Game;
+import game.GameManager;
+import ui.GameUILoader;
+import ui.ImageLoader;
+import ui.ORWindow;
+import ui.ReportWindow;
+import ui.StatusWindow;
+import ui.StockChart;
+import util.LocalText;
+import util.Util;
+
+/**
+ * @author Rainer
+ * @pattern Singelton
+ */
+public class RailsSwing {
+
+   private static Logger log =3D null; // Logger for this class. You =
cannot initialize it before calling the init-method of RailsSystem
+
+   /**
+    * Start Rails with the Swing-UI
+    *=20
+    * @param args <br/>=20
+    * - none: start with an empty Frame <br/>=20
+    * - 18xx: load the saved game 18xx (after load/save is implemented =
<br/>=20
+    * - 18xx gv p1 p2 ...: create a game of the 18xx, using =
game-variant gv (- for none/main) with the players p1 p2 ... <br/>=20
+    */
+   public static void main(String[] args) {
+      new RailsSwing().start(args);
+   }
+
+   private RailsSwing() {
+   }
+
+   /**
+    * Start Rails with the Swing-UI
+    *=20
+    * @param args see main(String[] args)
+    */
+   private void start(String[] args){
+      RailsSystem.init();
+      this.log =3D RailsSystem.getLogger(this);
+
+      this.initGUI();
+     =20
+      if (args.length =3D=3D 0) {
+         new GameUILoader(); // Will start with the option-panel to =
choose players and game
+      }
+      else if (args.length =3D=3D 1){
+         String savedGame =3D args[0];
+         // XXX: Load/Save is not implemented by now
+      }
+      else
+      {
+         String gameName    =3D args[0];
+         String gameVariant =3D args[1];
+         ArrayList playerNames =3D new ArrayList(args.length-2);
+         for (int i=3D2; i<args.length; i++) {
+            playerNames.add(args[i]);
+         }
+         try {
+            Game.initialise(gameName);
+            if (!Util.isEqual(gameVariant, "-")) =
GameManager.setVariant(gameVariant);
+            Game.getPlayerManager(playerNames);
+            GameManager.getInstance().startGame();
+            GameUILoader.gameUIInit();
+         }
+         catch (NullPointerException e){
+            this.log.fatal("Unable to start game", e);
+            System.out.println("Unable to load game. See log-file for =
more information");
+         }
+
+      }
+        =20
+   }
+  =20
+   private void initGUI(){
+//      imageLoader =3D new ImageLoader();
+//      stockChart =3D new StockChart();
+//      reportWindow =3D new ReportWindow();
+//      orWindow =3D new ORWindow();
+//      mapPanel =3D orWindow.getMapPanel();
+//      StatusWindow statusWindow =3D new StatusWindow();
+   }
+}
Index: rails/ui/swing/SwingUtil.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: rails/ui/swing/SwingUtil.java
diff -N rails/ui/swing/SwingUtil.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ rails/ui/swing/SwingUtil.java	1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,15 @@
+package rails.ui.swing;
+
+public class SwingUtil {
+      public static final int INSETS_TL_NOSPACE =3D  -2;
+      public static final int INSETS_TL_NONE    =3D  0;
+      public static final int INSETS_TL_SMALL   =3D  3;
+      public static final int INSETS_TL_MEDIUM  =3D  6;
+      public static final int INSETS_TL_LARGE   =3D 12;
+
+      public static final int INSETS_BR_NOSPACE =3D  -1;
+      public static final int INSETS_BR_NONE    =3D  0;
+      public static final int INSETS_BR_SMALL   =3D  2;
+      public static final int INSETS_BR_MEDIUM  =3D  5;
+      public static final int INSETS_BR_LARGE   =3D 11;
+}
Index: rails/RailsSystem.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: rails/RailsSystem.java
diff -N rails/RailsSystem.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ rails/RailsSystem.java	1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,117 @@
+package rails;
+
+import java.awt.Image;
+
+import javax.swing.ImageIcon;
+
+import game.Game;
+
+import org.apache.log4j.Logger;
+
+import util.Config;
+import util.LocalText;
+import util.Util;
+
+/**
+ * Rails spezific, UI undependent System wide settings and resources,
+ * @pattern Static Singelton=20
+ * @author Rainer
+ */
+public class RailsSystem {
+
+   private static final String NAME =3D "Rails";=20
+   private static final String VERSION =3D "1.0.1"; // Better 1.00.01, =
so you will have no sorting problem with multible versin-dirs
+   private static final String DEFAULT_USER_CONFIG_FILE =3D =
"my.properties"; // The default properties file name
+   private static final ImageIcon RAILS_IMAGE =3D null; // XXX: We can =
need an Image for Rails
+  =20
+   private static Logger log =3D null; // Logger for this class. You =
cannot initialize it before calling the init-method
+
+  =20
+//   private static final String AUTHORS =3D "Brett, Eric, Rainer";
+//   private static final String COPYRIGHT =3D "The Software is under =
Open Licence ...";
+//   private static final String DEVELOPMENT_YEARS =3D "2005-2007";
+//   private static final String IMAGE_ICON_NAME =3D "";
+//   private static final String ABOUT_PICTURE_NAME =3D "";
+
+   private RailsSystem(){
+      // do nothing
+   }
+
+   /**
+    * Initialize the Rails envirement
+    * @param -Dconfigfile=3D<property-filename> as argument at start of =
the main program
+    *
+    */
+   public static final void init(){
+     =20
+      // Init userspezific property file
+      String myConfigFile =3D System.getProperty("configfile"); // Get =
the name of the configfile from commandline, if set
+      if (!Util.hasValue(myConfigFile)) {
+         myConfigFile =3D DEFAULT_USER_CONFIG_FILE;
+      }
+     =20
+      // Set the system property that tells log4j to use this file.=20
+      // (Note: this MUST be done before updating Config)=20
+      System.setProperty("log4j.configuration", myConfigFile);
+      Config.setConfigFile(myConfigFile); // Tell the properties loader =
to read this file.
+
+      // Init log
+      log =3D RailsSystem.getLogger(RailsSystem.class);
+      log.info("Initialize Rails with " + myConfigFile + " as the user =
spezifig configuraion file.");
+   }
+
+   /**
+    *=20
+    * @return Versionnumber of Rails in xx.yy.zz </br>
+    * - xx: Major Version </br>
+    * - yy: Minor Version </br>
+    * - zz: BugFixes
+    */
+   public static final String getVersion(){
+      return RailsSystem.VERSION;
+   }
+  =20
+   /**
+    *=20
+    * @return Name of the Programm
+    */
+   public static final String getName(){
+      return RailsSystem.NAME;
+   }
+
+   /**
+    *=20
+    * @return Image for Rails
+    */
+   public static final ImageIcon getRailsImage(){
+      return RAILS_IMAGE;
+   }
+  =20
+   /**
+    * Get the logger for a class
+    * @param clazz Class, for with you need a logger
+    * @return Logger for clazz, by now the Logger of the package of the =
class
+    */
+   public static final Logger getLogger(final Class clazz){
+      return Logger.getLogger(clazz.getPackage().getName());
+   }
+
+   /**
+    * Get the logger for a object
+    * @param obj Object, for with you need a logger
+    * @return Logger for obj, by now the Logger of the package of the =
class of the object
+    */
+   public static final Logger getLogger(final Object obj){
+      return Logger.getLogger(obj.getClass().getPackage().getName());
+   }
+
+   /**
+    * Get the user choosen value for a key
+    * @param key
+    * @return value, defined by user in the user property file=20
+    */
+   public static final String getUserConfig(String key){
+      return Config.get(key);
+   }
+
+}

Re: [Rails-devel] Apple Java Version 1.6

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

On Mon, Jan 22, 2007 at 01:14:32AM +0100, Rainer Muetze wrote:
> 
> > Apple hasn't released their 1.6 to the general public, 1.5 is what is on
> Tiger.
> You mean, that there is now 1.6-Version for Apple yet?
> OK - thats a reason not to go up to 1.6.

That is correct.  1.6 is currently released to developers, but not the main
stream.  I am pretty sure that 1.6 will release with Leopard, which is
supposed to be the first half of this year.

JEff

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

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

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

On 1/21/07, Rainer Muetze <rai...@we...> wrote:
>
>  >Here's the options that are acceptable to me:
> >
> >
> >4. We can display a startup dialog for a few seconds that includes a
> >logo image and the disclaimer text. Again, no user interaction is
> >necessary, just display the dialog for 5 seconds, and then close it
> >and go into the game.
> >
> >
> >I will not force users to jump through a series of hoops every time
> >they want to play a boardgame.
> >
> >
> IDEA: We need some time to load the game. We can show the picture with the
> disclaimer and a process-bar.
> So nobody will be nerved, the user knows, for what he is waiting and has
> time to read it.
> Sounds perfect to me. I would use the AboutDialog with a little change, so
> it can be displayed from the helpMenu and from the startProcess.
> Have now expirience with processbars, but that would be intresting.
> If you agree check the patch in without the Options-Changes.
>



This idea sounds good.




>>
> >OK, I have not read the hole open source licence yet,
> >but properties are there to change it. We do not know, if there
> >translation will be correct.
> >I show only the english version, if the user choose english, and
> >BOTH, if he choose an other language.
> >At this way, the user can write a translation for him, but he has to
> >change the code, if he want to change the meening.
> >
> >
> >It sounds like you're over-thinking the issue. This added complexity
> >is unnecessary.
> >
> >If someone is going to localise my project, I need to trust them to
> >do a good job. Doing these sorts of second-guessing tactics is not a
> >good way of showing that trust.
> >
> Thats a point. We trust them anyway, because we give them the sources if
> they want them.
> I will read the open licence and maybe there is allready the protection
> for what I'm looking for.
> IDEA: If we put the disclaimer into the licence-file it will be much more
> protected as with my conclusion.
> Is this a way we can go?
>


Yes, including the disclaimer into the readme is good.



>>I know you want to get rid of GameTest. We'll do it very soon, but
> >we
> >>should do it after we refactor the package hierarchy. For now, we
> >>should reorganize our existing files into a hierarchy that uses
> >the
> >>rails.foo.bar model and perhaps cleans up a few current
> >>organizational issues. Then, we can move main() into a better
> >>location.
> >>
> >I do not understand for what you are waiting, GameTest is complete
> >implemented in RailsSwing,
> >but If you want to to thinks twice from now on, don'nt remove it.
> >You do not need another patch do do this change.
> >
> >
> >I'm waiting because this is just an aesthetics change. GameTest may
> >be ugly, but it works.
> >
> >The need to change it is really very low.
> >
> The need to hold on also. But keep it if you think you have too.
>
>
> >Perhaps you should consult with a lawyer about this issue.
> I would have done it, if it would not be so expensive. (This is an
> international lawyer problem)
> At least we are on thin ice anyway and there will be no last word on that,
> until it is fight out.
>
> >
> >I am very comfortable with our efforts. I know of at least two other
> >projects that clone board games that have been around far longer than
> >ours. Both of them do not hinder the user's experience just to cover
> >their own asses.
> >
> You have your example projects and I have mine. Are yours popular?
> Nevermind, If you like my two IDEAs, I will send you a new patch tomorrow.
> (not with the progressbar, but without the internation double text and
> without the userConfirmation)
>


The two projects I'm thinking of are:

Colossus:   http://colossus.sf.net
JavaBBowl:  http://home.austin.rr.com/javabbowl/

JavaBBowl is used heavily by http://fumbbl.com/ .

Re: [Rails-devel] Apple Java Version 1.6

[Rainer M. <rai...@we...>]

> Apple hasn't released their 1.6 to the general public, 1.5 is what is on
Tiger.
You mean, that there is now 1.6-Version for Apple yet?
OK - thats a reason not to go up to 1.6.

Re: [Rails-devel] Comments on Patch for Disclaimer, UserConfirmation and new Main-Class

[Rainer M. <rai...@we...>]

>My comments to some of the points raised by Rainer.=20
>=20
>On the code:=20
>=20
>It's not easy to read the kind of patch you have sent,=20
>but from the part on LocalText I understand that you have=20
>added a dummy constructor and also have factored out
>getLocalisedText().=20
>=20
>To me this is entirely a matter of taste, about which I'm not going
>to=20
>argue,=20
>but I *would* argue that both should be private or protected rather
>than=20
>public.=20
I have need the LocalizedText to get the language. There are =
instance-ethods
to get it, but since you never instanciated the class, I could not used =
it.
Since I try to avoid a complete refatoring, I used this work-a-round
instead.


>=20
>When creating a server (see below) we might want to create an
>instance=20
>(or a Properties map) per locale, but even then all of this should
>IMO be=20
>managed internally.=20
>
So a german and an japanese user could not play together? - no good =
idea.
But I agree with your encapsultion thoughts. If you give me a change I =
hope
I can show you what I whould prefer.


>=20
>> - getLogger()=20
>> Can be also in Util. I put it in here, because it is a=20
>> rails-spezifig way=20
>> to log.=20
>> Find the Logger over a Method makes it easiar to change the
>fist=20
>> desission to log on package-level.=20
>=20
>Sorry, I don't understand at all what you are trying to say here.=20
When you start to introduce log4j in devel-rails, you talk about the
posibility to create a logger for each class (or even instance),
but for rails, it should be enough, to have a logger at package-level.

To create a logger on a defined way would be a good think, I thought. So =
why
writting at each class the same code to get the package name and create =
a
logger,=20
if we can write a central method, with just need the class or an =
instance of
it, to get the logger?


>=20
>> - VERSION=20
>> Final variables should be written in upper letters
>(Sun-Conversion)=20
>=20
>I thought that *constants* should be written in upper case.=20
>The question is whether 'version' is really a constant.=20
>One can also see it as a variable that, once assigned, cannot be
>changed -=20
>but the value is different in each release.=20
>=20
>But if you say that this is nitpicking, I agree,=20
>and I have no real problem with making it upper case.=20
>
It was just an example. If you look at the code, you find diffrent =
styles
and naming-praxis, with makes it harder to understand it.
Writing constants in upper letter is just one think, with should know =
most
coders and most coders follows.
Anyway, when I will come to the project, you will see that I will make =
such
easy avoidable mistakes also. - don't bother.


>> - Config (comment)=20
>> - Much better not as static class, So you can have userConfig
>and=20
>> systemConfig. Both should than accessed by RailsSystem or maybe
>better=20
>> Util-Methods=20
>=20
>I was thinking it would be easier to have all (user and system)=20
>properties in one Properties map, so that the programmer need=20
>not worry about where a property is exactly defined.=20
>We could then also easily move properties between property files=20
>if that would suit us better.=20
>=20
>We definitely need static access to properties, otherwise we'll=20
>have to push around another instance reference.=20
>I have no real problem to replace Config.get() by Util.getConfig(),=20
>but I don't see the benefit either. To me, it's just an extra layer=20
>of indirection.=20
>
If we need system.properties we should not put it into the =
user.properties,
becouse the user should normaly not see it or change it.
Right know, there is no need for system.properties, and Right know, the =
is
no need for more then one user.properties per instance.
(which will be changing on a server-base-version).
But things can change, and one think, I have learnd on the hard way was,
that it is very hard to remove static access with multible access.
So I try to avoid static und public access where ever I can. You will =
find
this guidlines in many books, but I have not read an explanation for the
first one (avoid static).
If we will someday on a teamspaek talk, I will tell you my hard learning =
(to
long to write it).


>> - Where do you define the default-values? (if the file is=20
>> coruppted by=20
>> the user)=20
>=20
>Where needed, defaults are specified where the properties are used=20
>when they turn out to be null or empty.=20
>=20
So if you need the default more then ones, you defined it more then =
ones? -
Bad idea.


>Not every property has an explicit and fixed default value.=20
>The default money amount format is game-dependent.=20
>The default language is (British) English, because the default=20
>resource bundle is written in that language.=20
>The default log4j properties are (by definition) empty.=20
>Etc.=20
If there are no defaults - OK, but if there are, why not using a
property-file for it too.
the resource bundle has a default one (with no language extension).


>=20
>> - CodeStyle (comment)=20
>> - public and protected variables: You are much to=20
>> broadminded with it.=20
>> You should capsulate as much as possible, using getter- and=20
>> setter-methods=20
>> for access.=20
>=20
>One problem I have with Java is, that you cannot distinguish=20
>between variables that may only be visible to subclasses,=20
>and variables that may be visible to all classes within a package.=20
>Both are "protected".=20
- protected: means only for subclasses
- private: only for class and private or anonym classes in the same file
- 'none': package wide with does not include subclasses in other =
packages


>In my code in this project, most or all "protected" variables are
>meant=20
>to be used in subclasses only, even where such subclasses do not yet
>exist.=20
>We expect that a lot of subclassing will be needed in the future=20
>when we are going to add dissimilar games.=20
>So I am only prefixing instance variables with "private"=20
>where I am pretty sure that these will never be used in subclasses.=20
>=20
>The rule I use, is that subclasses have free access to its
>superclass=20
>variables without need to use a getter. But non-related classes=20
>in the same package should always use getters and setters.=20
>=20
>BTW I think that the 'game' package is getting=20
>too large, and that we might need to split it up.=20
>That would have the side effect of better "protection" too.=20
>=20
>I agree that in principle there should not be public variables.=20
>Do we really have sinned as much as you seem to imply?=20
>It is possible that I have not always been consistent,=20
>so I would appreciate your examples of wrong use of public etc.=20
For example, all windows (views) are public, so I guess you call them =
direct
from the gmae-classes (model).
That will make it imposible to write diffrent views. If you have =
methods,
you can write interfaces someday and call the methods over the =
interface.
At this way you do not know the concret implementation of the view.


>=20
>And (hmmm) see my comments on your version of LocalText above....=20
>=20
>> - static: Much to broadminded also. You should avoid=20
>> static as much as=20
>> possible. (static constants are a break in the rule)=20
>=20
>As a matter of principle? I don't see why.=20
>To me, this is very project-dependent.=20
>=20
>> You will get a lot of trouble to bring this code running in a=20
>> server-environment. No chance.=20
>> Even singletons are not very good on servers (but easy to=20
>> transform).=20
>> RailsSystem as a geneneral System-API-Class and Util for general=20
>> transformation and methods should be the only Classes which=20
>> have static=20
>> methods which are not factory methods or system-wide-parameters=20
>> Hard words but I have a bad feeling for the time this=20
>> project groose more=20
>> complex and it will be nearly imposible to have a=20
>> server-side-version with=20
>> multible games with this code.=20
>> Start smart is a good thing, but some day, you have to=20
>> redesign it and if=20
>> you go this way farther it will be imposible someday - sorry.=20
>=20
>I am fully aware that a lot of work needs be done=20
>to make a multi-game server out of this code.=20
>If we ever get that far.=20
>=20
>The problem is, that if you don't have class methods,=20
>you need at least some reference variables in many parts=20
>of the code to access widely used instances.=20
>=20
>Several parts of the code need to be able to find out in which turn,=20
>round or phase the game is (this all may have changed=20
>any moment, e.g. while processing a train buy).=20
>So there must be some central point of inquiry about all=20
>aspects of the game state.
A central controller and interfaces


>=20
>I am fully aware that the mixed use of class and instance variables=20
>and methods is a mess in some places (e.g. Game/GameManager),=20
>and that this needs to be redone in a better way.=20
>However, in my opinion the code is not yet in a sufficiently=20
>mature state that we can take decisions on exactly how to do that.=20
>=20
>I suppose the best way will be to make sure that every=20
>instance that must take decisions has a reference to an=20
>instance of either Game or GameManager, and can find out=20
>the current status by calling that instance's methods.=20
Very good idea.

>=20
>I don't think this will be very difficult to do.=20
>So far I did not have the feeling that this is more urgent=20
>than improving the code structure in more fundamental ways,=20
>to enable undo/redo and to prepare a client/server split,=20
>which is what I have been doing the last few months, and still do.=20
>=20
>=20
>Aside: I sometimes take shortcuts to use the little bits of time=20
>I have as productively as possible.=20
>And quite often I come back (much) later to that code=20
>and fix it, or improve it in some other way, or entirely=20
>remove it or replace it with something better.=20
>There is quite some code that I know must be improved,=20
>or replaced, or whatever - but often I just have to postpone=20
>my thinking on what exactly needs be done.=20
>In my experience, things usually become clear when the time is ripe.=20
Thats the way I have coded in the 80's. On a very large project (and I =
think
this is a large project - at least what the final vision is),
I was stucked in the code, with becomes unchangeable and had to start =
from
the beginning again,=20
That was the time, I start with uge modelling and tryed to defnie every
posibility in forcast. Good think, but much wast time for thinks, which =
will
never come.
There are some articels about 'the entrophy of code change', with meens,
that every change or add on code makes it harder to do the next change =
or
add on.
Agile proofs, that with good, very object oriented programm style, you =
can
drop the entrophy near zero. But you have to seperate your classes as =
far as
possible.
I hope, that with aspect programming, this will go even better, but that =
is
another story.
Today I try to define the vision goals and make models just for the next
step. Try to be agile by implementing as smal as possible,=20
BUT thing about the vision goals on every implementation step. Doing =
thinks,
with pure agile peoble would posible not do.


>=20
>> I know, my code is not a good example how it shoud be=20
>> (since it is not=20
>> much code at all and most of it in RailsSystem - the=20
>> exception of the rule,=20
>> Maybe I can refactor LocalText or Config to show you what=20
>> I mean, if you=20
>> want it.=20
>=20
>Showcases are always welcome to me.=20
>It is from code from other people that I learn,=20
>even if I adopt nothing or just a little of their style.=20
>I'm sure it's the same with you.=20
>=20
>Sorry that this reaction has become so long,=20
>but I hope I have been able to clarify a few aspects.=20

You are welcome. It makes thinks much more clear. I guess, that we will =
have
a good time together.
And please remind: Even if I have more expirence - Fresh thinking is the
way, we move on.
Even if I critisize a lot, the general ideas are great and changes have =
to
be made step by step.
I would not like to refaktor evrythink without going on implementing new
thinks also.

>- Questions=20
> - Java-Version=20
> Which one are you using? By know I have used only 1.4.2
>syntax, but=20
>would like to go up to 1.6 (or 1.5).=20
> 1.5 should be faster and has more type-safty and a
>enumaration.=20
> 1.6 should be faster then 1.5 and has some advantages in=20
>web-services=20
> At work, we are using still 1.4.2, becouse we have some=20
>third-party-libs, which are not compatible with 1.5, but I would
>like to get=20
>experince in 1.5/1.6=20
>=20
>For the sake of it? That does not sound like a good reason to start
>using it in this project.=20
>I don't know much about Java 1.5, so I would like to know why we
>would need it in this project.=20
>=20
>=20
>The last time we talked about it (at least 1 or 2 years ago), we had
>decided to use Java 1.4.2. However, that might be something we can
>revisit. I'm not sure how Java's adoption has been going. If most
>people have 1.5 or 1.6, I don't see a problem changing our system
>requirements.=20
>=20
>If there is a clear need, we should upgrade, but I don't see it
>yet.=20
>If it is speed, we can always recommend people to use the latest=20
>and fastest version of java, without relying upon it for our source
>code.=20
>=20
Somebody else said, 1.6 is still in beta. I was at the javasoft.com page =
and
could see that, but have not download it I'm not sure.

We don't need 1.5. You can do all thinks with 1.4.2.=20
As long as we do not use some knew protected key words of 1.5 (enum for
example),
it will be very simple to move up as time comes.
It was just a thought, becouse I have used 1.5 and eclipse told me, that =
a
method I used is depredicated at 1.5.
And since I like to be up to date and learn what is new, I asked.
(Spezialy I like to get experience in the =
type-save-collection-class-using
and the enums).

There was an article about the improvments of 1.6 in the german computer
magazine c't.=20
Since it makes web-services-implementation and use much easear, I guess,
that a change could be intristing, when we come to that point.
If 1.6 is still in beta, I would not use it.

Rainer

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

[Rainer M. <rai...@we...>]

>Here's the options that are acceptable to me: 
> 
> 
>4. We can display a startup dialog for a few seconds that includes a
>logo image and the disclaimer text. Again, no user interaction is
>necessary, just display the dialog for 5 seconds, and then close it
>and go into the game. 
> 
> 
>I will not force users to jump through a series of hoops every time
>they want to play a boardgame. 
> 
>
IDEA: We need some time to load the game. We can show the picture with the
disclaimer and a process-bar.
So nobody will be nerved, the user knows, for what he is waiting and has
time to read it.
Sounds perfect to me. I would use the AboutDialog with a little change, so
it can be displayed from the helpMenu and from the startProcess.
Have now expirience with processbars, but that would be intresting.
If you agree check the patch in without the Options-Changes.
 
 
 
>> 
>OK, I have not read the hole open source licence yet, 
>but properties are there to change it. We do not know, if there
>translation will be correct. 
>I show only the english version, if the user choose english, and
>BOTH, if he choose an other language. 
>At this way, the user can write a translation for him, but he has to
>change the code, if he want to change the meening. 
> 
> 
>It sounds like you're over-thinking the issue. This added complexity
>is unnecessary. 
> 
>If someone is going to localise my project, I need to trust them to
>do a good job. Doing these sorts of second-guessing tactics is not a
>good way of showing that trust. 
> 
Thats a point. We trust them anyway, because we give them the sources if
they want them.
I will read the open licence and maybe there is allready the protection for
what I'm looking for.
IDEA: If we put the disclaimer into the licence-file it will be much more
protected as with my conclusion.
Is this a way we can go?
 

>>I know you want to get rid of GameTest. We'll do it very soon, but
>we 
>>should do it after we refactor the package hierarchy. For now, we 
>>should reorganize our existing files into a hierarchy that uses
>the 
>>rails.foo.bar model and perhaps cleans up a few current 
>>organizational issues. Then, we can move main() into a better 
>>location. 
>> 
>I do not understand for what you are waiting, GameTest is complete
>implemented in RailsSwing, 
>but If you want to to thinks twice from now on, don'nt remove it. 
>You do not need another patch do do this change. 
> 
> 
>I'm waiting because this is just an aesthetics change. GameTest may
>be ugly, but it works. 
> 
>The need to change it is really very low. 
>
The need to hold on also. But keep it if you think you have too.
 

>Perhaps you should consult with a lawyer about this issue.
I would have done it, if it would not be so expensive. (This is an
international lawyer problem)
At least we are on thin ice anyway and there will be no last word on that,
until it is fight out.
 
> 
>I am very comfortable with our efforts. I know of at least two other
>projects that clone board games that have been around far longer than
>ours. Both of them do not hinder the user's experience just to cover
>their own asses. 
> 
You have your example projects and I have mine. Are yours popular?
Nevermind, If you like my two IDEAs, I will send you a new patch tomorrow.
(not with the progressbar, but without the internation double text and
without the userConfirmation)
 
Rainer

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

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

On 1/21/07, Rainer Muetze <rai...@we...> wrote:
>
>  Hi,
>
> >I like the About dialog. However, I don't think the checkbox in
> >Options is necessary. It's a bit heavy-handed, especially when the
> >user has to check the box every time they play.
> >
> I do not think so. Take a 1/2 Second to confirm that I own the boardgame
> is nothink agains the playtime (4-6 hours).
> Maybe I'm paranoid. But I wan't just as much protection agains lowyers as
> possible.
> Friends have experients with them and I would like to avoid such trouble.
>


Here's the options that are acceptable to me:

1. We can have a disclaimer that pops up the first time the application is
run, that users must click through. However, If we require user acceptance,
then it's only acceptable to show this _once_ and not every time the
application is run. So, we'd need to write some parameter to a file that can
be checked for to suppress the disclaimer after the first run.

2. We can have the disclaimer in the AboutDialog, which is easily available
from all windows. It should show the game version and the disclaimer.

3. We can display the disclaimer text in a field in the Options dialog, so
long as we aren't requiring any additional actions to be taken by the user.
Use of our game is implicit acceptance.

4. We can display a startup dialog for a few seconds that includes a logo
image and the disclaimer text. Again, no user interaction is necessary, just
display the dialog for 5 seconds, and then close it and go into the game.


I will not force users to jump through a series of hoops every time they
want to play a boardgame.


>We should leave the disclaimer in the AboutDialog, and just remove
> >the checkbox in Options. In Options we can add a button to view the
> >AboutDialog. I think that's sufficient. That way the disclaimer is
> >still available on game start-up, but it doesn't block people from
> >playing.
> >
> Avaible is not enougth. We have to make sure, that the have at least to
> look at it.
> We can show the AboutDialog at every startup for a view seconds or after
> creating a new game.
> But both means more disadvantage for playstart then this checkbox.
> I don'nt know how many times I have to check a box for agreement yet, but
> it havend nervered me.
>


I don't agree.  We don't need to force the user into seeing it. We simply
need to make it available so it _can_ be seen.

Lawyers care if we make the effort at all. As long as we ship the disclaimer
in the readme and have it available in the application, we've made a good
effort to inform our users of the status of our application.


>I don't think it's necessary to hard-code the disclaimer text. It's
> >inconsistent with our localization efforts. It's also inconsistent
> >with the philosophy behind choosing an open source license. Having a
> >single copy of the disclaimer in the LocalisedText.properties file
> >is good enough.
> >
> OK, I have not read the hole open source licence yet,
> but properties are there to change it. We do not know, if there
> translation will be correct.
> I show only the english version, if the user choose english, and BOTH, if
> he choose an other language.
> At this way, the user can write a translation for him, but he has to
> change the code, if he want to change the meening.
>


It sounds like you're over-thinking the issue. This added complexity is
unnecessary.

If someone is going to localise my project, I need to trust them to do a
good job. Doing these sorts of second-guessing tactics is not a good way of
showing that trust.


>I know you want to get rid of GameTest. We'll do it very soon, but we
> >should do it after we refactor the package hierarchy. For now, we
> >should reorganize our existing files into a hierarchy that uses the
> >rails.foo.bar model and perhaps cleans up a few current
> >organizational issues. Then, we can move main() into a better
> >location.
> >
> I do not understand for what you are waiting, GameTest is complete
> implemented in RailsSwing,
> but If you want to to thinks twice from now on, don'nt remove it.
> You do not need another patch do do this change.
>


I'm waiting because this is just an aesthetics change. GameTest may be ugly,
but it works.

The need to change it is really very low.



>For now, I would like to see a scaled-down patch that is just adding
> >the AboutDialog and the disclaimer.
> >
> >Then, we can come back and find a good way to start adding some more
> >consistent conventions and relocate some of these other files.
> >
> As I said at my first email to you, protection agains lowyers is a very
> import think for me.
> You will not get another patch, as long as we don'nt get a agreement about
> how far we go with it.
> The implementaion of my patch is what I think we have to do at leased. I
> have show you some alternatives in this mail,
> but for my thoughts, they are much more annoing then this implementation.
>


Perhaps you should consult with a lawyer about this issue.

I am very comfortable with our efforts. I know of at least two other
projects that clone board games that have been around far longer than ours.
Both of them do not hinder the user's experience just to cover their own
asses.



---Brett.

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

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

My comments to some of the points raised by Rainer. 

On the code:

It's not easy to read the kind of patch you have sent, 
but from the part on LocalText I understand that you have 
added a dummy constructor and also have factored out getLocalisedText().

To me this is entirely a matter of taste, about which I'm not going to
argue,
but I *would* argue that both should be private or protected rather than
public.

When creating a server (see below) we might want to create an instance
(or a Properties map) per locale, but even then all of this should IMO be
managed internally.


>    - getLogger()
>    Can be also in Util. I put it in here, because it is a 
> rails-spezifig way
> to log. 
>    Find the Logger over a Method makes it easiar to change the fist
> desission to log on package-level.

Sorry, I don't understand at all what you are trying to say here.

>    - VERSION
>    Final variables should be written in upper letters (Sun-Conversion)

I thought that *constants* should be written in upper case.
The question is whether 'version' is really a constant.
One can also see it as a variable that, once assigned, cannot be changed -
but the value is different in each release.

But if you say that this is nitpicking, I agree,
and I have no real problem with making it upper case.

>    We are using 'ea' as a version suffix to show users, that 
> say are using
> an early acces version (if they using the shnapshot)

I would have used 0.x version numbers, but I was too late 
in proposing that to Brett. I don't really mind.

>    - getVersion()
>    Try to avoid direct acess to variables, even if thy are 
> final. That makes
> changes later on easer.

You're right. I was lazy.

> - Config (comment)
>    - Much better not as static class, So you can have userConfig and
> systemConfig. Both should than accessed by RailsSystem or maybe better
> Util-Methods

I was thinking it would be easier to have all (user and system) 
properties in one Properties map, so that the programmer need 
not worry about where a property is exactly defined. 
We could then also easily move properties between property files 
if that would suit us better.

We definitely need static access to properties, otherwise we'll
have to push around another instance reference.
I have no real problem to replace Config.get() by Util.getConfig(),
but I don't see the benefit either. To me, it's just an extra layer
of indirection.

>    - Where do you define the default-values? (if the file is 
> coruppted by
> the user)

Where needed, defaults are specified where the properties are used
when they turn out to be null or empty. 

Not every property has an explicit and fixed default value.
The default money amount format is game-dependent.
The default language is (British) English, because the default
resource bundle is written in that language.
The default log4j properties are (by definition) empty.
Etc.
  
> - CodeStyle (comment)
>    - public and protected variables: You are much to 
> broadminded with it.
> You should capsulate as much as possible, using getter- and 
> setter-methods
> for access.

One problem I have with Java is, that you cannot distinguish 
between variables that may only be visible to subclasses,
and variables that may be visible to all classes within a package.
Both are "protected". 

In my code in this project, most or all "protected" variables are meant 
to be used in subclasses only, even where such subclasses do not yet exist.
We expect that a lot of subclassing will be needed in the future
when we are going to add dissimilar games. 
So I am only prefixing instance variables with "private"
where I am pretty sure that these will never be used in subclasses.

The rule I use, is that subclasses have free access to its superclass
variables without need to use a getter. But non-related classes
in the same package should always use getters and setters.

BTW I think that the 'game' package is getting
too large, and that we might need to split it up.
That would have the side effect of better "protection" too.

I agree that in principle there should not be public variables.
Do we really have sinned as much as you seem to imply?
It is possible that I have not always been consistent,
so I would appreciate your examples of wrong use of public etc.

And (hmmm) see my comments on your version of LocalText above....

>    - static: Much to broadminded also. You should avoid 
> static as much as
> possible. (static constants are a break in the rule)

As a matter of principle? I don't see why.
To me, this is very project-dependent.

>    You will get a lot of trouble to bring this code running in a
> server-environment. No chance. 
>    Even singletons are not very good on servers (but easy to 
> transform).
> RailsSystem as a geneneral System-API-Class and Util for general
> transformation and methods should be the only Classes which 
> have static
> methods which are not factory methods or system-wide-parameters
>    Hard words but I have a bad feeling for the time this 
> project groose more
> complex and it will be nearly imposible to have a 
> server-side-version with
> multible games with this code.
>    Start smart is a good thing, but some day, you have to 
> redesign it and if
> you go this way  farther it will be imposible someday - sorry.

I am fully aware that a lot of work needs be done 
to make a multi-game server out of this code.
If we ever get that far.

The problem is, that if you don't have class methods,
you need at least some reference variables in many parts 
of the code to access widely used instances.

Several parts of the code need to be able to find out in which turn, 
round or phase the game is (this all may have changed
any moment, e.g. while processing a train buy).
So there must be some central point of inquiry about all
aspects of the game state.

I am fully aware that the mixed use of class and instance variables
and methods is a mess in some places (e.g. Game/GameManager),
and that this needs to be redone in a better way.
However, in my opinion the code is not yet in a sufficiently
mature state that we can take decisions on exactly how to do that.

I suppose the best way will be to make sure that every 
instance that must take decisions has a reference to an
instance of either Game or GameManager, and can find out
the current status by calling that instance's methods.

I don't think this will be very difficult to do. 
So far I did not have the feeling that this is more urgent
than improving the code structure in more fundamental ways,
to enable undo/redo and to prepare a client/server split,
which is what I have been doing the last few months, and still do.


Aside: I sometimes take shortcuts to use the little bits of time
I have as productively as possible.
And quite often I come back (much) later to that code
and fix it, or improve it in some other way, or entirely
remove it or replace it with something better.
There is quite some code that I know must be improved, 
or replaced, or whatever -  but often I just have to postpone
my thinking on what exactly needs be done.
In my experience, things usually become clear when the time is ripe.

>    I know, my code is not a good example how it shoud be 
> (since it is not
> much code at all and most of it in RailsSystem - the 
> exception of the rule, 
>    Maybe I can refactor LocalText or Config to show you what 
> I mean, if you
> want it.

Showcases are always welcome to me.
It is from code from other people that I learn, 
even if I adopt nothing or just a little of their style.
I'm sure it's the same with you.

Sorry that this reaction has become so long, 
but I hope I have been able to clarify a few aspects.

Erik.

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

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

On Sun, Jan 21, 2007 at 04:45:03PM +0100, Erik Vos wrote:
>=20
> - Questions
>    - Java-Version
>       Which one are you using? By know I have used only 1.4.2 syntax, but
> would like to go up to 1.6 (or 1.5).
>       1.5 should be faster and has more type-safty and a enumaration.=20
>       1.6 should be faster then 1.5 and has some advantages in web-servic=
es
>       At work, we are using still 1.4.2, becouse we have some
> third-party-libs, which are not compatible with 1.5, but I would like to =
get
>=20
> experince in 1.5/1.6

Apple hasn't released their 1.6 to the general public, 1.5 is what is on
Tiger.

Jeff


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

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

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

 



I like the About dialog.  However, I don't think the checkbox in Options is
necessary. It's a bit heavy-handed, especially when the user has to check
the box every time they play.

We should leave the disclaimer in the AboutDialog, and just remove the
checkbox in Options. In Options we can add a button to view the AboutDialog.
I think that's sufficient. That way the disclaimer is still available on
game start-up, but it doesn't block people from playing. 
 
I don't think it's necessary to hard-code the disclaimer text. It's
inconsistent with our localization efforts. It's also inconsistent with the
philosophy behind choosing an open source license. Having a single copy of
the disclaimer in the LocalisedText.properties file is good enough.

Util.isEqual() is unnecessary. There's already a .equals() method that
everything inherits from Object. In a few places we override the .equals()
method to make more meaningful comparisons. One example is MapHex. 

I know you want to get rid of GameTest. We'll do it very soon, but we should
do it after we refactor the package hierarchy. For now, we should reorganize
our existing files into a hierarchy that uses the rails.foo.bar model and
perhaps cleans up a few current organizational issues. Then, we can move
main() into a better location.
 

If I'm going to be confronted with a disclaimer each time I run a test,
I will definitely work around that, and keep some (local) version of
GameTest regardless.
The disclaimer is OK for released versions, but I don't want to see it.

 For now, I would like to see a scaled-down patch that is just adding the
AboutDialog and the disclaimer. 

Then, we can come back and find a good way to start adding some more
consistent conventions and relocate some of these other files.

 


- Questions
   - Java-Version
      Which one are you using? By know I have used only 1.4.2 syntax, but
would like to go up to 1.6 (or 1.5).
      1.5 should be faster and has more type-safty and a enumaration. 
      1.6 should be faster then 1.5 and has some advantages in web-services
      At work, we are using still 1.4.2, becouse we have some
third-party-libs, which are not compatible with 1.5, but I would like to get

experince in 1.5/1.6

 

For the sake of it? That does not sound like a good reason to start using it
in this project.
I don't know much about Java 1.5, so I would like to know why we would need
it in this project.

 

The last time we talked about it (at least 1 or 2 years ago), we had decided
to use Java 1.4.2. However, that might be something we can revisit. I'm not
sure how Java's adoption has been going. If most people have 1.5 or 1.6, I
don't see a problem changing our system requirements.
 

If there is a clear need, we should upgrade, but I don't see it yet.
If it is speed, we can always recommend people to use the latest 
and fastest version of java, without relying upon it for our source code.
 
Erik.

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

[Rainer M. <rai...@we...>]

Hi,
=20
>I like the About dialog. However, I don't think the checkbox in
>Options is necessary. It's a bit heavy-handed, especially when the
>user has to check the box every time they play.=20
>=20
I do not think so. Take a 1/2 Second to confirm that I own the boardgame =
is
nothink agains the playtime (4-6 hours).
Maybe I'm paranoid. But I wan't just as much protection agains lowyers =
as
possible.=20
Friends have experients with them and I would like to avoid such =
trouble.
=20
>We should leave the disclaimer in the AboutDialog, and just remove
>the checkbox in Options. In Options we can add a button to view the
>AboutDialog. I think that's sufficient. That way the disclaimer is
>still available on game start-up, but it doesn't block people from
>playing.=20
>=20
Avaible is not enougth. We have to make sure, that the have at least to =
look
at it.
We can show the AboutDialog at every startup for a view seconds or after
creating a new game.=20
But both means more disadvantage for playstart then this checkbox.
I don'nt know how many times I have to check a box for agreement yet, =
but it
havend nervered me.
=20

>I don't think it's necessary to hard-code the disclaimer text. It's
>inconsistent with our localization efforts. It's also inconsistent
>with the philosophy behind choosing an open source license. Having a
>single copy of the disclaimer in the LocalisedText.properties file
>is good enough.=20
>
OK, I have not read the hole open source licence yet,
but properties are there to change it. We do not know, if there =
translation
will be correct.=20
I show only the english version, if the user choose english, and BOTH, =
if he
choose an other language.
At this way, the user can write a translation for him, but he has to =
change
the code, if he want to change the meening.
=20

>Util.isEqual() is unnecessary. There's already a .equals() method
>that everything inherits from Object. In a few places we override the
>.equals() method to make more meaningful comparisons. One example is
>MapHex.=20
>
You can not do the think I have done in isEquals in obj.equals, becouse =
obj
can not be null in your point of view.
My implementaion holds all rules for equals() and does the use of it =
easier.
It has nothink to do with overiding the equals method self.
PS.: Hope you have hold all rules for equals-overiding in MapHex.
=20

>I know you want to get rid of GameTest. We'll do it very soon, but we
>should do it after we refactor the package hierarchy. For now, we
>should reorganize our existing files into a hierarchy that uses the
>rails.foo.bar model and perhaps cleans up a few current
>organizational issues. Then, we can move main() into a better
>location.=20
>
I do not understand for what you are waiting, GameTest is complete
implemented in RailsSwing,=20
but If you want to to thinks twice from now on, don'nt remove it.
You do not need another patch do do this change.
=20

>For now, I would like to see a scaled-down patch that is just adding
>the AboutDialog and the disclaimer.=20
>=20
>Then, we can come back and find a good way to start adding some more
>consistent conventions and relocate some of these other files.=20
>
As I said at my first email to you, protection agains lowyers is a very
import think for me.
You will not get another patch, as long as we don'nt get a agreement =
about
how far we go with it.
The implementaion of my patch is what I think we have to do at leased. I
have show you some alternatives in this mail,=20
but for my thoughts, they are much more annoing then this =
implementation.
=20

Rainer

Re: [Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

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

On 1/20/07, Rainer Muetze <rai...@we...> wrote:
>
> Here comes the first BIG patch with the implementation of a AboutDialog,
> UserConfirmation and RailsSwing as the new starting class.
>
>

Hmm...

I like a lot of this, but there are some revisions I need before I merge
this patch.

I like the About dialog.  However, I don't think the checkbox in Options is
necessary. It's a bit heavy-handed, especially when the user has to check
the box every time they play.

We should leave the disclaimer in the AboutDialog, and just remove the
checkbox in Options. In Options we can add a button to view the AboutDialog.
I think that's sufficient. That way the disclaimer is still available on
game start-up, but it doesn't block people from playing.

I don't think it's necessary to hard-code the disclaimer text. It's
inconsistent with our localization efforts. It's also inconsistent with the
philosophy behind choosing an open source license. Having a single copy of
the disclaimer in the LocalisedText.properties file is good enough.

Util.isEqual() is unnecessary. There's already a .equals() method that
everything inherits from Object. In a few places we override the .equals()
method to make more meaningful comparisons. One example is MapHex.

I know you want to get rid of GameTest. We'll do it very soon, but we should
do it after we refactor the package hierarchy. For now, we should reorganize
our existing files into a hierarchy that uses the rails.foo.bar model and
perhaps cleans up a few current organizational issues. Then, we can move
main() into a better location.


For now, I would like to see a scaled-down patch that is just adding the
AboutDialog and the disclaimer.

Then, we can come back and find a good way to start adding some more
consistent conventions and relocate some of these other files.



- Questions
>    - Java-Version
>       Which one are you using? By know I have used only 1.4.2 syntax, but
> would like to go up to 1.6 (or 1.5).
>       1.5 should be faster and has more type-safty and a enumaration.
>       1.6 should be faster then 1.5 and has some advantages in
> web-services
>       At work, we are using still 1.4.2, becouse we have some
> third-party-libs, which are not compatible with 1.5, but I would like to
> get
> experince in 1.5/1.6



The last time we talked about it (at least 1 or 2 years ago), we had decided
to use Java 1.4.2. However, that might be something we can revisit. I'm not
sure how Java's adoption has been going. If most people have 1.5 or 1.6, I
don't see a problem changing our system requirements.


---Brett

[Rails-devel] Patch for Disclaimer, UserConfirmation and new Main-Class

[Rainer M. <rai...@we...>]

Here comes the first BIG patch with the implementation of a AboutDialog,
UserConfirmation and RailsSwing as the new starting class.



Design Desissions and other thinks:
- Refacoring double code
   I have not refactores your code, if I have doubled or moved it (see
version), since I don't no if you want to follow me. I will if you like =
it
and accept my patch.

- RailsSystem
   Need a place to initialize Rails spezifig environment thinks, Game is
more game-rule-spezifig, Util should be the place for stuff, you can use
also in other programs.
   - getLogger()
   Can be also in Util. I put it in here, because it is a rails-spezifig =
way
to log.=20
   Find the Logger over a Method makes it easiar to change the fist
desission to log on package-level.
   - VERSION
   Final variables should be written in upper letters (Sun-Conversion)
   We are using 'ea' as a version suffix to show users, that say are =
using
an early acces version (if they using the shnapshot)
   - getVersion()
   Try to avoid direct acess to variables, even if thy are final. That =
makes
changes later on easer.
  =20
   - INTERNATIONAL_DISCLAIMER/USER_CONFIRMATION
   Those are the text-versions, witch should not be changeable by the =
user.
I put a version also in the localizeText.properties, but there is just a
sublementary version for the local language version.
   If language is not default or en, you will see both text-versions!
   Please have a look at the text. I have used your recommentation but
sublement some more sentence to it. Hope you can life with them and =
Brett
should correct theme, if there are bugs in it.
  =20
- RailsSwing
   Renamed RailsMain to RailsSwing to show, that this is the startpoint =
of a
Swing implementation

- SwingUtil
   Util class for Swing utility methods and constants
  =20
- AboutDialog
   The look of the InfoFields is look&feel dependent. I did not have the
time yet, to bring a change look&feel class into the project, where this
would be normaly set.
   I would like to see an image/icon for rails, having some idears. Have =
you
one ready or should I go on (Making an 'R' with the
base-green/yellow/green/brown/grey colours of 18xx)
   If we want, we can expand the info with copyrigth information, =
authors,
ect.
  =20
- Options
   Have just integrated the userConfirmation, using your style (because =
I
want not to change to much yet).
   A User has to confirm, that he owns the boardgame.
   You suprised me by using the GridBagConstraints variable for more =
then
one place. I'm sure, that this has not work inprevios versions of the =
java
virtual maschine. I will optimize my code with this informattion in the =
near
feature (if you accept the code at all).
  =20
- StatusWindow
   Same as Options with the help-menu.
  =20
- LocalizeText.properties
   All the new Text.
  =20
- Util
   - isEquals()
      Do you have a spezial order in methods? I just put it at the and =
of
the class. Feel free to move it.
     =20
- Config (comment)
   - Much better not as static class, So you can have userConfig and
systemConfig. Both should than accessed by RailsSystem or maybe better
Util-Methods
   - Where do you define the default-values? (if the file is coruppted =
by
the user)
  =20
- CodeStyle (comment)
   - public and protected variables: You are much to broadminded with =
it.
You should capsulate as much as possible, using getter- and =
setter-methods
for access.
   - static: Much to broadminded also. You should avoid static as much =
as
possible. (static constants are a break in the rule)
   You will get a lot of trouble to bring this code running in a
server-environment. No chance.=20
   Even singletons are not very good on servers (but easy to transform).
RailsSystem as a geneneral System-API-Class and Util for general
transformation and methods should be the only Classes which have static
methods which are not factory methods or system-wide-parameters
   Hard words but I have a bad feeling for the time this project groose =
more
complex and it will be nearly imposible to have a server-side-version =
with
multible games with this code.
   Start smart is a good thing, but some day, you have to redesign it =
and if
you go this way  farther it will be imposible someday - sorry.
   I know, my code is not a good example how it shoud be (since it is =
not
much code at all and most of it in RailsSystem - the exception of the =
rule,=20
   Maybe I can refactor LocalText or Config to show you what I mean, if =
you
want it.
   Too catch your angst about no new features, you should not change all =
at
ones anyway. Just one class in a month or quarter. That won't cost you =
much
time and brings you forward.
  =20
- Questions
   - Java-Version
      Which one are you using? By know I have used only 1.4.2 syntax, =
but
would like to go up to 1.6 (or 1.5).
      1.5 should be faster and has more type-safty and a enumaration.
      1.6 should be faster then 1.5 and has some advantages in =
web-services
      At work, we are using still 1.4.2, becouse we have some
third-party-libs, which are not compatible with 1.5, but I would like to =
get
experince in 1.5/1.6



Hope you like it.

Regards
Rainer

Re: [Rails-devel] project layout

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

> As I said yesterday. I can give you a view on maven project layout on rails
> or go on with the coding my fist changes on UI - starting sequence and
> disclaimer. I like both thinks (both thinks will get me more familar with
> your code) and you have the choice. So I will do coding tomorrow.
> By the way: Everey time a get a new developer in my team, I have the same
> problem as you have with me :-)
>


I'm glad you're not offended.  I'm glad you understand.

Once you've gotten a few patches in, I think you'll do just fine. :-)


---Brett.

[Rails-devel] project layout

[Rainer M. <rai...@we...>]

> > > >Perhaps it is all worth a try.
> > > I have just checkout rails and use the default .project. Don'nt =
know=20
> > > if it comes with Rails or is the Eclipse default one. But class =
and
> > > java are in
> > > the same dir and that is quit confusing for me.
> >
> > I think that is a difference between Brett's and my setup:
> > I have created subfolders named src and bin for the sources and=20
> > classes, respectively, and I think Brett is using the Eclipse =
default.
> >
> This is true.  I don't change many of Eclipse's defaults.

So you checkout into src and move the files for the higher folder up?
OK - that will work for a while.


> > My main problem was how to get the resources and XMLs in the=20
> > classpath, but somehow I managed.
> >
> > I'm getting the feeling that you know a lot better how to set up =
such=20
> > a project than Brett (sorry if I'm wrong, Brett!) and certainly than =

> > me, and I'm absolutely interested to see a proper one....
> >
> No apology needed. This is true, this is my first real development
project.
>
> I know that there are many things that most software projects do that
we're not doing. I'd love to move toward a more=20
> standardized setup. However, I'd like to see all of the steps involved =
and
make better plans to do it in a way that=20
> doesn't disrupt our ability to still work on the code itself.
>
... (from other mail)
> Rainer - I think this is the core problem I'm having with many of =
these
suggestions.=20
> Instead of learning how we've been >>working, and doing it our way for =
a
while,=20
> you're suggesting a lot of large, drastic changes to accomodate your =
own
preferences.
>
> I think that we should focus more on reaching our existing goals. =20
> So far, I haven't received a patch for the first item you brought up =
(the
disclaimer)=20
> and now you're moving on to suggesting changing our RCS and moving all =
of
our files around=20
> and reworking large portions of our architecture.

Thanks - I'm working as 'software-project-leader' now for about 15 =
Years,
Writing code for about 30 Years, with UI as a main field for about 20 =
Years.
And thats maybe my problem. It's right. You start the project and have =
made
allmost all coding yet. I'm the new one in the project and should follow
you're project style. But if I see somethink, that I do not like, I will
tell you. I make offers, who you can make it better and tell you the
drawbacks. Thats all. I would not have bring up the discussion about =
project
layout if this project is under SubVersion or if I have knew that the
history is not verry valueable for you.=20
Doing thinks step by step is much better!=20
Every project layout change will hold the project at least for the =
hours,
you are doing it. As long as there are only a view people working on it,
that has no impact on the project.
As I said yesterday. I can give you a view on maven project layout on =
rails
or go on with the coding my fist changes on UI - starting sequence and
disclaimer. I like both thinks (both thinks will get me more familar =
with
your code) and you have the choice. So I will do coding tomorrow.
By the way: Everey time a get a new developer in my team, I have the =
same
problem as you have with me :-)

Rainer

[Rails-devel] Package rails.

[Rainer M. <rai...@we...>]

Hi,
>>
>> IMHO the package name changes (prepending 'rails.')
>> is worth doing now, better than later.
>> I don't care about the loss of history, as I'm sure
>> that the current version is better than anything in the past. In any 
>> case I will make a backup copy of my current project.
>>
> Agreed. This is small, and our revision history isn't a major loss. I
can't really see us reverting too far back. 
> Plus, we do have a couple of old released versions. I think that's good
enough.

OK, so I will go on with RailsMain and Swing on Saturday. Hopefully putting
in the disclaimer.

Re: [Rails-devel] rails-package rails.ui.swing SVG revenue

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

On 1/19/07, Erik Vos <eri...@hc...> wrote:
>
> IMHO the package name changes (prepending 'rails.')
> is worth doing now, better than later.
> I don't care about the loss of history, as I'm sure
> that the current version is better than anything in the past.
> In any case I will make a backup copy of my current project.
>


Agreed. This is small, and our revision history isn't a major loss. I
can't really see us reverting too far back. Plus, we do have a couple
of old released versions. I think that's good enough.


> The changes to Subversion and the project structure
> clearly need more thought and can be postponed, if done at all.
>

I honestly don't see the merit. It's a big upheaval for a very minor
gain. Plus, the gain is only realized in certain cases.


> However, I leave the decision to Brett.
> One of us should do it, as only the two of us can commit code now.
> I'm prepared to do the package name changes next Sunday,
> but it's equally fine to me drop the whole issue.
>

I think we should move toward a more standard package naming structure.

I might have time this weekend to do it. If not, it can happen next weekend.

---Brett

Re: [Rails-devel] rails-package rails.ui.swing SVG revenue

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

IMHO the package name changes (prepending 'rails.')
is worth doing now, better than later.
I don't care about the loss of history, as I'm sure
that the current version is better than anything in the past.
In any case I will make a backup copy of my current project.

The changes to Subversion and the project structure
clearly need more thought and can be postponed, if done at all.

However, I leave the decision to Brett.
One of us should do it, as only the two of us can commit code now.
I'm prepared to do the package name changes next Sunday,
but it's equally fine to me drop the whole issue.

FYI, I'm away from now until Saturday night.

Erik.


> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: Thursday 18 January 2007 23:34
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] rails-package rails.ui.swing SVG revenue
> 
> > With all these proposals, what is most important for me is
> > what all these changes would mean for the way I work with Eclipse.
> > With some trouble I have achieved a working relationship 
> with Eclipse,
> > and I don't really have a picture how that will change with 
> such a new
> > layout.
> >
> 
> 
> Rainer - I think this is the core problem I'm having with many of
> these suggestions. Instead of learning how we've been working, and
> doing it our way for a while, you're suggesting a lot of large,
> drastic changes to accomodate your own preferences.
> 
> I think that we should focus more on reaching our existing goals.  So
> far, I haven't received a patch for the first item you brought up (the
> disclaimer) and now you're moving on to suggesting changing our RCS
> and moving all of our files around and reworking large portions of our
> architecture.
> 
> 
> > As of now, Brett and I don't even use the same .project file
> > (I've put mine in .cvsignore). That may have to change.
> >
> 
> Erik - Yes, this likely needs to find some common working default that
> we can check in to CVS. Perhaps we should compare our .project files
> and see why they're different. I think we might have done this before,
> but I can't remember the results.
> 
> > One minor thing is, that the hierarchy will get a lot deeper,
> > which makes dealing with the (narrow) Navigator view a bit more
> > difficult. But that's no big deal.
> >
> > Perhaps it is all worth a try.
> >
> 
> I don't think it's all worth a try just yet. It seems like many of
> things are big changes with questionable benefit and a definite impact
> on our immediate productivity.  I don't want to stop development to
> undertake any of these big changes just to come out on the other side
> of it with minimal gains.
> 
> I think we're much better off taking smaller steps, and carefully
> selecting which changes we make that either work well with our
> existing methods or provide a definite, tangible benefit.
> 
> ---Brett.
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] project-layout CVS/SVN

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

On 1/18/07, Erik Vos <eri...@hc...> wrote:
> > >Perhaps it is all worth a try.
> > I have just checkout rails and use the default .project.
> > Don'nt know if it
> > comes with Rails or is the Eclipse default one. But class and
> > java are in
> > the same dir and that is quit confusing for me.
>
> I think that is a difference between Brett's and my setup:
> I have created subfolders named src and bin for the sources
> and classes, respectively, and I think Brett is using the Eclipse default.
>

This is true.  I don't change many of Eclipse's defaults.

> My main problem was how to get the resources and XMLs in the classpath,
> but somehow I managed.
>
> I'm getting the feeling that you know a lot better how to set
> up such a project than Brett (sorry if I'm wrong, Brett!)
> and certainly than me, and I'm absolutely interested to see
> a proper one....
>

No apology needed. This is true, this is my first real development project.

I know that there are many things that most software projects do that
we're not doing. I'd love to move toward a more standardized setup.
However, I'd like to see all of the steps involved and make better
plans to do it in a way that doesn't disrupt our ability to still work
on the code itself.

---Brett.

Re: [Rails-devel] project-layout CVS/SVN

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

> >Perhaps it is all worth a try.
> I have just checkout rails and use the default .project. 
> Don'nt know if it
> comes with Rails or is the Eclipse default one. But class and 
> java are in
> the same dir and that is quit confusing for me.

I think that is a difference between Brett's and my setup:
I have created subfolders named src and bin for the sources
and classes, respectively, and I think Brett is using the Eclipse default.

My main problem was how to get the resources and XMLs in the classpath,
but somehow I managed.

I'm getting the feeling that you know a lot better how to set 
up such a project than Brett (sorry if I'm wrong, Brett!)
and certainly than me, and I'm absolutely interested to see 
a proper one....

Erik.

Re: [Rails-devel] rails-package rails.ui.swing SVG revenue

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

> With all these proposals, what is most important for me is
> what all these changes would mean for the way I work with Eclipse.
> With some trouble I have achieved a working relationship with Eclipse,
> and I don't really have a picture how that will change with such a new
> layout.
>


Rainer - I think this is the core problem I'm having with many of
these suggestions. Instead of learning how we've been working, and
doing it our way for a while, you're suggesting a lot of large,
drastic changes to accomodate your own preferences.

I think that we should focus more on reaching our existing goals.  So
far, I haven't received a patch for the first item you brought up (the
disclaimer) and now you're moving on to suggesting changing our RCS
and moving all of our files around and reworking large portions of our
architecture.


> As of now, Brett and I don't even use the same .project file
> (I've put mine in .cvsignore). That may have to change.
>

Erik - Yes, this likely needs to find some common working default that
we can check in to CVS. Perhaps we should compare our .project files
and see why they're different. I think we might have done this before,
but I can't remember the results.

> One minor thing is, that the hierarchy will get a lot deeper,
> which makes dealing with the (narrow) Navigator view a bit more
> difficult. But that's no big deal.
>
> Perhaps it is all worth a try.
>

I don't think it's all worth a try just yet. It seems like many of
things are big changes with questionable benefit and a definite impact
on our immediate productivity.  I don't want to stop development to
undertake any of these big changes just to come out on the other side
of it with minimal gains.

I think we're much better off taking smaller steps, and carefully
selecting which changes we make that either work well with our
existing methods or provide a definite, tangible benefit.

---Brett.

Re: [Rails-devel] place of versionNr. localisedText

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

> >In our case, it is included in LocalText (which is probably not 
> >the right place, I would prefer to move it to Game). 
> Before we use a property-file for the 
> system-spezific-constants, we use the
> Main-Class, having an Interface, so non-project-spezifik 
> classes can use
> this information
> If Games is such a Main class for non-ui-stuff, this would be 
> a good place
> for it
> But as I read my digits father, you have allready done it - great.

Game is kind of a main class for the game engine itself,
so this looked a logical place to me.

> >I have been thinking on how we can best manage our resource bundles 
> >(i.e. versions of LocalisedText_aa_BB.properties). 
> >The contents may still be a bit fluid, although it will 
> >settle down somewhat now all messages (should) have been included. 
> > 
> >I'm in favour of removing all comments and just leaving the 
> >properties, sorted alphabetically. The sorting makes a comparison of 
> >different versions very easy in a side-by-side scroller like
> >WinMerge. 
> >This means that we have to drop all pretension of having the 
> >bundle internally organised in some way, but that would be 
> >hard to do and maintain anyhow. 
> > 
> >In the past I have used this alphabetic sort in a commercial 
> >application with texts in 6 languages, and this way it was very 
> >easy to spot differences (missing or redundant entries). 
> > 
> >What do you think? 
> Some Comments are not up to date - right?
> I would prefer a mix - main groups and alphabetic order 
> insite a group.
> So a User has not to translate the hole file, if he just need 
> the normal
> ui-element to play with a friend, who can not read english.
> But as I read my digits, you have allready done it.

... yes, I had some spare time. Simple things can go fast with me...

I had not thought of your proposal which looks reasonable to me.
And indeed, TextPad (which I used for the sort) can sort selections as well.

The old file was badly organised, mostly because I was too lazy
to think about how to organise it, and even to stick to Brett's 
initial setup.
But if you know how to structure a resource bundle, feel free....

Erik.

Re: [Rails-devel] project-layout CVS/SVN

[Rainer M. <rai...@we...>]

>A move to Subversion might be a good idea,=20
>but I don't know either how to do that,=20
>nor what it would mean for how I'm currently working with Eclipse (see
below).
No great impact for Eclipse, the SVN-plugin looks allmost like the CVS.
I know how to transfer CVS to SVN, there is a transfer-programm I have =
used.
But Sourceforge is new for me and I do not know, what the admin can do.
There are little changes - like the overall-checkin-number instead of a
file-based-version-number, but there is a good short guide for new
svs-users, who know cvs.
=20
>> project-directory-layout:
>=20
>With all these proposals, what is most important for me is
>what all these changes would mean for the way I work with Eclipse. With
some trouble I have achieved a working=20
>relationship with Eclipse, and I don't really have a picture how that =
will
change with such a new layout.
>
>I suppose you'll have to provide some instructions on how to =
restructure my
Eclipse project.=20
>
>As of now, Brett and I don't even use the same .project file (I've put =
mine
in .cvsignore). That may have to change.
>
>One minor thing is, that the hierarchy will get a lot deeper, which =
makes
dealing with the (narrow) Navigator view a bit more difficult. But =
that's no
big deal.
>
>Perhaps it is all worth a try.
I have just checkout rails and use the default .project. Don'nt know if =
it
comes with Rails or is the Eclipse default one. But class and java are =
in
the same dir and that is quit confusing for me.
You can tell Eclipse, that diffrent dirs (like test and main) should be
shown in own sub-folder, if you really need it. If you are coding, you
don'nt have to 'overlook' non-java-files.
But anyway, it's had to explain and yes, the Navigator shows some more ,
normaly allways open subfolders, before the code comes.

Rainer