The road to 1.4.0 (and a bit beyond)

[Jagged]

For JavaFX there is
e(fx)clipse

Is there a plan for migrating to JavaFX? Are we going to try and rip out Abeille and Swing or replace bits piecemeal? I understand there is a JavaFX Wing Panel so you can drop JavaFX elements into existing Swing screens (which sounds horrid )

[JamzTheMan]

No official plan as of yet that I've seen. I know Username has done some POC.

I've been monitoring support for high density displays and would like to make sure that gets included. MapTool text/menu/items are extremely small on my Surface Pro 3

Other than that, I believe we can do it piecemeal if needed to avoid a overwork overload.

[Jagged]

Been reading up on mixing/migrating swing to javaFX and found this article

[JamzTheMan]

Maybe we dedicate one release to updating the UI? Like 1.5? And do we start with a "lets convert everything from swing to JavaFX first, keep same UI" or do you tackle JavaFX while also updating how the UI looks?

Edit, and I was "ok" with some mismatches with the UI, but the threading and freezing issue seems like a good point not to do it.

[RPTroll]

I think the one dedicated release has a lot of merit. Just go hammer and tongs to get all the windows transferred over as is then improve in later releases.

[Jagged]

I think the one dedicated release has a lot of merit. Just go hammer and tongs to get all the windows transferred over as is then improve in later releases.

Agreed. Plus from I think from Craig's comments it might be worth waiting until we are running Java 8.

[JamzTheMan]

Definetly. We should lump Java 1.8 with UI change (or before).

I also was looking at different gradle plugins for one jar solutions (like Capsule), some look for JRE's better, some allow for maven downloads of dependencies for smaller downloads, some allow updates to your code via launch, some package JRE's.

Any thoughts on this? Would it be better to package a JRE even with a larger download size (do we even care if something is 100mb now a days?) or we can create one with JRE and one without.

[RPTroll]

I think packaging the JRE (maybe check first?) would be a good way to avoid issues around Java versions. It's the way most commercial apps are going in order to limit their testing needs and simplify support.

[JamzTheMan]

Yep. I created a single jar for token tool and it works great. And I like Mote's all in one package.

And i have to fix my friends install every time they get a new java update. Explaining how to not install java 1.8 or how to specify the path to jvm's just goes over their heads. I can only imagine how many new users give up on MT because of this. Most people don't bother with forums. In our group only 1/8 visit here...

[RPTroll]

I just had this issue with a guy on facebook. He didn't have java installed and thought MapTool was bad because it wouldn't run. So as a support guy, I'm all in favor of things that makes it easier on the users.

[smaudet2]

I was on here a couple years ago...

Life intervened and we never got anything done. I think my GM still wants to run our campaign on roll20, but I want to try GMing, and I hate r20's guts. So, back to RPTools for me!

Re the install thing...there are things like installers and such, I've even written a few with innosetup installers (not hard), you can bundle/download java with them and make sure you don't have weird issues.

Most programs on windows which require java work like this now, they bundle Java with their windows/mac installers (even on linux sometimes), they might try to detect java before installing their own, or they just go ahead and drop a java installation straight into their install directory.

From the web perspective there's a whole raft of corresponding changes for detecting user platform/providing simple options and an 'advanced' section which contains the JRE-free versions for savy users... and yes, yes you are punishing users, but hey, if users are stupid, they kinda deserve what they're getting.

[Mrugnak]

Any thoughts on this? Would it be better to package a JRE even with a larger download size (do we even care if something is 100mb now a days?) or we can create one with JRE and one without.

I'd like one without as an option, even if I have to build it to get it (but since I have only ever used gradle with minecraft I might need to ask questions before I get my build environment working).

We do care if something is 100mb these days. Not everyone has high speed, not everyone has an unmetered internet connection, and not everyone has an internet connection that is reliable. I happen to have a "high speed" connection that is metered and unreliable but I'm sitting here in the nations capital, in a lovely suburban development. Maptools is particularly useful for players who are spread out - which means rural or otherwise isolated players.

[JamzTheMan]

FYI: It can be ran without the packaged JRE. Gradle still builds the JAR normally first, in this case it's now a single JAR for MapTool and a second single JAR for Launcher. The JRE adds about 40-50mb to the size which about doubles it (around 40ish MB without the JAR). So it's not like MapTool is a small 5mb download without the JRE...

The plan is to release the JARs as is along with the packaged solution for size and for those who are familiar with Java and want to use their installed version (popular for Linux). (You can also copy the JAR after the install as well and move/use it as you wish).

So ya, it's like Burger King, have it your way.