Alex Elliott

The internet home of a prospective software engineer

This is my personal blog where I discuss projects that I'm currently working on, work I've recently completed, or write about any topic which has caught my interest in the world of Computing from my studies or from my personal research.

Latest Articles

Qt on Android with Necessitas

February 9th, 2012

One of the best things about the Qt toolkit is its portability, and that has only been improved by Project Lighthouse which provides a way to deploy Qt applications to all sorts of platforms. This has been levereged by an alpha port to Android of not only Qt – but also the Qt SDK (including Qt Creator integration) produced by BogDan Vatra.

Considering I have a couple of android devices around (phone and a tablet) I thought it was worth a look to see if this port (Necessitas) would allow me to run Expression Editor on the android platform. Starting with the basic set-up, I installed Necessitas with the Android SDK/NDK and Apache Ant and then opened the project file for Expression Editor in the Necessitas IDE. It adds a set of files required to run the application at this point, and it is necessary to edit android/res/values/libs.xml to note that Expression Editor links to QtXml as well as QtCore and QtGui.

I initially made an attempt to set up the existing CMake build system with Necessitas, but that proved to be quite vexing – so for the means of a proof-of-concept I reverted to qmake, and removed the optional components (PCRE, ICU, POSIX, C++11) from the build system. Since Necessitas has primarily been built around qmake this worked quite well and with only a few modifications to the source code (it didn’t like qMax(qreal, double) but a simple explicit static_cast was enough there) it built an .apk which then failed to deploy.

I hadn’t ensured that the android emulator had Ministro (which is used to provide the Qt libraries on Android – it is available from the Market) installed, after installing that via adb, it then deployed to an Android 3.1 based emulator successfully.

Expression Editor Running in Android Emulator

Expression Editor Running in Android Emulator

I’ve uploaded the produced .apk as a download on github and the source used is available under a separate branch, it does require Ministro to run. However, treat it with a lot of caution, I have not widely tested it, as it is mostly just a proof-of-concept, it does run correctly on my Galaxy Tab 10.1 but I can’t vouch for it elsewhere.

In any case, the fact that this was possible in under one day (and it runs very well considering I have made no real alterations to the source) really does show how portable Qt is today. It’s a very impressively complete and polished port for its early alpha stage and I am very thankful that people like BogDan Vatra are doing this work, and very thankful that Qt continues to be developed as one of (if not the) best ways of writing cross-platform applications available today.

New Lexing Parsers and What They Mean for Expression Editor

February 2nd, 2012

Back in September (prior to some uni work that rather soaked up my free time) I pushed a fairly major restructuring of Expression Editor to the repository. Functionally it has meant a bit of a step back, but the new structure does mean some significant improvements to how it works now, and provides scope for some things which would not have been possible before. I thought that since this has been neglected for a while, I might as well give some details on it while I still have a window of opportunity.

What has changed?

There is one major difference in how it operates now compared to how it worked before. Prior to this the parsing of regular expressions was rather ad-hoc, it was a process that grew as I built in support for more different syntax elements. The result of that was in the long term it would get increasingly difficult to ensure things were being parsed correctly, it also did not react well to being passed an invalid expression – it would tend to just fail and so the display did not update while the expression was invalid.

To improve on that ad-hoc approach, I replaced it with a single consistent method – a lexing parser. The system defines a range of tokens (over 100 different ones) from simple literals (T_LITERAL), through common syntax elements like ^ (T_STARTING_POSITION), through to less commonly used syntax elements like “(?<!” (which is of course T_NEGATIVE_LOOKBEHIND_ASSERTION_OPEN). The tokens available span across regular expression formats and provide a unified representation within Expression Editor to work with.

Of course there need to be regular expression backend specific parsers which convert their respective formats into a sequence of unified tokens. This is handled via a polymorphic set of parser classes based on the Parser base class (parser.cpp/parser.hpp), the general logic of the parser exists in the base class. It uses a map of tokens in the regular expression format onto regular expressions describing that syntax to find the longest match it can (in the case where some matches are of the same length, the first match is used). The result is then passed to handleToken() which handles the logic that should apply whenever a token of that type is found (for example, when a T_GROUPING_OPEN is found, it should continue to consume tokens until a T_GROUPING_CLOSE is found, if it reaches the end of the sequence without finding one, that T_GROUPING_OPEN should be reassigned the type T_ERROR as it is not balanced).

This structure – as mentioned in the last example given – is capable of handling invalid syntax correctly, and it’s fairly simple to implement new parsing backends as the logic is very consistent. The shared format is also very useful as it means that any new backends which use a different format will be easier to integrate.

What impact does this change have?

Well, initially it means a lot of things are no longer working, that’s unfortunate but on balance I think something that had to be done. At the time of writing two of the three testing widgets are no longer functional, the save/load/common/recent files is no longer in place and the visual editing which was there is not any more.

Not everything is bad news though, there are already some new features made easier by this system. The visualisation is now capable of updating even while there are errors in the expression. It will simply mark them as T_ERROR via the parser, and they will appear as red blocks until they are fixed – this means you can now spot errors via the visualisation. The amount of configuration possible has also increased, the settings dialog now provides a set of options for how the visualisation is presented and the aim is to keep adding further options as visual elements are added to the system. Allowing for the appearance to be tailored entirely to your specifications.

There are also more possibilities for the future than there were previously, by converting the regular expression to a shared format it opens up scope for regular expression optimisers and translators in the future. It would be nice if you could take an expression you had already written for PCRE and have the application convert it into say POSIX ERE for a system where PCRE is not supported or available. That would be a lot easier with this unified token sequence, as it would simply be a case of translating in the opposite direction to the original parser. Some elements may not be possible due to limitations of the format, but nevertheless it would be a useful feature to have.

What work is going on at the moment?

Not as much as I would like, really. I’ve got other stuff on via university – but I do want to try and bring back the features that have gone missing since the restructuring, and then I can get back to bringing in new functionality which would make this a better piece of software than before the restructuring. In the meantime the previous application is tagged in the repository, so the functionality is still available. Hopefully though it won’t need to be around too much longer.

Oh, a final passing point – another thing that has changed since the last time I wrote is that the CMake build system is now capable of producing an NSIS executable installer for Expression Editor, there is one available via GitHub which contains the new build of Expression Editor, and I’ll try to keep it as up to date as possible. I’d be interested to talk with people who’ve deployed Qt/C++/CMake to OSX before to get a suitable build system working there as well. It shouldn’t be too hard to do, since CPack does have package targets for various OSX installers it’s just not something I’ve done before.