Help!

[impishfae]

Status: Included in version 1.4.0

No really.

If and when I get my Java environment back up and running, would you be interested in a context-help module for the tool? Particularly for the configuration area, being able to hit f1 and bring up some details on what an option does rather than slorping through the wiki would be quite helpful, I think.

[Lokorin]

Certainly. The configuration is vast and the names rarely convey the entire meaning, so a help feature would be nice. I will upload the latest source when I get home so that you have a current version to work with. There is currently no public CVS server available, so I'm afraid that it will be manual version control until I get a server sorted in a week or two.

Just to give a brief understanding of how the configuration work:
The configuration values are defined by the "Value" enumeration in the Configuration class. Currently every value has a configuration path (used to structure the XML configuration file) and a default value assigned to it. The name shown in the configuration dialog are set in the ConfigurationDialog class.

A question might be if one would rather have the name set in the Configuration class along with some help information so that a help could be generated from that. Another possibility would be to create a separate enumeration in ConfigurationDialog which contains the name and help information. Or possibly the help infromation shouldn't be hardcoded into the code but rather available as a separate XML-file or something.

[Lokorin]

Here is the latest working snapshot of the source code.

I'm currently rewriting the reward interval and event presentations in the Server class (I forgot that they should be using functions such as addRaidBatch() in order to not become to closely coupled with specific server software, but your suggestion reminded me). When I'm done with that I'm going to work on either "Add an exact join/leave mode." or " Allow switching between multiple local configurations (including the member aliases)." from the to do list.

[impishfae]

Did something change in swt between the previously published source and this dev snapshot?

I had to use the previous swt dll and previous swt jar file to make the project run, though the version numbers reported in the swt jar files hadn't changed (filesize was different though).

Strange things are afoot at the Circle K!

[Lokorin]

I have indeed recently messed around with SWT, I will try to fix it later tonight.

*edit*

Meh, so little free time these days. I will have to look at it tomorrow instead.

[Lokorin]

I have taken a look and I can't seem to find any swt errors in the linux distro, I might have the library files somewhere else in my library path though, which could mean that I'm distributing old ones but developing with new ones. Another problem is that I don't have access to a windows system to test if I just messed up that distribution.

The problem will hopefully be caugth in testing, so I'm going to wait for that opportunity to test fixes.

[impishfae]

No sweat at the moment: I have my environment up and running with the original libraries from the binary distro, so it's all good.

My aim, on this first pass, is to just slurp in all the stuff from the wiki without change and bundle it onto a menu item. No context-sensitivity at this stage.

Have you got a feel for when 1.4 might be ready for testing, so I know how what my deadline is for getting the files to you by is?

[Lokorin]

There will probably be a couple of stages of testing, so there is no rush. You should at least have two or three weeks on you before there's a freeze on new functionality. There's no hard schedule at the moment, but what I have in mind is to launch an alpha to test new functionality as soon as the to do list is empty (bar the GUI changes) and obvious bugs have been fixed.

During that time I plan to work on implementing your suggestions for the GUI and fix any bugs found during testing. Once the alpha is over and all functionality is done a freeze will be put on new functionality (I would say this is two to three weeks away) and a beta will shortly follow. From there on it will mostly be bug-fixing until the version is ready for release (during this time I will work on that and on the web page).

[impishfae]

First proof-of-concept cut attached. All this does is add a new menu item to the 'help' menu which pops up the Help Index file.

Changed file: com.lokorin.dkplp.gui.GUI.java
Contains reference to HelpManager and a new menu item added in createContents to pop up the help.

Added file: com.lokorin.dkplp.gui.HelpManager.java
At the moment it just finds the index of the help set and displays it on command. (This will eventually handle all the context-sensitive stuff. I envisage this becoming the SWT equivalent of javax.help.CSH which operates on AWT)

Added library file: dkphlp.jar. Jar containing all the helpset information.
Added library file: jhall.jar Jar file containing distributable javax.help binaries to run the help system.

I've also included the source packaging for what's inside dkphlp.jar. I've been using JHelpBuilder to build it (project file included). The help files as they currently stand are basically empty. I threw a few bits and pieces in there just to check that the HelpViewer would operate correctly.

Next stage: updated dkphlp.jar file with actual content in the help files!

[Lokorin]

Nice, my only question is whether the end product is safe to include in a GPLed program considering their license. If the program is just used to generate the help files which are then displayed with sun's JavaHelp API then I guess it's fine though.

[impishfae]

Yep, it's just a jar builder and help system configurator. (It does come with a helpviewer of its own, but we aren't using it so there's no distributing of its software at all)

It's like using a commercial IDE to build software. The software itself can be licensed and distributed however you want, so long as you don't ship the IDE with it. Same deal...

[Lokorin]

And back to the SWT problem: It appears that linux and wIndows use different jars for SWT. I thought it was the same, hence the linux one was packed into the source dist. The binary distribution uses two different jars though, depending on OS, so it should be fine.

For now I will put up a note about it. I'm not really sure how it should be changed though, the best way that I can think of at the moment is to include neither and instead have instructions on how to download them.

[impishfae]

Couple of options strike me as possible. Either provide two different downloads - one for linux, one for windows. Or provide three downloads: one for core java for everyone, then swt linux and swt windows.

I'd personally recommend the first: people are less likely to mess up the installation putting jar files in the wrong place, etc, if you bundle everything where it's meant to be from the get-go. And that means less "I have a problem, my distribution doesn't work" error reports for you.

[Lokorin]

Aye, multiple source dists sounds like a good plan. I'm wondering how that would translate to CVS/SVN though, I guess I should split up the library jars there too so that people can just include directory x and y into the build path and have everything run. I'm not too fond of forcing people to check out unnecessary jar files, but I guess downloading an extra megabyte or two isn't a big deal these days.

[impishfae]

I suppose if they're concerned about dowloading an extra Mb or two, you could always just include the library files in a separate tree per operating system, and they can only checkout the jar/dll files they care about.