Satori-Project

It’s been a little while since the last release.

The biggest change to the not-yet-released version was a rewrite of the ThreadWorker class.  Most are probably not familiar with this class, but EG (and SatoriHub) work by serializing events in a queue.  The queue is processed in its own thread – the eventThread, which is an instance of ThreadWorker.  Every action triggered by an event is then processed in a third thread (in addition to the eventThread and the UI thread) called the actionThread, which has its own queue and is again an instance of ThreadWorker.  Externally, there should be no difference from the rewrite - the api was not changed at all.  However, the EG classes included a WinProc component [it only checked for WM_QUIT (no idea why)], which was removed in SatoriHub, and internally the queue was reworked to use Qt signals and an EventLoop.  Having an EventLoop allowed me to follow the advice of this blog and refactor some of the threading code to make it both cleaner and more reliable.

Why the gory detail for a change that no one should notice you ask (if you haven’t already stopped reading)?  For one thing, Task events stopped working.  And task events are key to the whole context switching feature of SatoriHub.  Turns out that MessageReceiver (which is what generates Clipboard changed, Task and Device messages) in EG runs in a ThreadWorker instance and requires the WinProc handling.  So I rewrote MessageReceiver so it is processed in a winEvent override in the UI thread.  Again, no change to the API, so you shouldn’t see any impacts.

Since I’ve already mentioned that there shouldn’t be any impacts from these changes, I decided to throw in some more….  QString is the unicode string type used internally by Qt.  It has methods similar to Python’s string/unicode types, but is a distinct class.  Qt widgets that return text normally return the type QString, and QString is what the examples in Mark Sommerfield’s book work in.  However, there’s a nice feature of PyQt – you can use “sip.setapi('QString', 2)”, and PyQt will automagically convert to/from QString/unicode for you (this isn’t covered in the (excellent by the way) book).  So all of the ugly Configure return values could be rewritten from

1: unicode(myLineEdit.text())

to just

1: myLineEdit.text()

This is much cleaner and Pythonic code, but it did require changes to a LOT of files.  In a similar manner, “sip.setapi(‘QVariant’,2)” gets rid of a lot of QVariant handling in SatoriHub.  QVariant is a “generic” type, which allows you to pass anything to a function, even in a strongly-typed language like C++.  Since python isn’t strongly typed, this led to particularly non-pythonic looking code, so this changed leads to more consistent, cleaner code that shouldn’t break anyting.

So, the theme is that while all of these changes to all of these files shouldn’t break anything, there were probably some bugs introduced.  Yeah, I’ll admit it.  My code isn’t 100% bug free (if you’ve read this far, you are probably a developer and that statement won’t shock you at all).  So the delay in a new release is due in part to additional testing.  But I think it is worthwhile to get these types of changes in during alpha testing, too.

I did say the delay was in part because of these internal changes.  I’m also working on some very interesting new features on the UI/On-Screen-Menu front.  With all of the extra testing, I had to add some stuff to keep up the WAF.  That will be a topic of another post (or 2).