Skip to main content

wxWidgets Accessibility

For a while now I've been writing wx.Python and wxWidgets applications for MS Windows.

But I've always assumed both to be inaccessible on Linux/GTK. In fact that was the response from one of the regular contributors on the Orca mailing list.

But I think there must have been some advance in versions or something because in the last couple of days I have:

  • Written a Hello World! application for Linux in `wx.Python
  • Written the same for Linux using wxWidgets (in C++)

And they are both totally accessible!

OK that's probably a rash statement because the apps I wrote did not have every kind of wxWidgets control. But buttons, message boxes, menus and static labels are all spoken by Orca.

My wxWidgets Hello World! program did have all the above.

So, now I'm on a mission to try out as many of the other native GTK controls as I can, or at least all those which are obviously not irrelevant to blind folks, like bitmaps and stuff.

The versions I am running are:

  • wxWidgets version 3.0
  • GTK 3.0

I don't know about the wx.Python version but it's what is in the Debian Jessie repo so it is probably quite up-to-date at the time of writing.

Next mission, given good results with more controls is to write a tree-based GUI designer, because being a blind programmer, drag-and-drop WYSIWYG GUI designers are not really of any use.

Emacs/Emacspeak Initialization Strategy

This afternoon I have changed the way my emacs and emacspeak initialization works.

Until now I have always used the file:


For my initialization. But today, in reading about how emacs initialization and library-loading works, to try to understand how T.V. Raman does it and how his files in the git repository all hang together, I have made a discovery which has made me understand things a lot better and change my strategy.

Initialization Files

emacs will look for any of these files for it's initialization:

  • ~/.emacs
  • ~/.emacs.el
  • ~/.emacs.d/init.el

So, I changed from using ~/.emacs to ~/.emacs.d/init.el.

Not only that but I have made some other discoveries, things which I did not know about before.

In our .emacs files we have usually had two blocks of lisp that begin with:

  • (custom-set-variables ...
  • (custom-set-faces ...

These two blocks of code are places into which changes are made when the emacs customization screens are used to make adjustments, hence the commentary in these blocks which warn about editing them by hand and not having more than one occurrence of each block.

Now, of course when adding stuff to the emacs initialization files by hand it is very easy to screw something up and stop the initialization from working.

When running emacspeak this is always immediately obvious because it comes up talking very, very slowly. Assuming of course you have emacspeak configured to talk more quickly than the default.

It is possible, it seems, to place the custom-set-variables and custom-set-faces code blocks into a separate file, name it as the custom file and then load it from the main initialization file.

So, bearing in mind we are now using ~/.emacs.d/init.el as our initialization file, place these two lines at the top of it:

(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)

The first of these lines instructs emacs that we want to use a different file from our main initialization file for custom changes made by the emacs customization mechanism.

The second line instructs emacs to load it.

Now we can merrily add other stuff to ~/.emacs.d/init.el, knowing that we are at no risk of messing up those customizations added with the emacs mechanism.

Loading Personal Libraries

Instead of loading everything we want in our initialization file, we can split it up, and make it much more modular. In this way we can tinker with something new, and when something breaks, we know more easily what broke it and probably how to fix it.

The first thing we need to do, again in our shiny new ~/.emacs.d/init.el file, is to add some paths to the load-path variable in emacs. It is this variable which acts a bit like the $PATH environment variable in the bash shell.

Put this fragment of code in your ~/.emacs.d/init.el file, just underneath the top two lines which specify and load the custom file:

;; add some paths to load-path
(let ((default-directory "~/.emacs.d/lisp/"))(setq load-path
(let ((load-path (copy-sequence load-path))) ;; Shadow
(copy-sequence (normal-top-level-add-to-load-path '(".")))

This will add:


And all of the sub-directories thereof to the load-path variable. Well, not ALL the sub-directories. It will ignore things like version-control related paths, sub-directory names that start with a dot etc., very useful if you want to put your initialization stuff in git or CVS.

Now we can add a whole bunch of load-library directives below this to load individual personal libraries of lisp code:

(load-library "elpa-prepare.el")
(load-library "markdown-prepare")
(load-library "rst-prepare.el")
(load-library "abbrev-prepare")
(load-library "c-code-folding-prepare.el")

These are just a few libraries I have created from splitting off the code which I previously used to have in my ~/.emacs file.

It should be obvious from the names what each library is for.

What was left in ~/.emacs?

There were a few lines of code remaining in my original ~/.emacs file which I left in the new initialization file:

(setq-default truncate-lines t)
(setq inhibit-splash-screen t)

Before I did this work today it was very hard to wade through all of the custom stuff, the markdown initialization code, the rst initialization code, and find these lines.


By doing this stuff this afternoon I think I have:

  • Split my original emacs initialization file into multiple library files which I load individually
  • Split my manually added initialization code from the code added and changed by the Emacs customization mechanism, which should make identifying errors easier
  • Dramatically increased the modularity of my initializations, making it more scalable
  • Made tinkering with emacs configuration less scary and hence more inclined to get done
  • Learned some valuable stuff about Emacs and Emacs Lisp

Note About load-library and .elc Files

By adding the path to our personal-libraries to the load-path variable we can leave out the .el extension of our libraries.

If byte-compiled versions of any of our libraries exist in .elc files, these will be loaded in preference to .el files, giving us an appreciable speed advantage.

To batch compile all the .el files in ~/.emacs.d/lisp:

emacs -batch -f batch-byte-compile *.el

The above will create .elc versions of each of the .el files. These will be the files which are loaded in preference to the .el files.

A Way of Using Include Directives in Markdown Posts and Pages

Using an include directive with Markdown in Nikola Pages

I love markdown. I think it's the best thing since sliced-bread. The ability to write complex documents with a simple set of formatting syntax that can then be converted into a raft of other formats, possibly with pandoc is probably the single biggest boost to your productivity you could find if you write a lot of documentation.

Nikola uses markdown, among other flavours of document formatting such as restructured text and org-mode text (an Emacs major-mode). But my choice is usually markdown. One thing I thought it was lacking until somebody asked the question on the Nikola mailing list was an include directive similar to that in the C pre-processor.

What follows is a distillation of the ensuing posts and discussion from the list.

First install the markdown-include Python package:

sudo pip install markdown-include

Now modify your to add this, there is one commented out which looks similar:

MARKDOWN_EXTENSIONS = ['fenced_code', 'codehilite', 'extra', 'markdown_include.include']

Embedding include Directives in Markdown Posts and Pages

To include a file in a Markdown post or page:

Note the path is relative to where markdown_include is being called from, not from the directory containing the post/page. So something like:


Assuming you have include/md/* immediately underneath where your is, e.g. the root of your Nikola site.

To change the root of files you wish to include, in place the following:

from markdown_include.include import MarkdownInclude
my_include = MarkdownInclude(
    configs={'base_path':'/srv/content/'} # can also be relative path to
MARKDOWN_EXTENSIONS = ['fenced_code', 'codehilite', 'extra', my_include]

I can't claim any originality for this as it was pulled directly from the Nikola email list. I'm putting it here because it's a subject that is very close to my heart, e.g. modularity. I've already installed the txt2tags plugin and I'm using t2t includes to pull-in tables of keyboard commands for such things as Emacs major-mode key-bindings.

This site seems to be veering slightly away from it's originally intended purpose of gathering into one place all kinds of stuff relating to accessibility on the Linux platform and becoming something of a personal blog and library archive for snippets of useful stuff.

Oh well, I guess it's my party...

Debian Mate Media Controls

This is another post which deals with issues surrounding the use of pulseaudio for text-to-speech and access tech such as the Orca screen-reader.

In the previous post I described how to switch speech-dispatcher over to ALSA and avoid the use of pulseaudio. Doing this will make the console accessible with speakup even when you are logged in to a graphical desktop.

But the default media controls in a Debian machine using the Mate desktop, at least at the time of writing with Debian Jessie, are for pulseaudio.

I have experienced issues with my Dell Latitude D630 where the headphone jack goes silent. I have never established why. This can be very annoying and happens at the most inopportune moments, usually in a room full of sighted folks who would very quickly try and lynch me if they had to listen to espeak through my PC speakers for more than five minutes.

This can be fixed by uninstalling a couple of packages and installing some alternatives.

The packages we are going to remove are:

  • `mate-media-pulse
  • mate-settings-daemon-pulse

The two packages we are going to install in their place are:

  • mate-media-gstreamer
  • mate-settings-daemon-gstreamer

But, beware! The first time I did this I made the mistake of purging the first two before I installed the new packages and it broke my installation. I then had to re-install Orca, Mate and lightdm.

So we are going to let apt-get make the decisions about what to install and what to remove.

Do the following:

$ sudo apt-get install mate-media-gstreamer
$ sudo apt-get install mate-settings-daemon-gstreamer

You will hear some stuff about removing one and replacing it with the other.

After this your sound controls in Mate should be much more usable and include the headphone jack if you have one.

I can't claim originality for this. The problem and the fix described was experienced by my fellow Linux and Raspberry Pi hacker Rill.