rails-devel — List for discussion of Rails development

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

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

> rails-package:
> 
> >We have not discussed this before, and I like the idea of putting
> >rails in 
> >front of all package names. 
> ...
> >That seems good. If you send me a patch for just moving and renaming
> >the 
> >existing GameTest, I'll apply that.
> 
> OK - you will get a RailsMain under rails, witch will 
> integrate the rest of
> the GameTest, which is not in RailsMain yet.
> 
> Moving existing code to a different directory has a main 
> drawback in CVS.
> You will have a break in History. 
> That is one of the reasons, why many people are changing to 
> SVN (SubVersion
> http://subversion.tigris.org/ ),which is developed by the 
> same main peoples,
> who have develop CVS. 
> I know, that you can use SVN under Souceforge, but I don't 
> know how you can
> switch to it under Sourceforge. I have convert some 
> CVS-Projects into SVN -
> easy doing.
> If we don't change, we should discuss some other possible 
> layout changes
> also, so we will have this break not to often:

A move to Subversion might be a good idea, 
but I don't know either how to do that, 
nor what it would mean for how I'm currently working with Eclipse
(see below).
 
> project-directory-layout:
> I'm using maven (http://maven.apache.org/ ) as a build &
> site-generation-tool. 
> They have a clear project-dir-layout
> (http://maven.apache.org/guides/introduction/introduction-to-t
> he-standard-di
> rectory-layout.html ).
> We do not need all dirs by now, but there are good reasons, 
> why many people
> use this layout in general, even if thy don't use maven or 
> even know it.
> Have a clear devision between different code-languages, resources,
> configurations and documentation makes it easer for new developers,
> spezially, if you use a common layout.
> Separation of test- and main-code makes it easy to build a 
> smaller jar,
> without the testing-overhead.
> If you want, I can move the project into the maven layout at 
> this weekend,
> including eclipse project files and you can have a look at it.
> To make it clear: I don't want to use maven at this project, just the
> dir-layout. At my company-projects, we are using maven just for the
> morning-checkout, for the test automatisation on the 
> Development-Server and
> to build the project websites overnight. The last two, we 
> don't have at
> rails and the first think is perfect done by the Eclipse 
> CVS/SVN-Plugin.
 
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.

I suppose you'll have to provide some instructions on how to restructure
my Eclipse project. 

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

[Rails-devel] Rails-Package

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

>> I propose that we agree beforehand upon the person who does it, and 
>> the time that it will be done, so that anyone else can stay away for a 
>> while.
>>
>> I would be prepard to do it next Sunday,
>> probably in the (European) afternoon.
>>
>
>I'm not sure if I'll have time before then.
>

I haved reserved the Saturday for rails, doing RailsMain and swing.* or
layout moving.
Whatever you want. Please think about the general project layout before
breaking the CVS-History.

Regards
Rainer

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

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

>On the version number, I wonder if we can't better leave that
>hardcoded. 
>The number is used to find the right jar file to retrieve XML files 
>and tile pictures. So it should not be tampered with. 
> 
>I have seen versions numbers automatically generated in some 
>development environments. In such cases, the generator changes 
>the source code to insert the version number in some predefined
>place. 
We do this at Work, using a project-spezific-property-file, witch is packed
in the project.jar
the default user.properties are not in the jar, only in the
packed-distribution-file.

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



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

Regards
Rainer

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

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

rails-package:

>We have not discussed this before, and I like the idea of putting
>rails in=20
>front of all package names.=20
...
>That seems good. If you send me a patch for just moving and renaming
>the=20
>existing GameTest, I'll apply that.

OK - you will get a RailsMain under rails, witch will integrate the rest =
of
the GameTest, which is not in RailsMain yet.

Moving existing code to a different directory has a main drawback in =
CVS.
You will have a break in History.=20
That is one of the reasons, why many people are changing to SVN =
(SubVersion
http://subversion.tigris.org/ ),which is developed by the same main =
peoples,
who have develop CVS.=20
I know, that you can use SVN under Souceforge, but I don't know how you =
can
switch to it under Sourceforge. I have convert some CVS-Projects into =
SVN -
easy doing.
If we don't change, we should discuss some other possible layout changes
also, so we will have this break not to often:

project-directory-layout:
I'm using maven (http://maven.apache.org/ ) as a build &
site-generation-tool.=20
They have a clear project-dir-layout
(http://maven.apache.org/guides/introduction/introduction-to-the-standard=
-di
rectory-layout.html ).
We do not need all dirs by now, but there are good reasons, why many =
people
use this layout in general, even if thy don't use maven or even know it.
Have a clear devision between different code-languages, resources,
configurations and documentation makes it easer for new developers,
spezially, if you use a common layout.
Separation of test- and main-code makes it easy to build a smaller jar,
without the testing-overhead.
If you want, I can move the project into the maven layout at this =
weekend,
including eclipse project files and you can have a look at it.
To make it clear: I don't want to use maven at this project, just the
dir-layout. At my company-projects, we are using maven just for the
morning-checkout, for the test automatisation on the Development-Server =
and
to build the project websites overnight. The last two, we don't have at
rails and the first think is perfect done by the Eclipse CVS/SVN-Plugin.




rails.ui.swing:

>In that case I would propose rails.ui.swing.=20
>I reckon that at some point we will need separate classes for
>ui-related (or client-side) logic=20
>that is common to all possible UI implementations, such as the code
>that interfaces with the=20
>back-end Round instances. Such classes could then be in rails.ui.=20
...
>I reckon that at some point we will need separate classes for
>ui-related (or=20
>> client-side) logic=20
>>=20
>> that is common to all possible UI implementations, such as the code
>that=20
>> interfaces with the=20
>>=20
>> back-end Round instances. Such classes could then be in rails.ui.=20
>>=20
>=20
>Agreed. We can move the Swing components to rails.ui.swing.=20
Very good Idea.=20
So we will have rails.ui and some sub-packages for general ui-purpose =
(like
interfaces, which other classes can use, without knowing, what ui is =
used)=20
and ui.swing for a concret implementation in swing. I will do that on =
the
way of my redesign, if you can wait for me.



why rails arguments:
>- default player names, useful for testing.=20
>We now have 0, 1 and 2 playing, and I would prefer to replace=20
>these anonymi by Alice, Bob and Charlie (or names like that).=20
>So why not make it configurable.=20
...
>> Well, GameTest was of course a temporary name anyway.=20
>Correct. However, I'm not sure I understand why you've added in
>using=20
>command-line arguments.=20
>=20
>I really don't want to have differences in functionality. At the very
>least,=20
>if there's a command-line argument for something, there also needs to
>be a=20
>way for the same feature to be accessed in the UI.=20
>=20
>So, this particular part of your patch needs a bit more work, and
>probably=20
>some additional discussion.=20
>=20
OK, the command-line argument are in no way a try to get diffrences in
funtionality. It should be only a shortcut for testing purpose.
Erics default player names should not be included in code for users. =
Call
rails with the playernames as arguments would remove the need of the =
names
in code or preference-files.
If we want to automate the tests later on, we can do it by calling rails
with the proper arguments.
And yes, it needs more work, but I make the old GameTest absulate and =
Erik
has implemented new features, with need initialisation at start up time. =
To
minimize the interferences, I thought, it would be good to get RailsMain
into CVS, so Erik can make his next initialisations into this class, =
instead
of StartGame, witch I have same to copy to RailsMain to be up to date.
And also I introduce rails at a new overall parent package and know, =
that
this will give more discussion, because it is a good idea, but has some
drawbacks on CVS (see rails-package).
And last, but not least, the arguments will speedup manual tests.




SVG and revenue-calculation:=20
>=20
> ... Yes, it does, but it's not perfect yet.=20
>=20
>Tile display and tile-handling logic now use completely=20
>separate data (the GIFs and SVGs for display, and Tiles.xml=20
>for the logic). Both have been derived from Marco Rocci's=20
>TileDesigner database (which we have extended with a lot of
>preprinted=20
>tiles).=20
>=20
>Tiles.xml should contain enough data to base route and revenue=20
>calculation on, but all of that is not done yet. It's contents is=20
>currently only used to prevent invalid tile lays where track=20
>would end up at forbidden hex sides (sea, preprinted grey tiles,
>etc.)=20
OK, if you havend done revanue-calculation by the day, I have finished =
my
start todo's,
I will have a look for the drawing-code also, spezialy because I would =
like
to show the calculated routes.



Regards
Rainer

Re: [Rails-devel] Updates

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

On 1/18/07, Erik Vos <eri...@hc...> wrote:
> I have moved the version string from LocalText to Game.
> In addition, I have cleaned up LocalisedText.properties
> and sorted it alphabetically.
>
> Another thing I would like to do soon (if noone else does it,
> of course) is the change of all package names by prepending rails.
> As this affects almost all files, it will be a huge update.
>

Probably a good idea.

> I propose that we agree beforehand upon the person who does it,
> and the time that it will be done, so that anyone else
> can stay away for a while.
>
> I would be prepard to do it next Sunday,
> probably in the (European) afternoon.
>


I'm not sure if I'll have time before then.

---Brett.

[Rails-devel] Updates

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

I have moved the version string from LocalText to Game.
In addition, I have cleaned up LocalisedText.properties
and sorted it alphabetically.

Another thing I would like to do soon (if noone else does it,
of course) is the change of all package names by prepending rails.
As this affects almost all files, it will be a huge update.

I propose that we agree beforehand upon the person who does it, 
and the time that it will be done, so that anyone else
can stay away for a while.

I would be prepard to do it next Sunday, 
probably in the (European) afternoon.

Erik Vos

Re: [Rails-devel] Resource bundles

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

On 1/17/07, Erik Vos <eri...@hc...> wrote:
> 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?
>

I think that's fine. The internal organization was more for assuring
coverage.  Now that we've got things beyond that stage, we can move to
a more managable layout.


---Brett.

Re: [Rails-devel] Version number

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

> In our case, it is included in LocalText (which is probably not
> the right place, I would prefer to move it to Game).
>

Agreed. It needs to move.  I put it there simply because I couldn't
think of anywhere else to put it.

However, we should probably just define it as a final static string somewhere.

---Brett.

[Rails-devel] Resource bundles

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

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?

Erik Vos

Re: [Rails-devel] Version number

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

> > my.properties:
> > good place for user-properties (like language/country). I 
> > would like to use
> > rails.properties for version-number and other system things, 
> > with normally
> > the user should not change.
> 
> Yes, I had already thought of putting language there.
> 

On the version number, I wonder if we can't better leave that hardcoded.
The number is used to find the right jar file to retrieve XML files
and tile pictures. So it should not be tampered with.

I have seen versions numbers automatically generated in some
development environments. In such cases, the generator changes
the source code to insert the version number in some predefined place.
In our case, it is included in LocalText (which is probably not 
the right place, I would prefer to move it to Game).

Erik.

[Rails-devel] New properties and localisations

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

I have added a number of properties to my.properties:

1. Ways to define a locale. As it is now, it is a bit of an overkill,
allowing entering all of language, country and locale code
(which includes both language and country, and optionally a variant).
I suppose we could get rid of locale, but I'll leave it in for now.
The locale affects the resource bundle that will be selected,
see my separate post on that subject.

2. A custom money format. 
If specified, it will override anything specified in Game.xml.

3. Next to the game report directory, also options to
change the report filename (date/time part and extension).
Date/time must be valid pattern characters as in SimpleDateFormat.
I know this is a stretch for most users, so this needs 
documentation if we leave it in.

4. Default player names (e.g. Alice,Bob,Charlie in stead of 0,1,2).
By default the player name boxes are now empty.

While testing the above, I noticed that Game.initialise() was called twice.
I have cleaned that up.

I have also added many more localisations. I believe that now 
all user-visible text (except the log) is localised.

I think the localisation file still needs to be cleaned up somewhat.
Again, see my separate post.

Erik Vos

Re: [Rails-devel] log4j, my.properties

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

> >I have also removed the prefix log/ to the log file name
> >to avoid errors if there is no log directory.
> I like a own log-dir. can'nt you just create the dir, if it 
> does not exist?

Well, this is all handled by log4j. 
I don't want to go as far as modifying that by subclassing its components.

> >My own version of my.properties is now named my_my.properties.
> >It is invoked by specifying -Dconfigfile=my_my.properties 
> >on the command line (in Eclipse by adding this option as a 
> "VM argument").
> 
> >GameTest picks up this argument. If absent, the default name
> >my.properties is used.
> 
> the -D option is a good idea for own versions, not the 
> default one for the end-users.

Exactly, that is the sole purpose of this option.

> If we use our firstname as prefix, we can checkin our own 
> version also. 

I don't want to check in own versions, let try to keep the code base clean.

> I will add the nessesary thinks in my RailsMain-Class

Great.

Erik.

Re: [Rails-devel] log4j, my.properties

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

my.properties

> I'd prefer to not have too many configuration files running around.
> Ideally, all preferences should be set in the UI, so the user doesn't
> have to manually edit the configuration file.

You can save properties from programm into the properties-file. So I would=
 use my.properties for all user-preferences.
He can then use the my.properties-file with a text-editor or if we have im=
plement it, make the changes with a option-dialog-window.

> I'd prefer to not have too many configuration files running around.
> Ideally, all preferences should be set in the UI, so the user doesn't
> have to manually edit the configuration file.

Two propeties-files are normally enough. One for the user and one for the =
system.



>I have also removed the prefix log/ to the log file name
>to avoid errors if there is no log directory.
I like a own log-dir. can'nt you just create the dir, if it does not exist=
=3F


>My own version of my.properties is now named my=5Fmy.properties.
>It is invoked by specifying -Dconfigfile=3Dmy=5Fmy.properties=20
>on the command line (in Eclipse by adding this option as a "VM argument")=
.

>GameTest picks up this argument. If absent, the default name
>my.properties is used.

the -D option is a good idea for own versions, not the default one for the=
 end-users.
If we use our firstname as prefix, we can checkin our own version also.=20
I will add the nessesary thinks in my RailsMain-Class



>> We should capture this somewhere. Perhaps we should make use of
>> SourceForge's documentation tools=3F

>I'm not familiar with those but it sounds good.
me too



>For all users we will need to document the contents of the properties fil=
e.
>Both my.properties and GameTest.java already include comments
>that could serve as a start for such document(s).
I like dokumentation where you need it. In this case comments should be go=
od enough I think, particular if we write also a option-dialog-window.


Regards
Rainer

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

Erweitern Sie FreeMail zu einem noch leistungsst=E4rkeren E-Mail-Postfach!	=09
Mehr Infos unter http://freemail.web.de/home/landingpad/=3Fmc=3D021131

Re: [Rails-devel] FW: First verry little patch

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

On 1/16/07, Erik Vos <eri...@hc...> wrote:
>
>  Hi Rainer,
>
> BTW I am redirecting this post to the mailing list as it contains items o=
f
> general interest.
>
>  Here comes my first, very little patch:
>
> A new main class with which you can start rails with arguments (Example:
> RailsMain 1830 =96 p1 p2 p3 p4).
>
> Well, GameTest was of course a temporary name anyway.
>


Correct.  However, I'm not sure I understand why you've added in using
command-line arguments.

I really don't want to have differences in functionality. At the very least=
,
if there's a command-line argument for something, there also needs to be a
way for the same feature to be accessed in the UI.

So, this particular part of your patch needs a bit more work, and probably
some additional discussion.



By the way: I would prefer a main parent package, where all other packages
> are children from. SUN guidelines tells about a location.company.packages=
tructure. Normally rails would be
> org.rails.*, but I think rails.* would be enough for now. If you have
> discussed this before and did'nt want it, I will refactore the swing pack=
age
> to root.
>
> We have not discussed this before, and I like the idea of putting rails i=
n
> front of all package names.
>

That seems good.  If you send me a patch for just moving and renaming the
existing GameTest, I'll apply that.


I have used swing as a package name instead of UI, because maybe someone
> else would like to make a SWT-UI or a JSP-UI.
>
> In that case I would propose rails.ui.swing.
>


I reckon that at some point we will need separate classes for ui-related (o=
r
> client-side) logic
>
> that is common to all possible UI implementations, such as the code that
> interfaces with the
>
> back-end Round instances. Such classes could then be in rails.ui.
>

Agreed.  We can move the Swing components to rails.ui.swing.


Erik.
>
> Second maybe I have to transfer your UI-Components to my UI-Components
> part by part. With my own package, I can use both classes at the same tim=
e
> and do not have to use different class names for the same thing.
>
>
>
> Hope you like it
>
>
>
> Regards
>
> Rainer
>
>

Re: [Rails-devel] Log4j logging, my.properties GIF/SVG

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

> my.properties:
> good place for user-properties (like language/country). I 
> would like to use
> rails.properties for version-number and other system things, 
> with normally
> the user should not change.

Yes, I had already thought of putting language there.

Other potential properties that crossed my mind today:

- a location (directory) name to store copies of the Game Report
(as currently replaced in the Log/Report window).
Report file names would be like 18XX-date-hhmm.txt or such,
18XX being the real game name).
Absence of this item would mean: don't store reports.

- default player names, useful for testing.
We now have 0, 1 and 2 playing, and I would prefer to replace
these anonymi by Alice, Bob and Charlie (or names like that).
So why not make it configurable.
 
> GIF/SVG:
> Maybe I haven not read your discussion about revenue 
> calculating and trail
> showing yet complete, but I could not think about showing the 
> track, witch
> was used for best revenue with GIF-plates. I did not know by 
> now what SVG
> means, but I hope it has something to do with vector-graphics.

Yes, it does, but it's not perfect yet.

Tile display and tile-handling logic now use completely
separate data (the GIFs and SVGs for display, and Tiles.xml 
for the logic). Both have been derived from Marco Rocci's 
TileDesigner database (which we have extended with a lot of preprinted
tiles).

Tiles.xml should contain enough data to base route and revenue
calculation on, but all of that is not done yet. It's contents is
currently only used to prevent invalid tile lays where track
would end up at forbidden hex sides (sea, preprinted grey tiles, etc.)

Erik.

[Rails-devel] FW: First verry little patch

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

Hi Rainer,
 
BTW I am redirecting this post to the mailing list as it contains items of
general interest.

Here comes my first, very little patch:

A new main class with which you can start rails with arguments (Example:
RailsMain 1830 - p1 p2 p3 p4).

Well, GameTest was of course a temporary name anyway.

By the way: I would prefer a main parent package, where all other packages
are children from. SUN guidelines tells about a location.company.package
structure. Normally rails would be org.rails.*, but I think rails.* would be
enough for now. If you have discussed this before and did'nt want it, I will
refactore the swing package to root.

We have not discussed this before, and I like the idea of putting rails in
front of all package names.

I have used swing as a package name instead of UI, because maybe someone
else would like to make a SWT-UI or a JSP-UI. 

In that case I would propose rails.ui.swing.

 

I reckon that at some point we will need separate classes for ui-related (or
client-side) logic 

that is common to all possible UI implementations, such as the code that
interfaces with the

back-end Round instances. Such classes could then be in rails.ui.

 

Erik.

Second maybe I have to transfer your UI-Components to my UI-Components part
by part. With my own package, I can use both classes at the same time and do
not have to use different class names for the same thing.

 

Hope you like it

 

Regards

Rainer

 

 

 

 

 

Re: [Rails-devel] Log4j logging, my.properties GIF/SVG

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

> GIF/SVG:
> Maybe I haven not read your discussion about revenue calculating and trail
> showing yet complete, but I could not think about showing the track, witch
> was used for best revenue with GIF-plates. I did not know by now what SVG
> means, but I hope it has something to do with vector-graphics.
>

Yes, Scalable Vector Graphics (SVG) is the W3C's vector graphics
format. It's a graphics format based on XML.

Their site is at http://www.w3.org/Graphics/SVG/

We're currently using the Batik toolkit (
http://xmlgraphics.apache.org/batik/ ) for rendering SVG. The current
SVG rendering code is very simplistic and is a bit of a kludge. I know
there are much better ways of using Batik, but just haven't had the
time to implement them.

---Brett

Re: [Rails-devel] Log4j logging, my.properties GIF/SVG

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

Hi,

Log4j:
Sounds good to me. Have no practice in logging yet. Had used log4j only =
with
external packages and using simple verbose & debug flags for
log-output-management (which are set in a property-file).

my.properties:
good place for user-properties (like language/country). I would like to =
use
rails.properties for version-number and other system things, with =
normally
the user should not change.

GIF/SVG:
Maybe I haven not read your discussion about revenue calculating and =
trail
showing yet complete, but I could not think about showing the track, =
witch
was used for best revenue with GIF-plates. I did not know by now what =
SVG
means, but I hope it has something to do with vector-graphics.

Regards=20
Rainer

[Rails-devel] StartRound fixes and cosmetic changes

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

Just minor things today:
- during testing I noticed some glitches in the 1835 and 1870 start rounds,
which pointed to defects in the StartRound code. These are now fixed.
- Some more localisations. BTW I'm only localizing text that is (or can be
made)
visible through the UI. I don't see a point in localising debug log
messages.
- A few cosmetic changes.

