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