Thanks, I was setting up some help the other day and the manual said it will open in browser and I thought to myself I am sure I have seen it open in a window before…
I actually prefer it to open in a dedicated window (as i want to present the rules in a narrow scrolling format so that they can be open without overly obscuring game).
Help html opens in a new window that does not belong to the system browser, possibly a html rendering Java Swing element
This is done for the Help files in the Player because the source files reside inside the module zip archive and can not easily be displayed in an external browser. The Help Window is just a JFrame or JDialog with a HyperLinkListener and uses Swing components’ inbuilt HTML support. Very basic, but does the job fine.
In the Module Editor, there is some inconsistency, most Help files are displayed in the external browser, but the individual trait Help pages are displaying in the same internal window used by the Editor. The reference manual files are installed in the Vassal install directory so are available to an external browser.
Personally, I quite like the internal browser window style as well. Low overhead.
The minimum that needs to be done is that the Module Editor is made consistent and the trait help pages are opened in the same place as the other Module editor help pages.
Possibly we need a Global Preference ‘Display Module Editor Help pages in external browser?’, but it is probably not really required as long as the Module Editor is consistent.
Come on don’t roll your own html renderer or bring this not-maintained-anymore Swing html renderer in 2020
Either use the system browser where the user can decide for himself whether to open links in a new window or a tab, or bring a proper rendering engine with out-of-the-box hardware acceleration, something like WebKit.
I’d just use the system browser, a neat side-effect of this is the fewer JFrames and JPanels and JWhatevers are used the easier it’s going to be to move away from Swing some day.
Using the system browser is fine for the Module Editor and we should extend it’s use right across the Editor, I don’t see this working for module based html help files unless you extract them from the module and store them somewhere outside the module.
While you could theoretically use data uris to serve up the pages (with inline data uris to include the images) to a browser, how do you support the hyperlinks?
The help files in html format that come with Vassal, those are the ones I meant, they should display in a consistent way.
Did not even know that the modules can bring their own html files, this sounds like a whole other problem. You are probably right and it’s best to just display them inside Vassal, instead of extracting them then having to clean up etc.
While you could theoretically use data uris to serve up the pages (with
inline data uris to include the images) to a browser, how do you support
the hyperlinks?
Hmm. That’s a good point—internal hyperlinks wouldn’t work with data
URLs.
Can browsers understand archive URLs? If not, maybe we should export
such files to our temp directory, so browsers can get them via file://
URLs?
Firefox can render pdf’s out of the box, does anyone have experience with other browsers? Worst case, the browser will offer to open the pdf with the default application, or to download it.
Oh now I see what you’re suggesting - the embedded webserver would serve up the html (and pdfs and whatever) to the default browser and/or application.
