[Freecol-developers] [PATCH] client: control: ConnectController: clean out dead code

[Enrico Weigelt, metux IT consult]

---
.../sf/freecol/client/control/ConnectController.java | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/src/net/sf/freecol/client/control/ConnectController.java b/src/net/sf/freecol/client/control/ConnectController.java
index 50eb9aa83d2..0ef34de6e53 100644
--- a/src/net/sf/freecol/client/control/ConnectController.java
+++ b/src/net/sf/freecol/client/control/ConnectController.java
@@ -129,7 +129,7 @@ public final class ConnectController extends FreeColClientHolder {
}
}
}
-
+
logger.info("Logout begin for client " + player.getName()
+ ": " + reason.toString());
return askServer().logout(player, reason);
@@ -480,21 +480,13 @@ public final class ConnectController extends FreeColClientHolder {
try { Thread.sleep(1000); } catch (InterruptedException ie) {}
}
askServer().disconnect();
-
+
switch (fcc.getServerState()) {
case PRE_GAME: case LOAD_GAME:
// Name is good
break;

case IN_GAME:
- /*
- // Disable this check if you need to debug a multiplayer client.
- if (FreeColDebugger.isInDebugMode(FreeColDebugger.DebugMode.MENUS)) {
- getGUI().showErrorMessage(StringTemplate
- .template("client.debugConnect"));
- return false;
- }
- */
// Find the players, choose one.
List<String> names = fcc.getVacantPlayerNames();
if (names.isEmpty()) return false;
@@ -523,7 +515,7 @@ public final class ConnectController extends FreeColClientHolder {
*/
public void mainTitle() {
final FreeColClient fcc = getFreeColClient();
-
+
if (fcc.isMapEditor()) fcc.setMapEditor(false);

if (fcc.isLoggedIn()) {
@@ -532,12 +524,12 @@ public final class ConnectController extends FreeColClientHolder {
}
return;
}
-
+
fcc.stopServer();
getGUI().removeInGameComponents();
getGUI().mainTitle();
}
-
+
/**
* Reset to the NewPanel (except in the map editor).
*/

[Michael T. Pope]

On Wed, 25 Jan 2017 10:10:18 +0100
"Enrico Weigelt, metux IT consult" <***@gr13.net> wrote:

No. Please, enough of these. The code below is commented out
temporarily to make it easier to test multiplayer while I extract more DOM
from the login code.

Post by Enrico Weigelt, metux IT consult
- /*
- // Disable this check if you need to debug a multiplayer client.
- if (FreeColDebugger.isInDebugMode(FreeColDebugger.DebugMode.MENUS)) {
- getGUI().showErrorMessage(StringTemplate
- .template("client.debugConnect"));
- return false;
- }
- */
// Find the players, choose one.
List<String> names = fcc.getVacantPlayerNames();
if (names.isEmpty()) return false;

You are so keen to mess with stuff that you do not know the history of
or reasons for... and I am faced with a huge pile of patches to review.

We have a resource problem here. FreeCol is a small project with few
contributors. We need to focus on high priority tasks, not
counterproductive stuff like the above.

Cheers,
Mike Pope

[Enrico Weigelt, metux IT consult]

Post by Michael T. Pope
No. Please, enough of these. The code below is commented out
temporarily to make it easier to test multiplayer while I extract more DOM
from the login code.

Why not just keeping such things in a separate patch queue, that can be
applied when needed?

OTOH, the code path is so rarely called, that it easily could easily be
activated by a config flag, which would be *much* cleaner.


--mtx

[Michael T. Pope]

On Wed, 25 Jan 2017 11:06:39 +0100

Post by Enrico Weigelt, metux IT consult

Post by Michael T. Pope
No. Please, enough of these. The code below is commented out
temporarily to make it easier to test multiplayer while I extract more DOM
from the login code.

Why not just keeping such things in a separate patch queue, that can be
applied when needed?

Please stop, and take a look at what you are doing. You just submitted a
patch to remove a comment. This is almost the definition of pointless,
and in this case outright unhelpful, and you think that I should carry
*comment* patches in my queue? I am left now to seriously question your
judgement.

Not that you seem to be listening. I believe I have made some remarks
about priorities and "Fix stuff that is broken". Repeatedly. But perhaps
I am right above, and your judgement is so poor that you can not tell what
is actually important.

I will be delighted to be proven wrong, and in due course I will give all
your patches careful attention as is my responsibility. I am actually
moderately hopeful that the feature container one will show a
*measurable* improvement when it shows up in testing. However I do not
intend to repeat myself further on the subject of your misplaced
enthusiasm for micro-optimization. You may interpret any future
silence from me as such.

Cheers,
Mike Pope