Erik Vos

Re: [Rails-devel] Log4j logging

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

> > My own version of my.properties is now named my_my.properties.
> > It is invoked by specifying -Dconfigfile=my_my.properties
> > on the command line (in Eclipse by adding this option as a 
> "VM argument").
> >
> > GameTest picks up this argument. If absent, the default name
> > my.properties is used.
> >
> 
> 
> We should capture this somewhere. Perhaps we should make use of
> SourceForge's documentation tools?

I'm not familiar with those but it sounds good.

The -D feature is mainly interesting for developers; other users
will not likely have a need for two different properties files.

For all users we will need to document the contents of the properties file.
Both my.properties and GameTest.java already include comments
that could serve as a start for such document(s).

Erik.

Re: [Rails-devel] Log4j logging

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

On 1/15/07, Erik Vos <eri...@hc...> wrote:
> > I think we don't really need more than one log file just yet.
> >
> > I definitely don't want to clutter up a user's drive unnecessarily.
> >
> > It looks like we should use the FileAppender.
>
>
> OK, I have reduced the log4j options in my.properties to
> just a simple log file that is overwritten for each new game.
> I have removed the ConsoleAppender.
>
> I have also removed the prefix log/ to the log file name
> to avoid errors if there is no log directory.
>


Perfect. :-)


