Monthly Archives: December 2018

A mess of bits splattered about


* Accessibility

I have just begun adding proper accessibility names and descriptions for things where I can. This will take time, but the excellent Windows Narrator built into Windows 10 is helping me identify the many places where I need to improve things.

The interface in GCA5 is pretty busy for screen readers. I’ll probably have to offer a stripped down version at some point.

* Miscellaneous

Added some code to let my controls display styled text if I want to update them to do so.

Added some additional error traps.

Restructured some code.

Repaired the code in Updater for integrating libraryupdates.xml into the new system that uses fileupdates.xml. The intent was that the old library update generator would still work for updating library specific book files, while the new general file update generator would allow for all files, including the library files if specified. At some point, the code for actually integrating the libraryupdates.xml information into the process was bypassed, but now it should be included correctly again.

Closing characters in the UI should trigger slightly less chaotic UI refresh behavior.

Characters should no longer be getting marked as Dirty every time they are loaded into GCA.

Having fixed the ‘Dirty’ issue mentioned above, I found that there was also an issue with how tabs were changing the ‘dirty’ or ‘clean’ image for the tab, so I changed how that is set.

Discovered a problem with where I was assigning certain event handlers for characters in the UI. Changed where they are assigned.

Changed some of the graphic elements for the third toolbar, to help clarify which ‘buttons’ are checkbox style, which are either-or radiobox style, and which are selected.

Changed the images used on the character tabs for ‘dirty’ and ‘clean’ characters.

Slightly improved some of the drawing code for trait boxes when drawing traits, group headers, and header information.

Added a character option for “No default level discount,” which effectively turns off the ability to improve skills from the default level, and requires every point spent to buy levels normally, ignoring any discount defaulting might have provided.

Added a button to Unified View which provides a horizontal override, similar to the existing vertical version. This mode limits boxes to the height of the display area, and turns off flow-wrapping of boxes in the worksapce. This allows for a horizontally scrolling workspace, and limits scrolling to within the lists themselves, rather than scrolling the entire workspace to move within long trait lists.

* Plugins

Recompiled for changes in interfaces and structures.

* Trait Viewports

Viewports are a new way of organizing traits for interaction and display. Basically, a Trait Viewport (Viewports for short) is a list of a particular type, such as Spells, that only includes those traits that meet specific criteria, such as all being Druidic. This new way of handling traits allows for much more freedom in what can be displayed and how the user can interact with it, over the previous way of being restricted to one list per type of trait.

In addition, with each Viewport being its own thing, it’s possible to match that up with particular display preferences based on the Viewport, so users can customize how they view different Viewports without it affecting other data of the same type.

GCA still organizes all traits internally by trait type (spell, skill, advantage, etc.), but each character will also track and manage all the viewports that are defined for it, so that they can be carried along whereever the character goes. Importantly, the Viewports are only saved in the character by definition, which is the criteria used to create it; the traits are not saved in the character file with that information actually applied to trait or list data, so you will not be able to just read the XML file to get a list of a Viewport’s traits; the Viewport will have to be created and filled somehow (which GCA does automatically while managing the character).

The display information for each Viewport, however, is user specific, and is not saved with the character at all. Different users or different computers or whatever may call for different display options, so those Viewport display options are maintained with the other user settings for your GCA installation. GCA has default settings for each type of trait, so loading a character with a Viewport that you’ve never specified settings for will result in the default settings for that type being applied.

I have created new trait boxes for Unified View, based on Trait Viewports. These new boxes embrace the whole new Viewport structure, including display options. Because of the changes, I’ve also changed how ordering is indicated in the column headers for the lists. Although the three standard color options (grey, red, yellow) are still provided, since they’re drawn into the header area using transparency, you may find the results often aren’t quite what you’d expect. The default ‘gray’ option tends to look best.

Trait Viewport Usage Notes

When building a Display Template for a Viewport:

You can format the TAG column of a Column two ways, if TagIsFormatted is True. If TagIsFormatted is False, then only the Tag name may be specified and only that value retrieved.

1) You can support String.Format() style substitution by including {X} markers where X is 0 through whatever.
Then include a comma separated list of values that will be inserted into the {X} markers. This list is counted from base 0, so the first item goes into {0}, second in {1}, etc.
This allows you to format the Tag field with whatever values you like, so long as the following list of values are valid Tags.
For example, you could use “{0} lbs, weight” for the Weight column of Equipment, where the value of the Tag ‘weight’ is inserted for {0}.

2) You can specify a numeric format for tag values that are themselves numeric values. If you do this for a non-numeric value, results will be unexpected.
You do this by including the keyword #format followed by the numeric format to use, best enclosed in quotes or braces (required if the format includes a comma).
The format uses the .Net Numeric Format strings, so there’s online docs for that out there.
For example, our Weight column could use “{0} lbs, weight #format {#,0.00}” to build on our example above, which formats the weight value to use commas to separate thousands, and always include two decimal places.

You can use the tag numeric formatting without the substitution, such as “weight #format {#,0.00}” to just show the weight without including the ” lbs” from our example.

Only one Tag can be specified, unless you use the substitution method.

Viewport Development Note

Right now, it looks like Viewports are too much for me to get done, UI wise, for other parts of GCA. So, I’ll probably not be rolling them out to Classic or anywhere else for initial release. However, they’re supported internally.

For this build, and maybe the future (we’ll see), they’re the way the Unified view displays traits. Since the default Viewports are the same as the standard way of doing things, that shouldn’t change anything for you. However, the tools for changing the display outputs, and the viewports themselves, are basically half-baked. They usually work for the first change you make, but then don’t, for some reason. If I can fix that, maybe I’ll keep Viewports here for now. Otherwise, I’ll roll them back in Unified as well.

However, regardless of how that works out, Viewports can still be used programmatically for output sheets if authors want to use them.

Looking back at 2018

This year was basically a failure. I got very little of what I wanted to get done, actually done.

Every time I thought I was getting back to work on GCA, life kicked sand in my face. Work has been stalled for months, and the multiple times I dove back in to get back to it, I was quickly pulled right back out again.

I’m sorry about that, I really am. I did not foresee this kind of downtime.

I’m really hoping I can turn this around next year.

My current plan, once I get some traction again, is to roll back the UI stuff for the last big thing I was doing. I think it’s cool, but it’s not required, and the UI takes a lot of work to make it properly useful for people. The internal stuff is there, and appears to work, so I’ll leave that there for the future; maybe sheets can make use of it as an option for organizing certain outputs.

Anyway, once that’s rolled back, I’ll return to my previous plan: finish, fix, and polish; get everything that is already there ready for public consumption. Then we’ll see what we might do about a larger scale beta to shake things down properly.