Prevent users from "double clicking" the server jar

[turt2live]

This is open as an open discussion and for implementation pending.

Many users tend to "double click" the server jar, therefore preventing them from starting the server normally when they use their batch file (see: binding exceptions).

This can be circumvented in a very simple if statement in the main method:

if (System.console() == null) {
    return;
}

This basically means that if a console is not available, or one is not being used, the application exits and therefore does not use many resources as a background process.

[the-maldridge]

Would it be possible to display an alert that the jar was invoked improperly, perhaps with the web address to the installation guide.

[jaredStef]

I think that if statement and all is good, but before it terminates it generates the start file based on the operating system returned in System.getProperty("os.name"); Displaying a javafx window telling the user more information is also something to consider.

[maxov]

I know we're trying to prevent against user stupidity here, but considering that the JAR is executable it should at least behave correctly when someone tries to execute it, no matter if they do it with a batch file or not.

I haven't seen this kind of behavior in any previous executable JAR. If any user tries to double-click on the JAR and run it, it'll suddenly close for "apparently no reason". What kind of convoluted behavior is this? There would be a large increase of number of issues from users who are not sure why the JAR is not running.

If you insist on doing this, I would pop up a JOptionPane asking to try running from the command line with two options: 'continue' or 'exit'. Clicking continue would keep running the JAR without a console, and clicking exit would exit glowstone so that the user could try again. This way at least the user knows what is happening and is notified that what they're doing is not recommended.

[gdude2002]

Why can't we just have it open a terminal? I'm sure JARs can do that.

[maxov]

@gdude2002 Pretty much the only way that terminals can be opened is by executing a system command which would be "fun" to get working cross-platform and cross-system. Even then I'm not sure how to pipe output to that terminal.

Possibly another way to do this would be to open a terminal-like GUI with the continue or exit buttons, somewhat like this:

[jaredStef]

I feel that most users wouldn't heed the warning and would run it from there all of the time. The user would think hmm scary, hacker terminal or nice gui. GUI!

[turt2live]

I haven't seen this kind of behavior in any previous executable JAR. If any user tries to double-click on the JAR and run it, it'll suddenly close for "apparently no reason". What kind of convoluted behavior is this? There would be a large increase of number of issues from users who are not sure why the JAR is not running.

They are completely unaware that the jar is running in the first place. Clearly the general consensus in the first few messages is to have some kind of notification that they are doing something that they shouldn't be doing, and I agree.

Pretty much the only way that terminals can be opened is by executing a system command which would be "fun" to get working cross-platform and cross-system. Even then I'm not sure how to pipe output to that terminal.

Java can handle all of this with trivial code.

Possibly another way to do this would be to open a terminal-like GUI with the continue or exit buttons, somewhat like this:

I actually disagree, a warning saying Please see <link> for information on how to start the server is more than suitable.

[the-maldridge]

I've used several programs that if you invoke them the wrong way they close without warning, some have dialogue boxes and some do not. I think if we have a dialogue box, but not a functional terminal, that that would be sufficient to clue in new users that the program expects to be run in a particular way.

[gdude2002]

I think we might want to get some community feedback on this one - but here's my input.

• Silently failing = BAD
• Failing and telling the user they're an idiot = ALSO BAD

I like @gratimax's idea, but only if we can't get it to just open a terminal.

[m3rcuriel]

I agree with @gdude2002 in the sense that opening a terminal is ideal, but I really cannot find any documentation on how to do that outside of using the Console class, which is more or less along the lines of @gratimax's idea.

[dequis]

How did craftbukkit handle this? Pretty sure they had no GUI. And our installation procedure is pretty much the same are theirs, why is this suddenly an issue for us? I don't get it.

[gdude2002]

How did craftbukkit handle this? Pretty sure they had no GUI. And our installation procedure is pretty much the same are theirs, why is this suddenly an issue for us? I don't get it.

I was wondering that myself - that's why I believe there has to be something we can do.

Also, I think it just opened a terminal.

[turt2live]

A larger percentage of Glowstone users compared to CraftBukkit are reporting binding problems. Keep in mind that Glowstone is not just a CraftBukkit replacement, there are other projects that Glowstone is inadvertently collecting users from as well.

Not to mention that considering Glowstone is new to many people. The first thing most people do when downloading a file is to open it, and when it does nothing they then check the documentation.

As for what CraftBukkit did, it just did the same thing as Glowstone's current behaviour.

[jaredStef]

I feel that the server should generate the start file based on the users os, stop the server and then tell the user to run it from the "start.command" file. Even if bukkit doesn't do it we should try to do it better.

[turt2live]

I really don't think us going the extra mile is needed. @SpaceManiac's comments would be appreciated on this subject, although I personally think the two rational choices are to either give some kind of dialog linking to the installation help or to provide some kind of terminal UI. I personally would recommend the dialog containing a link to the help article.

Other functionality, such as creating install scripts and so forth are really just special case purposes and users may not want that functionality. They want their server to just work and they should, in my opinion, read the provided documentation if they attempt to start the server incorrectly (ie: no start file).

[SpaceManiac]

In my opinion the most reasonable option (greatest benefit for least work) is a simple dialog offering access to the installation article. The other stuff sounds kind of neat but wouldn't really be that useful.

[SpaceManiac]

So this was pretty simple to implement, considering: Thoughts?

[turt2live]

I like it. I didn't test the code provided in the ticket on Linux or Mac though, just as a heads up.

sent from mobile On Dec 1, 2014 8:35 PM, "Tad Hardesty" notifications@github.com wrote:

So this was pretty simple to implement, considering: [image: Dialog] https://camo.githubusercontent.com/5fbf7fbd9768cb6e3d9928155f3ed181ac5322b0/687474703a2f2f7075752e73682f64644238622f366664363732346138332e706e67 Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/GlowstoneMC/Glowstone/issues/581#issuecomment-65178827 .

[dequis]

Nice! Commit it to a branch or something so we can test it?

[SpaceManiac]

Up on https://github.com/GlowstoneMC/Glowstone/compare/console.

[gdude2002]

Maybe we should stick with this for now and implement an actual nice GUI later at some point? I mean, vanilla has one and I'm sure we could do better than that.