Posted tagged ‘MIME’

Thoughts on Process Invocation with Qt and PoCo

June 9, 2011

Since late 2010, I’ve enjoyed developing C++-based applications with the Qt framework. Overall, I find it to be intuitive, fairly well-designed, and well-documented.

However, one area of the framework that I’ve found unsatisfactory (or at least struggled with, despite my best efforts) is the QProcess class. Ideally, I’d like to be able to instantiate it once, on a per-method (or per-class) basis with the appropriate executable path and CLI arguments, and then dump its output directly into a QString for use elsewhere.

I vaguely recall successfully resolving ~90% of the problem in Stroma (although that project’s architecture is currently rather monolithic) – but I never managed to solve the rest of it (actually dumping the output of the invoked process into a QString/multi-line text box widget).

After taking a break from that project for a while, I found myself encountering a similar problem in another project; and after reading various forum/mailing list posts and pieces of documentation, sought to find alternative means of resolution.

The most promising initial candidate was Boost::Process, although it appears that development is still ongoing – therefore, it isn’t an “official” Boost component yet.

With that I mind, I decided to install and investigate Poco::Process, after seeing a mention of it on StackOverflow, last night.

Installation under Fedora was trivial (involved running “sudo yum -y install poco-devel poco-doc” from a shell), and the appropriate header files were conveniently located in /usr/include/Poco for later perusal.

That said, I was sceptical about the quality and usability of the PoCo library itself, since the documentation and sample code felt relatively terse and incomplete; not to mention that guesswork (aided by this post) was necessary, when it came to actually integrating it into the build system.

However, once those hurdles are dealt with, basic integration with the Qt project build system simply involves appending the following to the project file:

#Headers for PoCo
HEADERS += /usr/include/Poco/Pipe.h /usr/include/Poco/Process.h \
/usr/include/Poco/PipeStream.h \

#Libraries for PoCo
LIBS += -lPocoFoundation

Once the project file is configured, adding the following to your class header file (modulo existing references, of course) should work :

#include <QApplication>
#include <QString>
#include <QDebug>

#include <string>
#include <cstring>
#include <cstdio>
#include <iostream>
#include <Poco/Process.h>
#include <Poco/Pipe.h>
#include <Poco/PipeStream.h>
#include <Poco/StreamCopier.h>

using namespace Poco;
using Poco::Process;
using Poco::Pipe;
using Poco::PipeInputStream;
using Poco::PipeOutputStream;
using Poco::ProcessHandle;

Some of the aforementioned header files are unnecessary – although their presence doesn’t seem to cause any obvious problems at compilation or application execution time.

My method in question (a rather rudimentary/brute-force mechanism for returning the MIME type of a file as a QString object, based upon sample code from a presentation slide), looks like: 
QString FileTypeHandler::GetMimeType(QString aFileName) {

    qDebug() << "Inside FileTypeHandler::GetMimeType";
    qDebug() << "Have text: " << aFileName;

    std::string mimeCommand("/usr/bin/file");
    std::vector<std::string> mimeArgs;
    Poco::Pipe mimeOutput;
    ProcessHandle mimeHandle = Process::launch(mimeCommand, mimeArgs, 0, &mimeOutput, 0);
    Poco::PipeInputStream mimeInput(mimeOutput);

    std::string mimeData;

    mimeInput >> mimeData;

    qDebug() << QString::fromStdString(mimeData);

    return QString::fromStdString(mimeData);


Theoretically/in essence, it accepts a file name as its argument, invokes the file -i command to (hopefully) look up its MIME type, stores it in a standard ANSI C++ string, and finally returns it as a QString for consumption by UI widgets.

In reality, it pretty much does just that – with the caveat that it doesn’t quite return the correct output. (It returns “/dev/null:” instead of “/dev/null: application/x-character-device; charset=binary“, for example).

Still, I hope that these notes are useful for others who are facing the same problem…

Maybe others can chime in with a better alternative, or other suggestions?

Does Anyone Know Noddy?

March 8, 2010

Not too long after the folks at the Symbian Foundation announced the release of the complete Symbian Platform codebase (or at least the parts that weren’t already open), I performed some of the searches that I typically perform on a newly-opened large codebase.

Some of the criteria that I searched for included:

  • References to suppliers and competing organisations (e.g. Sony Ericsson, NTT DoCoMo, Apple and Microsoft)
  • References to previous names of organisations (e.g. Psion and Symbian Software Ltd.)
  • References to project/product internal/code-names (e.g. UIKON, AVKON, Crystal and Quartz)
  • References to cancelled or previous project/product names, especially within a given context (e.g. “EPOC is“- which will locate a prehistoric marketing document extolling the virtues of the old EPOC32 platform that is a progenitor of the current Symbian Platform)
  • References to projects/products that are related to, or derived from the codebase in some way (e.g. MOAP(S), Series 80 and UIQ)
  • The terms “confidential” and/or “proprietary” in various combinations

…and just for kicks – profanity and intra-cultural references.

Which leads on to a little mystery:

Just what is the significance of the Noddy references? (Most of which are enshrined in MIME test case sample files, and are made by folks with a connection to Psion).

According to a friend/contact at the Foundation, “Noddy wasn’t originally a cartoon character” – which makes sense, if a cursory glance at a Wikipedia disambiguation page; and passing familiarity with plush nodding dog ornaments in car windows is anything to go by.

Still, that doesn’t really explain who or what Noddy is in this context; or why Noddy was seemingly disliked by the folks involved in compiling the aforementioned test case files.