> My own version of my.properties is now named my_my.properties.
> It is invoked by specifying -Dconfigfile=my_my.properties
> on the command line (in Eclipse by adding this option as a "VM argument").
>
> GameTest picks up this argument. If absent, the default name
> my.properties is used.
>


We should capture this somewhere. Perhaps we should make use of
SourceForge's documentation tools?


> Only my.properties will exist in CVS.
> So, if you want to save my original version (or your own version)
> of this file, please rename it before you synchronise!
>

Will do.

Re: [Rails-devel] Log4j logging

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

> I think we don't really need more than one log file just yet.
> 
> I definitely don't want to clutter up a user's drive unnecessarily.
> 
> It looks like we should use the FileAppender.


OK, I have reduced the log4j options in my.properties to 
just a simple log file that is overwritten for each new game.
I have removed the ConsoleAppender.

I have also removed the prefix log/ to the log file name
to avoid errors if there is no log directory.

My own version of my.properties is now named my_my.properties.
It is invoked by specifying -Dconfigfile=my_my.properties 
on the command line (in Eclipse by adding this option as a "VM argument").

GameTest picks up this argument. If absent, the default name
my.properties is used.

Only my.properties will exist in CVS.
So, if you want to save my original version (or your own version)
of this file, please rename it before you synchronise!

