Is Quoll Writer looking psychedelic? It’s not you!

I’ve had reports from a few users of QW that it sometimes goes nuts and starts looking, for want of a better word, trippy.  That is multiple parts of the user interface appear to overlap others.  It’s ok, no one is spiking your tea with magic mushrooms.  It’s something far more mundane.

Unfortunately I don’t have a picture but the image below is the sort of thing I mean.

Source

I believe this issue relates to the D3D system on Windows.  For whatever reason Java isn’t playing well with D3D.

The fix is a little arcane but seems to work, just follow the steps below (my thanks to Gillian for working this out).

• Open the Control Panel
• Go to System
• Click Advanced System Settings 
• Click Environment Variables under the Advanced tab
• Click New to create the variable (in the User variables section) and fill in the following fields:Variable name: J2D_D3D

  Variable value: false

• Click OK

Now the steps to get to the System Properties are for pre-Windows 10.  In Windows 10 in the Control Panel search box you can enter Environment and then click Edit environment variables for your account to skip straight to the fourth step.

You then restart QW and it should stop the hippy-trippy effect.

I am going to do some testing and add the variable to the standard QW build to see if that has any negative effects.  i.e. can I add it without messing anything up.

Update (21/Sep/2018):

I have also been told (thanks Marrie!) that if you disable the Aero Glass effect, in Windows of course, then it might solve the problem.  See here for details on how to disable the effect.

Advertisements

Another update on version 2.7

Version 2.7 is still progressing.  The QW website has been changed over to support multiple languages and the User Guide has been reworked and revamped.  At the moment I am finishing up the changes to QW itself to support website translations.  A number of new features have been added to the strings editors such as a find and the ability to filter out certain ids.  I am currently adding the ability to test out a website translation.

Once the website translation stuff is done I’ll be moving onto bug fixes and new features for QW in general.

And I have to say, I will not miss this translation stuff!  I am utterly sick of it.

The Change Cascade

When you first develop a piece of code you generally do the best you can to make it fit for purpose and work in a flexible way.  Then, later on, you might need to come back to the code and change things to work in a different, or even more flexible way.

A good example of that for me is the changes I’ve had to make to support translations of the Quoll Writer website.

After doing some research there were a number of best practices that I decided to implement, the most important one is to identify the translation via an ISO language code embedded in the URL you use to access a page.

For example, at the moment the downloads page for QW can be found at:

https://quollwriter.com/downloads.html

This, of course, will serve the English version to the user.

Now, if someone creates a Polish translation of the QW website there needs to be some way of them accessing that translation and the server needs to know what translation the user want to view.

One of the recommended ways of doing this is to embed the language code at the start of the path in the url, thus:

https://quollwriter.com/pl/downloads.html

Pretty straightforward, for a German translation you would use:

https://quollwriter.com/de/downloads.html

French:

https://quollwriter.com/fr/downloads.html

and so on…

The server examines the url requested, sees a language code and returns the translated page.

But the problem is that the code that serves pages to the user had no concept of these languages.  It was never designed to handle multiple languages or to examine urls in this way.  So begins the change cascade.  Just adding these two letters to the front of the url path requires a long list of things to happen, and for each “thing to happen” I need to make a change, with one change cascading onto another and creating implications and changes of its own.  It’s like watching an ice crystal grow.

So why am I telling you all this?  I realised long ago that creative writing and writing computer code are very similar disciplines.  They are both more art than science, they both require creativity, they follow similar rules, they have similar structure.  Change cascades also happen in creative writing, you make a seemingly minor change that then tumbles through the rest of the story, creating implications and forcing modifications, modifications you couldn’t possibly foresee at the outset.

The lesson here is not to be afraid of the change cascade.  Don’t cling to something you know needs to be changed just because of the changes it will cause.  If you know a story will be improved by the change then embrace it, make the change, then get to work.

Getting a case of Developer’s block and what it taught me about Writer’s block

We’ve all had it, sometimes we just don’t want to move forward or worse still, know how.  But did you know that you get it in all walks of life?  It’s not just a problem for writers.  Sometimes you get stuck thinking about a problem or avoiding the problem altogether.  How many of you have avoided that difficult conversation or the annoying task?  It’s writer’s block, just manifested in a different way.

Recently I’ve suffered with a case of Developer block.  I had a technical problem to solve that I just didn’t want to tackle.  Creating version 2.6.5 of Quoll Writer was extremely painful for me.  It was repetitive, technically frustrating, repetitive and tedious.  It drained my mental resources and even a long-ish holiday to New Zealand only partially helped restore me to “normal”.  In the past few weeks, apart from releasing bug fixes for QW, I’ve been working on an update to the User Interface translation editor to support creating translations for the QW website.  However I kept getting stuck, I kept getting Developer’s block.  I knew what I had to do I just really, really didn’t want to do it.  I would make any excuse I could to avoid it, “I’ll just do this first”, “I’m too tired tonight”, “the kids have been annoying me today”, “I’ll play Witcher 3 for a bit”, “mmm biscuits…”

Growing increasingly annoyed with myself (sound familiar?) I thought about what was actually blocking me.  What was the task I was avoiding like it had a terminal case of leprosy-black-death.  After some introspection, I realized I was avoiding making the Quoll Writer desktop application interact with the Quoll Writer server.  The application needs to make a request to the server to get the English strings that act as a base for all the translations.  It’s not trivial to implement but it’s not difficult either, however it is fiddly and tedious.

With the problem identified the block disappeared, I had identified exactly what I needed to do and why I was avoiding it.  Instead of the problem being a vague miasma lurking just beyond my reach I had given it shape and form and, more importantly, given it a clearly defined boundary.

So how does this relate to creative writing?  To me, the problem of Writer’s block is the same as Developer block and the solution is the same.  Identify the problem, define it, give it a form, a shape, a boundary.  If you have to write a difficult dialogue scene then plan it out, give it form and flow before tackling the details.  If you have to write a descriptive scene then maybe draw the geography or thing you want to describe.  The important thing is to identify exactly what you have to do and give it a boundary.  Know thine enemy.

But wait, there’s more.  You see thinking about this problem helped me realise that I always dislike doing server interactions for the QW app.  This isn’t the first time I’ve had this type of block.  But now I’ve identified what I dislike doing I can plan for the future.  The next time I have a server interaction I can detail exactly what I need to do and plan for it, I can give in a boundary.  In my own writing I often dislike and avoid descriptive scenes.  I love me some Tolkien and that guy could describe for his country but I’m not Tolkien and I need to know what I dislike doing to be able to give it form.  So, the next time I have some writing I know I’m going to avoid, descriptive or otherwise, I know what to do.

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!

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.