Sebastian Huber edited this page Apr 6, 2015 · 12 revisions

Here you can find some development hints you should better read before starting.

  1. Building
  2. Logging
  3. TODOs
  4. Versioning


How to build the application in Visual Studio can be found on the Getting Started page.


Use the log, Luke.

The Player makes extensive use of logging. It uses the NLog framework therefor. The configuration can be found in NLog.config. Feel free to customize the logging level of a single namespace or the whole application to your needs, while you are on a local branch.

The log file itself will be created directly beside the exe file of the application (e.g. KeyboardX\Player\bin\Release\Player.log). This can again be changed via the config. It is highly recommended to use a professional log viewer, like e.g. LogExpert.


TODOs are kept as comments directly in the source code, near where they really matter. To keep an overview of which TODOs are most important, there was introduced a prioritization schema:

// TODO <priority>: <description of TODO>

Where priority range is [1;9] and 9 is the topmost priority. Priorities [6;9] are reserved for local development and should not be commited into master branch.

Visual Studio provides a Task List View where the TODOs are listed in a neat way:

TODOs in Visual Studio

This approach is the most integrated way and has the advantage, that TODOs are near where they really matter. Nevertheless, for abstract, higher level TODOs GitHub Issues should be used in future, as they provide a better workflow and discussion.


KeyboardX is still under heavy development. Major things may change rapidly. For now, semantic versioning makes no sense here. It's just important to have any kind of version number to distinguish between different releases. And to recognize the sequence of releases. So simply the date in the form of YYYYMMDD was chosen for versioning.

As soon as this circumstances changes, semantic versioning is proposed as the way to go.


The schema for keyboard files defines a minimal valid version attribute for a keyboard. If the schema is updated in a way, that would break validity of currently valid keyboards, this minimal version is increased (to current date string, see above). This helps detecting invalid keyboard files.

The schema file itself contains also a version attribute. This is only for recognizing the version of the schema and is not used further.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.