Erik.

Re: [Rails-devel] Log4j logging

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

On 1/13/07, Erik Vos <eri...@hc...> wrote:
> Speaking about that, the version of my.properties that I have checked in
> may not be the most user-friendly one, as it creates an indefinite
> amount of logfiles.
>

Yeah, that's not good.

> Logging options ("appenders") that don't are:
> - the RollingFileAppender, which rolls over at a certain size,
> whereby a maximum number of old logs can be set.
> - the FileAppender in overwrite mode, which creates a new log
> in each run (i.e. game). No backups with this one.
>
> Any suggestions about the way to go?
> In theory we could develop out own appender, which might
> do whatever we want, but I have already found that
> grasping the inner workings of log4j is not easy.
>

I think we don't really need more than one log file just yet.

I definitely don't want to clutter up a user's drive unnecessarily.

It looks like we should use the FileAppender.


>
> Could we give a different name to the CVS version,
> and tell the user to change the name to get it working?
>

I don't like that option.  I'd like to make things as easy as possible
for users. Most people want their software to "just work" without much
setup.

So, we should provide a properties file with sensible defaults. Some
will want to change them, most will just use what we give them.


---Brett

Re: [Rails-devel] Log4j logging

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

> I'd prefer to not have too many configuration files running around.
> Ideally, all preferences should be set in the UI, so the user doesn't
> have to manually edit the configuration file.

