An end of year update on where version 2.6.5 is up to

This is my final update of the year.  I hope you all have a bountiful Xmas and eat so much that your relatives have to call the fire department to extract you from your chair in front of the T.V.  Just kidding that would be awful, but I hope you all have a great Xmas and a Happy New Year.

Now onto the point of this post.  My last post, back at the start of November suggested that Santa may be bringing the 2.6.5 update in his bag of goodies.  Alas Santa got waylaid by some disgruntled Elves wielding sharpened candy canes and demanding better pay and conditions and thus won’t be able to make the delivery as planned.

Development of 2.6.5 hasn’t stopped, far from it, I just realized that I needed to create an editor to provide support for those creating the set of User Interface strings for a new language.

My original plan was to give the creators a .xlsx (Office Spreadsheet) file with a couple of columns and an extra column for them to fill in with the new translated string.  But this is about as user friendly as the ill-fated iPotato that Apple originally planned to release before the vastly superior iPhone made its debut.  A glorified text file, which is what a .xlxs file is, is also woefully error-prone, so instead I decided to actually create a strings Editor that a user can use to create their translated strings.  A picture of what it currently looks like can be seen below:

There are numerous advantages of this Editor over a .xlsx file, not least the fact that it has built-in support for tab completion of referenced ids.  Let me explain.  To facilitate re-use I’ve allowed for the use of previously defined variables in a string.

So I might have a string with an id (the value I actually use in the code to reference a translated string):

objectnames.singular.project = Project

In other words, in the QW code I use “objectnames.singular.project” to reference the value “Project”.  When the value of “objectnames.singular.project” changes to, say, “Potato” everywhere that “objectnames.singular.project” is used in other strings it will also magically change to Potato.

So, I might have another string with id:

project.new.title = Create a new ${objectnames.singular.project}

The ${…} construct just allows me to find the values in the string.  This value will come out as: “Create a new Project”.  If I change the value of “objectnames.singular.project” to “Potato”, the value will be “Create a new Potato”.

This kind of reuse makes sure that consistent terms are used throughout the interface.

To return to my previous point, the Editor supports the ability to provide suggestions for partially entered ids, if it detects:

