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!

 

Creating your own Assets in Quoll Writer

Version 2.6 of Quoll Writer introduces the ability to create your own Assets.  An Asset is any type of thing that may relate to your story that you want to keep track of.  For example I am currently writing a science fiction story set in spaaaaace and I want to keep track of the planets I’m creating, now I can.  Additionally I can record as many fields or bits of information about my new type of Asset as I need.

Note, these new “user customizable fields” as I call them also apply to the standard, existing Quoll Writer Asset types of Characters, Locations, Research Items and Items.  Everything that applies to new types of Assets also applies to them.

Any new types of Asset you create will be available in all of your projects.

Creating a new type of Asset

To add a new type of Asset right click on an existing section in the Project sidebar (or right click on the background of the sidebar) and select Add new type of Object.  You’ll see the following popup.

As should be clear this first step sets up some basic things about your object.  Things are pre-filled in to get you started.

Clicking Next > takes you to the next step where you can add fields.

Adding fields to the Asset

A couple of “standard” fields will be automatically setup for you, this is to allow you to quickly get going by clicking Next a few times.

There are a number of different types of field you can add.  To add a new field click on the + icon above the fields.  A few of the field types are described below.

You’ll notice I named my new type of object “Planet”.

Adding a single line text field

To add a single line text field to the object, click on the add field button then select Text from the drop down list (it’s the default).  You need to give the field a name, remember I’ve already got a “Name” field which would be for the name of the planet.  In this case I want to record what the main spaceport is for the planet is so I call my field “Major Spaceport”.  You can change the name later.  Click on Save to add the field.

Note: if you want to have aliases or other names for the object check the Is other names/aliases for the planet, any values you enter in the field will be assumed to be an alias for the object and thus identify the object.  You can have as many fields marked as aliases as you want.

Adding a multi-line text field

To add a multi-line text field (think more than one line) select Multi-line text from the drop down list on the add field form.  Here you have the option to display the text entered as bullet points and it can also be aliases/other names.

In this case, I want to record the main imports/exports for the planet and have them displayed as bullet points.

Adding a number field

Finally I add a number field and you guessed it I need to select Number from the drop down list.

In this case I want to record the population of the planet, you can specify a maximum and minimum value for the field (this can be useful if you want to record a value that usually has well known limits, for example the age of a human).  The maximum/minimum are optional to complete though so you can ignore them if they don’t interest you.

Other types of fields

The fields above are just some examples to get you going, but you can also add:

• Web links
• Lists of things
• Images
• Dates

A future version will also add the ability to link different objects together, so I might create a “Spaceport” object and then have a field in the “Planet” object to directly refer to the specific Spaceport object.  Other improvements will be to have an image “gallery” that allows you to have one field for multiple images.  I also have plans to move the existing “Documents” section to be just another field.  I wanted to do all these things in version 2.6 but I just ran out of time.  If you would really like to have these things added, or have ideas for other fields then let me know.

Moving fields around

Some of the field layouts, which are discussed in the next section, take the order of the fields into account.  You can move the fields up and down in the list by using drag-n-drop.

Selecting how the information is displayed

So you’ve selected the name of your object and added some fields about it.  Now it’s time to decide how the fields/information should be displayed.

Shown below is the layout selector.  By default the fields will just be shown in a single column.  Once created you can change the layout as much as you like and the display of the object will be updated.

The layout you choose will affect how the fields are displayed and how they are shown when you are adding new instances of the object or editing them.  Some examples of layouts are shown below.

A layout with the description on the left hand side, other fields on the right

 

The same layout as the previous example but this time for editing the Planet.

 

In this layout no field is given any special prominence and they are displayed in two equal columns

 

Same layout as above but you’ll notice that the name field is given special prominence.  This is because you don’t want to have to try and find the name at the bottom of a column

Changing the layout is easy and I would encourage you to experiment to find the layout that suits your needs the best.  In general the name of the object, the description and its image are all classed as special fields for the layouts and are treated in special ways.  For example, the layouts that give the object description special relevance will try and make that field as big as possible, the object image is also shown in a specific place.

Changing things around

Once you’ve saved the information about your new object, you can easily change things around to fit what you need.  Just right click on the type of object in the sidebar or right click on an instance of the object when viewing it (in its own tab) and select Edit the Object information/fields.  Any changes you make will be immediately reflected in the object tab.  You can change the icons, the name of the Asset, add new fields, remove fields, change them, move them around, go wild 🙂

However, I recommend creating your own type of Asset first and learning how to add fields/move them around and so on before changing any of the standard QW Asset types (i.e. Characters, Locations and so on).  Bear in mind that if you remove any fields from those standard objects you may lose information, so take care!

Using Tags to group things together in Quoll Writer

Another of the new features added in the 2.6 update is the ability to “tag” objects to bring them together in a single group.

So let’s say you are writing a story about The Red Hand Gang, you’ve added all your characters but want to group the core characters together under one section.  It’s now easy just add a new tag called “The Red Hand Gang” (or whatever name you want to give it) and then either drag-n-drop the characters onto the section, or right click on the character and select the tag from the “Tags” menu.

Here’s what it looks like:

(Anyone else remember The Red Hand Gang or am I just old… actually don’t answer that!)

Any tags you add will be available to all of your projects.  I’m still on the fence about per-project tags, but if you have a strong view on it, let me know.

So let’s go through the management/adding of tags in detail.

Adding a new tag from an object

First off we need to add a new tag.  Probably the easiest way is to add the tag from the object.  In this case we are talking about characters so right click on the character in the characters list in the sidebar and from the Tags menu select Add New Tag(s).  You’ll be shown the following popup:

You can add as many tags as you like, just separate each with commas (,) and semi-colons (;).

The tags will be added/applied to character Lil’ Bill immediately.  Note however that the sections associated with each of the tags won’t be added to the sidebar.  To make the tags available you need to add them individually, right click on a current section and select Add section below or right click on the background of the sidebar and select Add section.  Then select the tag you want to add.

Adding/managing tags in general

If you want to manage the tags in general, i.e. all at once.  Then either right click on the background of the sidebar and select Add/Manage the Tag(s) or, in the Options panel, go to section Assets & Tags and click the Manage the Tags button.

Whichever you choose you’ll see the following popup:

An important thing to note here is that if you remove any tags using this popup then they will be removed from all of your projects.

While you can rename a tag from this popup by double clicking on the item and changing it you can also rename a tag from the tag section in the sidebar, right click on the tag name and select Rename.

Remove a tag from the current project

To remove a tag from just the current project, right click on the tag section in the sidebar and select Delete this Tag, you’ll then be shown the following popup:

As you can see this gives you the choice of removing the tag from all projects or just the current project.

Removing tags/adding existing tags to an object

To quickly remove tags or add existing tags to an object just right click on the object in the sidebar and in the Tags menu check/uncheck the tags that you want to apply/remove.

Please note I am aware of the annoying bug that makes the highlighted text in the menu white.  This is an “other people’s software problem” (which is the bane of my life btw).  I have contacted the developer responsible for this issue a couple of times and he has ignored me.  QW3 will remove the need for his software altogether thus solving the issue.

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.