Not sure if it is feasible and worthwhile for log4j logging.

Speaking about that, the version of my.properties that I have checked in
may not be the most user-friendly one, as it creates an indefinite 
amount of logfiles.

Logging options ("appenders") that don't are:
- the RollingFileAppender, which rolls over at a certain size, 
whereby a maximum number of old logs can be set.
- the FileAppender in overwrite mode, which creates a new log
in each run (i.e. game). No backups with this one.

Any suggestions about the way to go?
In theory we could develop out own appender, which might
do whatever we want, but I have already found that
grasping the inner workings of log4j is not easy.


In addition, we should distinguish between the my.properties
version in CVS, which should be a sensible default version,
and the version that we really use ourselves.

Could we give a different name to the CVS version,
and tell the user to change the name to get it working?

Erik.

Re: [Rails-devel] Log4j logging

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

>
> Do we already have any choice items like that?
> I don't think so, but once we have such items,
> we should find a place to store these.
>


I thought we might, but perhaps we don't.


> I don't know how such storage is realised in other systems.
> If it's a properties file, I would suggest to create
> another one for that purpose: one that can be overwritten
> by the program after any change.
> my.properties would then be reserved for properties
> that are not (or not yet) maintainable via the UI.
>

I'd prefer to not have too many configuration files running around.
Ideally, all preferences should be set in the UI, so the user doesn't
have to manually edit the configuration file.


---Brett