${objectn

then it will offer “objectnames” as a potential value in a popup, the user then presses the “Tab” key to accept the value.  Press “Tab” again and all the “child” values under “objectnames” will be displayed.

For example objectnames has two “children” (things after the dot), “singular” and “plural”.

This set of dot separated values allow for reuse of terms and allows for grouping of functionality.  So a prefix of “project” means “things to do with a project”, “warmups” is for the “Warm-ups” and so on.

The Editor’s other main purpose is to allow easy submission of the strings back to the server where they are stored.  It also provides verification and error checking so by the time the strings reach the server they need little to no extra processing (although the server does do its own error checking).

Unfortunately, all this extra work has taken time however the infrastructure to make it all work is now essentially in place.  The main thing remaining is a way to handle updates for future QW versions.  That is I need to make the new or modified strings for a new version available to translation creators BEFORE the new version of QW is available to everyone else.  A tricky problem but not insurmountable.

All of this, of course, has put my estimate back somewhat.  The work is worth it, if a little tedious at times.  At the moment, I think a realistic estimate of when 2.6.5 will be ready for release is sometime in late February 2018.

Happy Xmas and a healthy New Year to all!

Advertisements

An update on version 2.6.5 (was 2.6.3) and some news on version 3

So many version numbers!  Anyway, what was once 2.6.3 is now version 2.6.5 because I released a bug fix to solve an issue with the legacy asset types, that became version 2.6.4.

But let’s move on, the focus of version 2.6.5 is to allow different languages to be used for the user interface.  So you might have a German or Greek translation of the text you see on screen.  This post is an update on how that is progressing.  In short, it’s going slowly.  There are a number of issues at play.  The first is that it’s mind-numbing work, I literally have to be doing else at the same time or I go bonkers.  Finding a text string in the code then determining where to put it in the strings file takes time and I have to ensure that I’m following the rules that I’ve set up in the strings file.  For example, all the strings used for defining menu items in a popup menu (what you see when you right click on something) are in the following structure:

“popupmenu”: {

“items” : {

… items go here

}

}

I have to ensure that whenever a popup menu is defined I use the same structure and, where possible, the same names for items that perform the same or similar actions.  If a menu item creates something then it should be called “new” in all places.  This is designed to build a vocabulary that those who will be creating the translation will be able to learn and grow accustomed to, when they see “new” they know that it means “create something”.

Another issue is that I have to make sure that a string is actually used, over the years a certain amount of cruft has built up in the code and some things, upon investigation, aren’t actually in use anymore or are duplicating code from elsewhere.  This is a tedious detective work process, think Columbo and his “just one more thing”, it sucks up time and energy.  Admittedly, it makes the code more streamlined and easier to work with but it is a grind.

A further issue is that I have to keep the person creating the translation in mind.  The identifiers I use need to be semantic, as much as can be possible, so that meaning can be derived from the label itself.

Thus a translation creator will see a text string label like:

allprojects.headercontrols.items.add.tooltip | Click to create a new ${objectnames.singular.project}

Hopefully they will be able to glean that this relates to the “All projects window header controls buttons and is the tooltip the user sees when they mouse over the Add project” button(hey, I can dream).  The ${…} construct allows me to refer to other terms previously defined within the file, thus the name for a single project is defined by: objectnames.singular.project, similarly the plural is defined by objectnames.plural.project.  That way, if you change the value in “objectnames.singular.project” then you don’t have to change the tooltip value.

A while back I created a file of the files that I need to check, basically all files that contain a string that “might” be used within the user interface.  Originally that file had around 400 file names, as of writing it has 106 left, that is I have 106 files left to check/change.  However a number of these files are pretty big and core to the user interface and each one can take a number of hours to go through.  For example, over the weekend I tackled the Projects window (the allprojects from above), just one file took nearly two days.  You can see the changes here.  You need to expand the “Landing.java” file to see it all, lines in green are the ones I added, red is stuff removed.  Apparently I’ve changed 159 files since I started, you can see the full list of changes here.

All of this pseudo whining is leading up to me saying, I’ve still got a while to go and don’t know when 2.6.5 will be released.

Version 3

Onto version 3 news.  It looks like it’s going ahead!  For a long time now I’ve been trying to get away from using Java Swing and move to a new UI technology called JavaFX.  Swing is basically dead and no new development has been done on it in years.  However the thing stopping me ditching Swing is the need of a good, high performance text component in JavaFX.  There is now such a component available, called RichTextFX and I’ve been looking into it for a while.  It has excellent performance (much better than Swing) and doesn’t have some of the irritating rendering bugs that Swing has.  However, it’s not a panacea and I need to add a couple of features to give it full parity with Swing.  When I get truly bored with the UI string changes I’ve been working to add these features.  Once that is finished I can get started on moving QW over to JavaFX and start reaping the benefits, such as:

• A native Mac and Linux version
• Full skinning, including user provided skinning using CSS, this also allows the use of multiple themes that can be time triggered, a common request I get is to have a dark theme for night time use, JavaFX lets me easily do that
• Potential for a mobile version
• More complex and interesting components and full web support
• Simpler code, simpler build process
• Animations and transitions, for example I will be able to have popups and sidebars slide in and out rather than just “appearing”

A few months ago I actually moved the Projects window (Landing.java from above) to use JavaFX, it took me about 4 hours to do and it looked better and allowed me to create better, more interactive features.  Most of those 4 hours were me becoming used to the new code and CSS classes.

So, in summary

So to wrap up, development of QW is still going on apace, the next big version, version 3 will be started soon and 2.6.5 will be out probably by the end of the year to allow for user translations of the UI.  For V3, let’s pencil in mid-2018 and I’ll keep you posted with updates in the meantime.

What I’ve been up to and what’s coming up in version 2.6.3

So I’ve been pretty quiet lately.  I don’t like doing too many of these posts.  There is a real danger in development that you tell people that something is “COMING SOON!” and then a life reality hits, for example my son had appendicitis last week, or a complex development reality hits, I’m looking at you legacy Asset fields, and “COMING SOON!” turns into “COMING SOME AT SOME POINT…”.

I’ll start with me first, development on QW hasn’t stopped, it never does but more on that later.  I’ve been trying to do more writing lately and I’m trying to find an agent for my first book.  If anyone knows of a good agent who is looking for a book about two young brothers who discover that their local forest is full of weird and monstrous creatures then please shout up.  It’s obviously a lot more exciting than that I just don’t want to muddy things up here with a full elevator pitch.  Also, if you know of any site or publication that is accepting short stories, mostly for the fantasy and science fiction genres then I’d be much obliged if you could send me their details.  In short, I’m trying to get my work out there, although it seems most of the American publications and sites are on holiday until 1st September.

As an aside, I’ve created a new type of asset for my story called “Literary Agent” and added some agents I plan to send my book to.  Yay, the custom assets are working out.

Now onto QW news.  Some of the most frequent requests I’ve had lately are related to translations of the QW interface into other languages (hello Turkish feature requesters, I haven’t forgotten about you!)

It’s an old request and I’ve struggled with how to effectively implement it for a long time.  On the surface it sounds like an easy problem to solve, someone would like to help and provide their services, usually free of charge, to create a translation.  Sounds great and it is very generous, I can’t stress that enough.  In reality though, and isn’t reality always this way, localization of an interface is a complex and tricky thing to do.  The main issue is that I don’t want to own or be responsible for the translations.  That is, I don’t want to have to pay to get a translation checked or be responsible for keeping it up to date.  For example, if someone provides me with a translation file I have no way of knowing whether they have written the German equivalent, for example, of “Trololololo” for each string.  To check I would need to either pay someone or find someone who I trust who could check it.  Neither option is great.

My solution to this somewhat intractable problem will not involve trust.  Instead I intend to allow end users to validate the translation for me and for the originator of the translation to accept responsibility for it, so if you provide a translation you’ll need to provide an email address and at least tacitly agree to keep it up to date and fix issues found with it.  If you don’t respond to comments on the translation from end users then the translation will be removed or, if it’s abandoned, given to someone else.  Each translation can be voted on to give end users a feeling of confidence in the text provided.  For example, there may be three competing translation files for a particular language, this may sound strange but translation is more art than science (try using Google Translate for anything more complex than “Hello, I’d like a sausage sandwich”) thus one person may translate a phrase one way, someone else another way, the votes will give a confidence measure of the accuracy and usefulness of the translated text.  Translations will also be versioned and the email address of the translation owner available for end users to contact.

End users will be able to use multiple translations within a stack, where one translation overlays the previous one, thus if something is missing from one translation file, another may provide it.

In short, QW will provide a framework where other people can generate and provide translations but I don’t have to try and make sure they are correct.

I’m currently in the middle of moving the interface over so that it can use strings from a file.  Surprisingly there is a lot of text in QW.  I’m also having to change the way that the strings are used so that they are as language unbiased as I can make them.  Thus I don’t prescribe how a string should be phrased or laid out, just that it is there.  It’s a complex thing to do.

Unfortunately I can’t really say for sure how far through I am at the moment.  Tips, achievements and the main project window are done, as is most of the problem finder but I’ve still got editor mode and the rest of the interface to do.  In other words, I don’t have an ETA yet, but watch this space, I’ll do a “COMING SOONISH!” post with more details when I’m closer to finishing.

Version 2.6 – out now

I’m pleased to announce that the long awaited version 2.6 is out now.  It brings a lot of changes to QW, see here for details.  In short you can now customize your characters, locations, research items and items and can add your own type of assets to help keep track of what “things” are in your stories.  This post goes into more depth about the changes and what is possible.

You can also customize the sidebar a lot more with drag and drop for moving sections, drag and drop for moving items within a section and the ability to hide sections you aren’t using.

This release also allows you to tag objects and group them together in their own section in the sidebar.  See this post for more information.

This has been a very big and complex release and will be the only large release this year.  I need a break.  I’ll still be doing a couple of small releases later in the year with some of the suggestions I’ve collected but for now I need to get on with my own writing.  It is, after all, the reason why QW exists.

I’d like to say a big thank you to everyone who is either a Patron or has donated.  If you feel like tossing the odd coin or two my way you can either Donate or become a Patron, every little helps.

In the short term I am going to try and get a wiki and some forums up and running.  The catastrophe that has been my email for the past few months is not something that can continue.  I also need to work on revamping the QW website, it has fallen way behind the actual product and needs some attention.

Enjoy and happy writing!

 

Version 2.6 – nearly here

Good news everyone!  I’ve now finished testing and bug fixing of QW and have moved into the final phase before release.  This period can take anything from a couple of days to a week depending on whether I find any issues.  During this time I actually use QW for writing (it will be nice to get back to that) and try and flush out anything that wasn’t detected during testing.  Think of it as general purpose beta testing.

Also during this time I’ll be preparing the install file, the documentation for the website and the update information that QW itself contains.

I’ll be honest, I’ll be glad to be rid of this release, but more on that in a later post.

Version 2.6 – an update

Just a quick note about version 2.6.  I am still testing at the moment but the good news is that said testing is now approaching completion.  There are nearly 500 formal tests for QW and there are probably that many informal tests again that I run to check other things.  Most tests are an aide-memoire for a specific feature which gives you an idea of the size that QW has grown to.

I’ll be honest, development and testing of version 2.6 has been a long and complicated affair and it hasn’t helped that the changes for assets has impinged on every functional area (for example I am currently testing Editor Mode and sending an update to a project was broken because of the new user configurable fields).

On the upside, I have nearly finished testing Editor Mode and there are only a few minor areas left to test after that.  So I’m hoping (oh god I’m hoping) that testing will be complete by 7th May and then I can release maybe a week later.

What’s coming up in version 2.6

I haven’t done one of these for a while but to be honest there wasn’t much to talk about.  There have been a few “point” releases of QW since version 2.5 but nothing major to discuss.

However in version 2.6 some big changes are coming.

The two most requested features I get asked for nowadays are:

1. More configuration, i.e. customizable fields, for assets (characters, locations etc).
2. A dark theme for nighttime usage.

Item 2 won’t be happening (probably) until I can do version 3 of QW.  Version 3 will be built on a completely new technology called JavaFX and will support a slew of new features.  It will also be a very big change that is going to take some time and certain other things need to be in place before I can even think about moving, but it is coming.  As a side note native Linux and Mac versions will be possible when I move to JavaFX.

Version 2.6 will deal solely with item 1.  At first glance it seems like an easy thing to do, just allow users to add new fields, but the implications of doing so are huge.  I would add that an ancillary feature request often tacked onto the request for new fields is the ability to arbitrarily group and order items.

With the preamble over, here’s the 10,000ft view of what will be new in version 2.6.

Drag-n-drop of sections in the project sidebar

Currently the sections in the project sidebar (the panel that shows the chapters and characters and so on) can’t be customized very much.  You can either open or close a section and that’s your lot.

Version 2.6 will allow you to drag and drop the sections around, reordering things to how you would like them to be displayed, so if characters are the most important to you then drag them to the top, or if you are in the middle of getting feedback from your editors, drag those to the top.  The choice will be yours.

Adding/removing sections in the project sidebar

So you can drag-n-drop sections but what about if you never use a section and don’t care about it?  Well in version 2.6 you’ll be able to hide sections (and reshow them) whenever you like.  If you are not using “Research Items”, then why not hide it and save some space.

New object types

You’ve now removed all the things you don’t need in the project sidebar, you’ve moved things around to fit how you like them, but what about if you have something that isn’t an “Item” or a “Location” or a “Character”?  What about if you want to be specific and have a list of Cheeses or Spaceports or Books or Candlesticks?  In 2.6 you’ll be able to create new types of objects and each type will become its own section in the project sidebar, which you can hide or show as you wish.

Customizable object fields

So you’ve created your “Cheeses” object type, now you want to record some information about them, maybe stuff like “Smell” or “Color” or “Consistency”.  In 2.6 you’ll be able to add as many new fields as you’d like and record as much information as you like.  Here’s a list of the types of fields you’ll be able to add:

• Text – a line of text
• Multi-line text – err, multiple lines of text
• Files
• Select an item from a list of possibilities (think drop down list)
• Number
• Date
• Web link
• Another object – for example you might want to associate a character with their favorite cheese

Layouts

Your object is created, your fields added but now you have a different problem, how should the information be laid out and displayed?  A number of possible layouts will be available.  Some possibilities are shown below.

BTW, if you eat cheese that has pickled onions in it (yeah I’m looking at you Mersey Valley) then there is something wrong with you.  Seriously go see your Doctor, you are either pregnant or mad.

Tagging

But wait!  There’s more.  I’ve sometimes been asked to allow sub-groups or sub-types of objects to be created, or to allow arbitrary groupings of objects together that have some sort of commonality.  If we stretch our cheese example a little more, how would we group together characters, locations, chapters, notes and whatever-else-you-can-dream-up into a single easily identifiable group?  The answer I propose is tagging, that is you apply the same tag or label to each of the relevant objects.

So if you have a character that is obsessed with Wensleydale (let’s call him “Wallace”) and his location may be “62 West Wallaby Street” and you’ve created a new type of object called “Dogs” and you have a dog called “Gromit” and you have chapters called “A Grand Day Out”, “The Wrong Trousers” and “A Close Shave”.  You might give each of these objects the tag of “Where’s the Wensleydale Gromit?” to group them all together.  You’ll then be able to see the tagged objects in their own section in the project sidebar.

It will look something like this.

Cheeeeese Gromit!

The advantage here is that you can group items together without having to nestle them within a sub-branch of a tree, they remain accessible at the top level and can be dragged and dropped around like any other section.

To add new items to the group you just drag them from another section… which leads me to…

Drag-n-drop items within a section

The final new feature deals with moving items of a particular type around in their section.  You can already drag-n-drop chapters around to order them, so why not characters or locations?

When will it all arrive?

Not sure yet.  I’ve already done the drag-n-drop and hiding of sections and I’ve started on the customizable fields and layouts, but I won’t deny, it’s a huge piece of work that impinges on a large number of areas and that means time.  Christmas is also in the way as is the unforgiving Brisbane summer, where you often feel like mother nature is lurking behind every ominous looking cloud with a piece of 2 by 4, just waiting for you to drop your guard so she can smash your head in with it.

Sometime in February 2017 is a realistic date but it could take longer.  My wife starts a new job (and career) in February and my son starts a new school then too so it will be hectic time and little may get done.  Life finds a way of getting in the way.