search

RPTools / maptool

Virtual Tabletop for playing roleplaying games with remote players or face to face.
http://rptools.net
GNU Affero General Public License v3.0
801 stars 262 forks source link

[Feature]: Start server at startup #3873

Open Snarfbur opened 1 year ago

Snarfbur commented 1 year ago

Feature Request

Motivation I want to run the server part of the MapTool for my campaign on a cloud server, where the apps are running in Docker containers. To have this as easy to maintain as possible there have to be some small, useful enhancements to be done.

Goals

1. Clear separation between MapTool system and usage data An update of a current MapTool instance means:

To be clear. Mixing data for system, developers and users is never a good idea. There are reasons, why system relevant data is normally read only. Of course, some parameters have to be in this file, because they are setting VM parameters, not changeable later. On some (now) rare circumstances even a user has to 'experiment' with them. But setting the language or the data folder location are not such parameters.

To be compatible to old versions the data in the new location should not overwrite the MapTool.cfg or runtime arguments (cmdOptions) values. With this low priority it is always for the MapTool developer possible to overwrite really necessary values for everybody in the MapTool.cfg and temporary overwriting with runtime arguments possible.

2. Option on startup to start a server A restart of the application can be implemented e.g. with docker parameters for the container or with a controller script on the OS. To start the server inside the application you need currently a person or a special robot software to simulate the user actions. A startup parameter to start the server during the initialization of the application would make this much easier.

3. Refactor: UI startup frame The options have of course to be added to the startup frame. Because the current description on the right side is not very helpful for people with problems, this is a good moment to rearrange the view and give a user at least concrete hints to find the correct parameter in the MapTool.cfg file.

The Solution you'd like

1. Clear separation between MapTool system and usage data a. Add argument (option) parameters

Implement language and country switch. Get sure that data-dir is used.

b. User startup.prefs file Create & Read Preference file under MAPTOOL_DATADIR/config named startup.prefs. Note: If this is not update-save maybe an own DIR under the data folder or an own folder in parallel

Parameter-List:

See https://wiki.dev.rainer-muetze.de/project:mt:ug:stratupprops

2. Option on startup to start a server Check, if we can use already the original startup sequence, where the private server is created. Check, what additional parameters are needed (first only for one server initialization variant)

3. Refactor: UI startup frame Separate user from system settings, users first

Note: Who does the translations?

Alternatives that you've considered.

1. Clear separation between MapTool system and usage data An OS specific shell script, which manipulate the MapTool.cfg file after the update.

2. Option on startup to start a server A special robot software to simulate the user actions. I remember that we used 3 special testing & simulation tools in my old company. The one our team tester was using was even free to use and JavaScript based. But this is 'Shooting at sparrows with cannons.'

3. Refactor: UI startup frame None

Additional Context

I will implement this by myself as a good start point for contributing MT.

I have a fresh started wiki for my development projects: https://wiki.dev.rainer-muetze.de with a technical Documentation for this issue: https://wiki.dev.rainer-muetze.de/project:mt:startup:tecdesc (To document decisions and alternatives coming up during the implementation)

More Information about me:

On my branch, I will do this in 3 issues. Because each one depends on the others and I added more or less only small additional stuff I'm not sure if you want it more separated or as it is. Pure Agile says separate it, but I'm sure if separated, at least the refactoring of the startup frame will never be done.

Snarfbur commented 1 year ago

I will start implementation today. Have only done agile project management and some clean code consulting for the last 10 years. So this is my first major programming project in Java in more than 10 years. Let's see how far I get :-)

Snarfbur commented 1 year ago

I finished Part 1and updated the issue to the current solution.

Snarfbur commented 1 year ago

During the review of the code of the PreferencesDialog class for Part 3 I see 4 solutions:

  1. Complete redesign with JavaFX -> I have no experience with it.
  2. Complete redesign in Swing to get a better overview -> To much effort for a dead solution.
  3. Add just the additional properties in 'Start'-tab and change the left side information text -> You use a UI-Tool I have no experience)
  4. Do nothing (maybe just update the information text).

Since in the productive version 1.12.2. under windows I cannot see any correct value I tend to 4!

Since there is no development solution to see anything on this tab and under windows I see no correct values I have no idea, how to test a change in the dialog effective.