What’s happening with QW

(I really need to start doing these more often, the only trouble is, in software development things don’t move very quickly so you forget how long it has been since you last posted something!)

So recently I’ve been working with a very helpful guy from Poland to get non English translations of the User Interface available. Basically to flush the bugs out of the system and make things better. There is now a full Polish translation available and partial ones for French and Spanish.

My current effort, and this will be released in version 2.7, is focused on allowing the QW website and User Guide to be translated as well. The only trouble is that this is tiresome and tedious work so it takes a while.

I do have a longish list of user requests that will also be added in 2.7, they are mostly minor tweaks and ease of use things, like adding keyboard shortcuts to navigate through the tabs and having an option to turn off the startup splashscreen.

Longer term, I want to improve the spellchecker and problem finder and make it available for other languages. I also want to revisit my timeline planning tool, I had taken a stab at it a while back but technical issues prevented me from continuing but it’s a feature that’s been requested a few times now so it’s coming back to the top of my attention pile.

I am also planning an online backup and save function that would be for Patrons only, this is because I can’t afford to make the feature free and Patreon would make collecting payments etc easy.  This would provide backups and have your data be in the cloud for safe keeping (encrypted of course) but would also mean you could access your projects on any computer with QW installed.

Longer, longer term, version 3 will be on a new technology that will open up a lot more possibilities and features that are a little too painful to do at the moment.

So, lots to do!

Advertisements

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!

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.