RPTools "next" Git Repository

[JML]

Always interested in the progresses you make.

Regarding button mapping I would try to keep it consistent regarding the actions mapped rather than the object manipulated. But that's just my two cents.

Glad to see you're still working on it. Thanks.

[username]

So, you can save your drawings now and vision is enabled. As stated, everything is rather rough around the edges. Some points that keep me from releasing this as a (pre-)alpha of "whatever" (1.4, 2.0, prototype,...)
* findbugs has only recently been upgraded to Java 8 and requires maven 3, which I wasn't abled to install on my machine, so I have findbugs only as eclipse-plugin (which works, oddly enough). So I can't vouch for the POM working out-of-the-box. This has got to be fixed by someone knowledgeable in these matters and it's not going to be me until I get a new machine, which will probably be around X-mas.
* Some class decorator (ASM) has broken and I haven't found the reason for it. Again, this is just a testing issue, but it makes the process bumpy. I want it to be cleaner.
* Documentation for those that are courageous enough to brave this is not sufficient. I could probably put some small stuff on Github. But it has to be done; you probably wouldn't find your way around without it.
* Craig has recently resurfaced and I always made it clear that I wanted to participate, not lead. So if Craig finds more time, I'd rather wait before announcing something on the wrong track.

Reminder: The github address is in the first post of this thread.

[JML]

Thanks for the news. And I'm also glad you might not be alone any more

[badsequel]

Thank you for your efforts, username!

[username]

Just as a sign of life: work has continued and a lot of things already work. You may consider this now the first pre-alpha version ready to be tested (as far as the reduced feature set is concerned). It is still build-it-youself, but I think it has the basic ingredients JML mentions.

[username]

Yet another update, this is not forgotten. Is there a place to upload test versions here or would I need to get my own space? It would be nice to have some feedback before totally going into the wrong direction. In particular, I don't know how this all fits into the 1.4 discussion.

[RPTroll]

Check out the new MapTool 1.4 thread for info on forking and merging. I also need to get a handle on what you've done to date so I can add it to the functionality list.

[username]

I am reviving this thread because I would like to hear whether we have ongoing prototype activity and whether they are worth expanding. I haven't continued on JFX and since 3 years the subject had remained stale as far as I can tell. Instead I have recently started prototyping with the same "core" that I used for JFX and separated server and client and made the client a web client. That has several advantages:
- JFX is going to be separated from the JDK, I don't know what this means for the JRE and packaging
- JFX is only slightly less tightly coupled to the server than Swing. A Web GUI would radically seperate them
- customizations are significantly easier than in JFX and the documentation is better. The compatibility situation is better.

There are disavantages, obviously:
- Web GUIs are still "obscure" programming, regardless of frameworks; and a new language to boot.
- Interest in this may even be less than for the JFX prototype above. (That *is* possible.)

Is there any interest in refactoring 1.4 in the above sense or do some general overhaul (e.g. making features more accessible instead of adding more features)?

[Azhrei]

I am reviving this thread because I would like to hear whether we have ongoing prototype activity and whether they are worth expanding.

Yes, JavaFX (or just "JFX") is splitting off. In fact, it has already done so. The use of Java 9 "modules" functionality is going to allow applications that want to package a JRE as part of their install process (which will include the RPTools, at some point) to pick and choose which modules they want included. Those modules and their dependencies will then be built into a "custom" JRE install that the application developer can ship with their application.

Is there any interest in refactoring 1.4 in the above sense or do some general overhaul (e.g. making features more accessible instead of adding more features)?

Jamz has retooled TokenTool to use JavaFX. If you're interested, we have a TokenTool 2.0 on our GitHub repo, and he's on 2.1 now, IIRC, on his GitHub fork. I hope to get some build and deployment issues resolved for MT first, then I'll get his patches merged. But he's been heading up the JFX stuff so far.

Changing MT to use JFX is going to be a long road as there are many issues to resolve. I'll list some of them, but be aware this list is not complete: the rendering engine in JFX is different, panel layout is defined differently, Swing does or does not play well inside a JFX container depending on who you talk to, and our current docking library (JIDE) doesn't support JFX. None of the problems we've found so far are insurmountable given sufficient time, but there's a lot of foundational stuff yet to be done.