Completely eliminating the “Welcome Screen” not-actually-the-main-screen step
Boot up with “Blank Main Screen” PLUS game’s About graphics and simple buttons for Start New Game, Load Game, and maybe Online (something analogous to my earlier mockup, but maybe not list every predefined setup, put that into wizard flow)
“Start New Game” button (or any New Game / Predefined Setup choice) jumps straight into that “wizard flow” at appropriate point.
“Load Game” button (or from File Menu) picks a game to load and jumps straight into that flow.
“Play Online” button opens the Server Controls (so not requiring ONLY the weird toolbar button to find)
So then the wizard flow becomes much simpler and relegated to after player has picked New / Load / Online.
Like look how much simpler this flow just “looks”. And almost certainly easier to implement & maintain.
This is just one of several possible approaches, but I just wanted to illustrate how a huge amount of extra nodes & steps & complexity could all be eliminated and actually keep a very good (probably better actually) “new user experience”.
[attachment=0]Vassal Wizard NEW Flow.jpg[/attachment]
So, what exactly is the problem with the current wizard? I used it for another project and I didn’t find it that bad once I understood how it works (which was not easy). I looked around for something comparable, but couldn’t find anything. The actual page content of each page of the wizard, what buttons , fields are on it, the look and layout, is completely under our control.That’s our problem, not the library.
The is another version of the library I found that had some later work done and fixes some of the bugs in the ancient version. I also had to add a few missing Constructors to make it do what I wanted to do.
I think the wizard is important for absolutely new players, but if we want to design a new flow, I am happy to work on implementing that. I’ll see if I can drag out the updated library source as well.
It’s an obscure library which unlike regular libraries has only a single version in the maven repositories, has not been maintained and will never again be maintained, and part of it sits in our codebase under org.netbeans making US the maintainers.
And the fact that it will never again be maintained means it will never be adjusted to the jigsaw project (java module system) and there will come a time when the compiler will not accept such libraries anymore, at least not without walking on additional crutches.
… just spent a couple hours implementing a kind of wizard panel inside the PlayerWindow.
There were some real hardcore specialists at work there, highly professional Java, Swing and OOP developers/maintainers.
PlayerWindow.controlPanel is exposed to the GameModule (which in itself is global, glorious idea there). And from there on the controlPanel gets passed around like … I better don’t use the appropriate expression.
public static VASSAL.tools.ComponentSplitter#splitAncestorOf, really??! A public static method? That comes from the side and messes with the PlayerWindow’s internals, changing internal components just like that?
I think we have to start from lesson one. OOP is not just “hey I have a C-struct and I can put some code there that is roughly related to the contents of the struct”. Writing code like this is object-BASED programming and has nothing to do with object-ORIENTED programming.
Why do I keep hearing Linus in the distance, and his famous citation from a time before he got sick with the “political correctness” and “code of conduct” disease…
Glorious future awaits Vassal NG in C++. Glorious.
Brian, love your idea with this new user experience.
Here is what I got so far:
[attachment=0]playerwizard-alpha.png[/attachment]
Yes, this is JavaFX worming its way into the swing application. Look at the clean design, the View is in xml, the Controller is a Java class, the style can be set in CSS later on.
We don’t need a special wizard library for 1-2 dialogs with 3 buttons each. We just need a good UI toolkit which enforces clean design.
I wouldn’t know JavaFX from a hole in the ground so I certainly have nothing to say about that but I’m very interested in forward progress on a new wizard flow!
I will admit I just like to prototype things and try them out. Busy tonight trying to put a search function in the editor.
Again, that is because Rodney chose to use the Wizard classes that way, not anything that is imposed by Wizard, or could easily be changed by us without too much effort.
I’m afraid I don’t understand why this is a problem. We take the source inside Vassal and maintain it ourselves. There is in fact an update to this package, but no one has the access to update the original anymore, so it live in a different place. No big deal, it is not a very complex library, it is stable, and that would resolve any module issues. We can move it to a different package if necessary.
I’m not saying don’t replace it, knock yourself out if you have nothing better to do, but the two reasons given so far are
a) The way Vassal has used the library is ugly and not well thought out (which we can easily fix)
b) No-one is maintaining the code, and it may stop working if it remains external to Vassal (which we can easily fix).
Neither seems a particularly good reason to re-write the functionality from scratch.
Sorry. Hours spent on untangling spaghetti instead of doing useful things makes me an angry Yan
About the wizard lib, yes from a technical point of view we can maintain it ourselves. I was looking at this from a project management perspective, we hardly have the resources, or better, we do not have enough resources to maintain Vassal itself. The PR queue is getting bigger every day and not smaller, and there is still more to do in Vassal than we can ever manage if things stay the way they are. Almost anything we touch uncovers some hidden and previously unknown problem that also needs to be solved, just yesterday we came upon some very dubious network/socket code that needs to be cleaned up… half the world’s enterprise backends run on Java sockets, Twitter’s backend runs on Java sockets, Netflix runs on Java sockets, Minecraft servers/clients run on them, but Vassal devs are smarter than everyone else and feel that Java sockets are not reliable enough…
And we see how good the maintenance of half the wizard library and the beanshell library has worked in the past - it has not worked at all, the code of these two libraries was added once and not maintained anymore.
And, from the technical perspective, 3 panels with an embedded image and 3-5 buttons per panel do not need any library, it’s easier to do that manually. Wizard library makes sense for applications like MS Office where there are many different wizards and they need to look consistent.
I was looking at this from a project management
perspective, we hardly have the resources, or better, we do not have
enough resources to maintain Vassal itself.
This is why we need to bulid something which doesn’t consume so many
resources just for fixing problems…
The way forward is to get to a point where we draw a line under the
current code base, rather than dumping more effort into a bottomless
pit.
just yesterday we came upon some very
dubious network/socket code that needs to be cleaned up… half the
world’s enterprise backends run on Java sockets, Twitter’s backend runs
on Java sockets, Netflix runs on Java sockets, Minecraft servers/clients
run on them, but Vassal devs are smarter than everyone else and feel
that Java sockets are not reliable enough…
We don’t know that code needs to be cleaned up. It migth be correct
as written—beacause as I said, Java’s sockets implementation is weird.
I’ve written a lot of sockets code before. Java makes it awkward to manage
normal occurances with sockets. I stand behind that.
And we see how good the maintenance of half the wizard library and the
beanshell library has worked in the past - it has not worked at all, the
code of these two libraries was added once and not maintained anymore.
This is one of the reasons I’d like to be rid of the wizard library, yes.
(And also why I would like to explore if we can update BeanShell and
have only our modifications as part of our codebase.)
And, from the technical perspective, 3 panels with an embedded image and
3-5 buttons per panel do not need any library, it’s easier to do that
manually. Wizard library makes sense for applications like MS Office
where there are many different wizards and they need to look consistent.
Should be possible, usually the Generation gap pattern (en.wikipedia.org/wiki/Generation_gap_(pattern) us used for that, the library would be the “generated code” and our modification would be subclasses of it.
You can try, but I had to modify the grammar and re-generate the Parser using JavaCC/JJTree to add support for the Regular Expression operators. This generates quite a few of the source files.
Apart from that, I seem to remember it was just some changes to the implementation of the + operator to handle Vassals numbers as strings. Plus adding the Regular Expression handling.
beanshell 2 has reached end of life with the 2.0b6 update. Work is underway on Beanshell 3.0 which seems like a bit of a rabbit hole, they are chasing along behind the Java releases trying to implement everything that Java is implementing. I think they are up to about Java 11 so far.
Here’s an interim compromise.
I am happy to work on updating our beanshell implementation from 2.0b4 to 2.0b6, keeping the structure the same and implementing the same Vassal changes. I know where the bodies are buried. That should be relatively straight-forward and cause a minimum of disruption (even though the Beanshell 2.0b6 repository refuses to build out of the box atm). There appear to have been some performance optimisations applied as well which will help us. That will give us the latest current Beanshell implentation with minimum work.
When Beanshell 3.0 is released, you can review the situation and look at changing the structure of the implentation.
I ran a quick diff between our internal beanshell code and the 2.0b4 sources, it shows that 17 files are different and a bit over 90 files are the same.
Is it not possible to subclass the 17 files/classes that we want to change and just reference the other 90 classes from the beanshell jar?
I don’t see how subclassing those classes will help as we don’t call them, they are all internal (except 1) to Beanshell, our code doesn’t go anywhere near them.
We could do what the WizardSupport code does and duplicate them in a duplicate package structure inside our source tree so that the ClassLoader finds our copies before the jar copies? But doesn’t this raise Access issues to protected class members as the 2 sets of codes are in different Jars?
Classloader doesn’t care about different Jars, all packages/classes from all Jars are put into the same “namespace” before the classloader begins it’s work, and only the order matters. And the application is first in that order so the classes in it are found first, before the classes in the library Jars are found.
Yes, that is what I thought, you had me confused talking about subclassing.
Since the 2.0b6 beanshell library in the maven repository is out of date and the only recommended version to use (according to the github Beanshell page) is a manual build of the github repository, which is also version 2.0b6, then I’m not sure we are going to gain anything out of this. We would have to manually build our own Beanshell library to distribute, just so we can add replacement classes of it in our Vassal code.
How about as a stage 1, I update out current beanshell 2.0b4 implementation to 2.0b6 without any structure changes and check that it will actually work. We can the look at restructuring as a stage 2.
By the way, the 2.0b4 you found is not the 2.0b4 I used, the Beanshell people seem to like keeping the version number the same and just pumping in more and more changes! I only update 2 classes, plus the parser grammar change, which results in 8 more updated classes.
My recent reading about Modules indicated that the Java VM will place classes loaded from different jar files in different modules and generate IllegalAccessErrors if you try and access protected methods from one in the other, even if the packages have the same name. Of course, I can no longer find the discussions about this issue.
Yea because why the hell not, why use version numbers at all, just build new releases of a product and use your dog’s name as the version number for all of them… That’s some specialists at work there.
To be honest I haven’t fully understood this whole jigsaw/modules system yet, yes it adds way more restrictions for even more encapsulation, but only works in full when all the dependencies are java-modules-enabled, while older dependencies somehow keep playing outside of this new-and-stricter playing field. Vassal is not modules-enabled right now, most of its dependencies are in the old module-less format, and I think we don’t have to worry about these java-modules intricacies yet. Question is for how long.
