technical

New incarnation of mimec.org

Submitted by mimec on 2017-11-19

Today is the beginning of a new chapter in the history of the mimec.org website, which I created almost twelve years ago, and the related websites dedicated to my open source projects. I moved these sites to a new server, but I also completely redesigned them and migrated them to the latest version of Drupal. I actually built them completely from scratch and imported the old content using some hand-crafted tools, so the whole conversion took about six weeks of work. I hope that you like the result.

If you look closely at my blog, you will notice that there hasn’t been much going on recently. I mainly focused on Bulletcode, the company which I founded three years ago with my friends. We had a lot of ups and downs, but the important thing is that we created a few projects that help thousands of people. Even though it was always just a side project for us, it was definitely one of the greatest experiences in our lives. Each of us moved on to different projects, but we’re still a great team and when the time comes, we may work on something new again.

Personally, the last few years were very hard for me, so the company was one of the things that kept me alive. But now I’m ready to begin a new chapter in my life, start building a new relationship and become the person who I really want to be. I’m more aware of myself. I rediscovered many things that I lost along the way, things that inspire me and drive me to become better at what I do. I am grateful for what I have and I look into the future with optimism and curiosity.

So what are my plans now? A few months ago, I started working on a new, experimental version of WebIssues, with a new user interface based on Vue.js. Those of you who follow me on Twitter could already see some screenshots of that prototype. I also wrote a series of articles on Medium dedicated to programming in Vue.js and to my great surprise, they were very well received. I found a way to create the new version of WebIssues with as little effort as possible. However, I felt that this wasn’t the right approach, so I decided to take a step back and rethink this.

The truth is that it took me many years to learn PHP and C++ before WebIssues could become what it is today. Now I must gain a similar level of skills with the new technologies, even if it takes a similar amount of time. I also want to make a really good use of them instead of just doing a simple face lifting. So instead of rushing toward releasing a new version, I’m going to keep experimenting until I’m satisfied with the results. Of course, I will continue to write about new things that I learn along the way on Medium. I will also share my progress in this blog.

I’m very excited about this new plan, because I think that personal development and improving our skills is the best thing that we can do in our lives. Especially if they allow us to do something both creative and useful. With that goal in mind, I’m sure that the next months and years will be an amazing time.

Happy 10th anniversary, mimec.org!

Submitted by mimec on 2015-12-15

Today is a very special day. Excactly ten years ago, on December 15th 2005, I wrote the first post on the mimec.org website. It's become a tradition that I write a short summary of the past year on each anniversary, and I will do it again today, because it was also a very special year for me.

First of all, there were a lot of round anniversaries this year. Almost exactly 10 years ago I graduated from college. WebIssues turned 10 years old in November, although technically it wasn't officially released until September 2006. Fraqtive turned 10 years old in January. And in March it was 10 years since I started my first job - and after those 10 years I still work for the same company, although it grew in size from a few developers to a few hundred, changed its name and relocated its headquarters. Even my primary day job project is still the same after 10 years. So, looking at those numbers, one might think that my life is very stagnant, and I will most likely spend the rest of it in the same place, doing the same things…

But even though a lot of things remained the same for such a long time, the last year also brought a lot of substantial changes. I overcame a serious crisis in my family, and we are back together, although a year ago nothing indicated that this would ever be possible. I think that this is my greatest personal accomplishment, and I simply owed this to my son. Obviously it doesn't mean that it's all a bed of roses now, quite on the contrary, but it was a very valuable lesson for all of us, and I will definitely not let the most important things get out of control again.

Today is also the first anniversary of Bulletcode, a software company founded by me and two of my friends. At the moment it's still more of a hobby than a real business, we put more money into it than we make, and we try to put as much work into it as our day jobs allow. But the whole year was a huge, invaluable experience for us all. We started the company to work on a very promising project, which unfortunately failed miserably for reasons that were beyond our control. So we ended up with a company which generated costs, without any projects, with no business partners, and with no idea what to do next. But instead of shutting it down, we took the challenge and started looking for new ideas and opportunities. I cannot reveal yet what we are working on, it's all a bit of a mistery and conspiracy, but it's definitely the most interesting project I've ever participated in, and we're all waiting impatiently to release our first product.

Model-View-Presenter in QtQuick pt. 2

Submitted by mimec on 2015-06-03

In the previous article I explained the basics of a simple Model-View-Presenter architecture in QtQuick. Now it's time to explain the implementation details. I will start with the Presenter QML component which is the base component of all presenters:

FocusScope {
    id: root

    property Item view
    property QtObject model

    property var modelToViewBindings: []
    property var viewToModelBindings: []

    Component.onCompleted: {
        root.view.anchors.fill = root;
        root.view.focus = true;

        for ( i in root.modelToViewBindings ) {
            name = root.modelToViewBindings[ i ];
            dynamicBinding.createObject( root, {
                target: root.view, property: name, source: root.model, sourceProperty: name
            } );
        }

        for ( var i in root.viewToModelBindings ) {
            var name = root.viewToModelBindings[ i ];
            dynamicBinding.createObject( root, {
                target: root.model, property: name, source: root.view, sourceProperty: name
            } );
        }
    }

    Component {
        id: dynamicBinding

        Binding {
            id: binding

            property var source
            property string sourceProperty

            value: binding.source[ binding.sourceProperty ]
        }
    }
}

As you can see, the presenter is a FocusScope, so that it can be used as a top-level visual component of a window or can be embedded in some more complex layout. The presenter contains a view property which holds a reference to the embedded view component and a model property which holds a reference to the model object. The Component.onCompleted function makes sure that the view fills the entire presenter and that it has keyboard focus enabled.

The remaining code is related to binding properties between the model and the view and vice versa in a simplified way. The modelToViewBindings property contains an array of names of properties that should be bound from the model to the view. The first loop in the Component.onCompleted function creates a Binding object for each property binding. The target of the binding is a property of the view. The value of that property is bound to the corresponding source property in the model. Note that JavaScript makes it possible to access a property of an object with a given name using the [] operator, because an object is essentially an associative array. The binding from the view to the model works in exactly the same way. As demonstrated in the example in the previous article, it's even possible to create bi-directional bindings.

The view and model objects are created in the actual presenter component which inherits Presenter. As I explained in the previous article, we want to be able to switch both the view and the model as easily as possible. In order to do that, I implemented a simple factory, which is basically a shared library implemented in JavaScript:

.pragma library

var config = {
    modules: {},
    urls: { views: "views/", models: "models/" }
};

function createObject( type, name, parent ) {
    var module = config.modules[ type ];
    if ( module !== undefined ) {
        var qml = "import " + module + "; " + name + " {}";
        return Qt.createQmlObject( qml, parent );
    } else {
        var url = config.urls[ type ];
        if ( url !== undefined ) {
            var component = Qt.createComponent( url + name + ".qml", parent );
            var object = component.createObject( parent );
            if ( object === null )
                console.log( "Could not create " + name + ":\n" + component.errorString() );
            return object;
        } else {
            console.log( "Factory is not configured for " + type );
            return null;
        }
    }
}

function createView( name, parent ) {
    return createObject( "views", name, parent );
}

function createModel( name, parent ) {
    return createObject( "models", name, parent );
}

The config variable specifies the names of C++ modules and/or URLs of directories that contain QML files with the implementation of views and models. By default, the models can be simple mock-ups written in QML, which makes it possible to run the whole application directly using the qmlscene tool without writing a single line of code in C++.

The createObject() function first looks for a registered C++ module of the given type. If present, it creates a simple component declaration in QML and calls Qt.createQmlObject() to create the instance of the component. When there is no C++ module registered, the function tries to load the component from the QML file in the given location. The createView() and createModel() functions are wrappers that can be used for simplicity.

By changing the default configuration of the factory at run-time, you can not only switch between mock-up models and real models implemented in C++, but also, for example, to use different views in mobile and desktop versions of the application. For example, the Component.onCompleted function of your top-level QML component could contain the following code to override the default configuration:

if ( typeof models !== 'undefined' )
    Factory.config.modules.models = models;

The C++ application can register the classes which implement the models in a module and pass the name of that module to the QML engine as a property of the root context, like this:

qmlEngine->rootContext()->setContextProperty( "models", "MyApp.Models 1.0" );

Unfortunately, it's not possible to pass variables from C++ code directly to shared JavaScript libraries which use the ".pragma library" directive (according to this thread, this is done this way on purpose). The method shown above can be used to work around this limitation; just keep in mind that the factory needs to be configured before any objects are actually created.

Model-View-Presenter in QtQuick

Submitted by mimec on 2015-05-19

One of the advantages of using QtQuick is that it's possible to fully separate the user interface from application logic. Not only there are separate classes or components, but even the programming language used in both layers is completely different. The user interface can be written (or designed) using QML, a declarative and highly expressive language created strictly for the purpose of developing modern UI. The application logic on the other hand can be written in C++, which is powerful, abstract and yet exceptionally fast. Such approach has many advantages over writing the UI directly in C++, because with all it's strengths, it's not well suited for UI development. One of these advantages is that you can have two separate teams in the project, and the UI team doesn't need to know C++, and the application logic team doesn't need to know QML.

But wait, eventually these two layers have to be integrated somehow, right? There are several possibilities of doing such integration, and at first they seem quite complex, which defeats the purpose of simplifying the development process. The Qt tutorials and documentation don't give a lot of help. They only mention a general rule of thumb that you should never directly access or manipulate QML objects from C++ code, although the API certainly makes this possible. The whole idea is that the QML code should create and use objects implemented in C++ to perform various operations. But then if a QML button directly invokes some method implemented in C++, this has nothing to do with decoupling the application logic from the UI.

The solution to this problem is well known and it can also be successfully applied to QML and C++. The idea is to introduce another layer of abstraction between the application logic (the model) and the UI (the view). There are several variants of such architecture, the most common ones are Model-View-Presenter and Model-View-Controller. The differences are quite subtle and I'm not going to dig into the details. They mostly have to do with the lifetime and control flow between these layers. Generally MVC is commonly used in web applications, and MVP is often used in desktop applications, but this doesn't always have to be true. My goal wasn't to strictly follow any particular approach, but to find one that is best suited to solve the given problem, which is what design patterns are all about.

My implementation of the Model-View-Presenter architecture in QtQuick is based on the following assumptions:

  • A view is a visual QML component which defines the look of the application and has no logic (except for basic validation). It can be anything from a single ListView to a complex form with lots of different controls. The view should have some signals that correspond to user actions (for example indicating that a button was clicked). It also may have some properties that can be used for passing data to the view (for example to change the text of some label) and from the view (for example to retrieve text entered by the user). It doesn't require or directly use any components related to application logic, so a view can be created and tested independently from the other two layers.
  • A model is a C++ class that implements some aspect of the application logic. It typically has a number of methods that perform some operations. It may also have signals, which are useful to indicate that an asynchronous operation has completed. Properties can be used to pass data to and from the model, for example parameters and results of an operation. The model doesn't know anything about any visual components of the application. It can be created independently from the other two layers, which is useful for unit testing, automation, etc.
  • A presenter is what glues the view and model together. It's a visual component written in QML, but its only visible content is the view that's embedded in it. The presenter also creates the model object. Then it connects appropriate signals and slots from the view and the model and bind their properties. These connections and bindings can include additional logic, but it's best to design the interface of the view and model in such way that they can work directly together. In that case the presenter's only job is to create and set up these two objects and the overhead of having the third layer between the UI and the application logic is very small.

The MVP architecture makes it possible for the views and models to be created and tested independently, by two different teams, as long as their interfaces (signals, slots and properties) are designed in a compatible way. Another advantage of such approach is that it makes prototyping really easy. Designing a good user interface is a difficult craft and often the best solution is to quickly build and test different variants and prototypes. But the prototype often needs to demonstrate not only the appearance, but also the behavior of the application, so it's very useful to have some mock-up of application logic. This can be done by writing mock-up models which simply pretend to perform complex operations by returning fixed or random data. Such mock-up models can even be created in QML, which makes it possible to run and test the entire prototype without writing a single line of C++ code!

I will write more about writing mock-up models and switching between mock-ups and real models in the next article. For now let's assume that a model is a simple C++ class which inherits QObject and a view is a simple QML component which inherits Item or one of its sub-classes. The key and most interesting part of this architecture is obviously the presenter, so let's take a look at an example:

Presenter {
    id: root

    signal showMainWindow()

    view: Factory.createView( "LoginView", root )
    model: Factory.createModel( "LoginModel", root )

    modelToViewBindings: [ "login", "error" ]
    viewToModelBindings: [ "login", "password" ]

    Connections {
        target: root.view
        onLoginClicked: { root.view.disableView(); root.model.beginLogin(); }
    }

    Connections {
        target: root.model
        onLoginSucceeded: { root.showMainWindow(); }
        onLoginFailed: { root.view.enableView(); }
    }
}

As you can see, this component inherits the Presenter class. I will show you the implementation of that class in the next article, but for now let's skip the technical details and take a look at how the actual presenter is implemented, in this case a simple login window.

The showMainWindow() signal is used to communicate to some higher level object (for example the application object) that it should display the main window of the application containing an appropriate presenter. In real life applications there will often be multiple views that can be switched or even displayed side by side, and multiple models that provide functionality for these views. The application will never interact with these views and models directly but rather will create appropriate presenters to handle them.

The view and model properties contain references to the view and model objects which are owned by the presenter. These objects are created using a helper Factory class, which makes it possible to dynamically switch between mock-up models implemented in QML and real models implemented in C++, or for example between views designed for mobile and desktop version of the same application. I will write more about the factory in the next article.

The modelToViewBindings and viewToModelBindings properties make it easy to bind properties of the same name and type between the model and the view. Again, I will present the underlying implementation in the next article, but generally the idea is to create a number of Binding components dynamically using a very simple syntax. Obviously in more complex cases it's possible to set up the bindings manually. The bindings can be unidirectional or bidirectional, like in case of the "login" property. For example, the model can remember and initialize the view with the last used login, and the view can pass the new login entered by the user back to the model.

The last part of the presenter handles signals from both the view and the model. In most cases, the signals from the model are passed directly to slots in the view and vice versa, but they can also be connected to a signal in the presenter itself or can contain more complex logic. In this simple example, when the login button is clicked, the view becomes inactive (with some visual hint like a busy indicator) and the model begins processing the login request asynchronously (for example by contacting a server or database). When login completes successfully, the showMainWindow() signal is emitted to the parent of the presenter, and in case of an error the view is activated again and some error message is displayed through the "error" property. This is obviously a very simplified example, but it represents what might happen in a typical modern application.

You can find the next articles of this series here.

Render loops and timers in QtQuick

Submitted by mimec on 2015-04-02

Recently I was testing one of my Qt Quick applications on a virtual machine and I noticed that the busy indicator which is displayed at startup was spinning much faster than it should. I quickly found the reason of the problem: QTBUG-42699. Luckily, there is a simple workaround. You just have to put the following lines near the top of your main() function:

#ifdef Q_OS_WIN
    qputenv( "QSG_RENDER_LOOP", "basic" );
#endif

So what the hell is a render loop? All you should ever need to know is that it's something that makes your Qt Quick application work. This article mentions two types of render loops: threaded and non-threaded, but in reality there are three types: threaded, basic and windows. I have no idea what is the difference between the basic one and the windows one (they are both non-threaded), and why the third type is called "windows". It's definitely not specific to the Windows platform, except that it's used on Windows by default. However, I also noticed that switching to the "threaded" render loop made the busy indicator… spin even faster, so I decided to dig a bit deeper into this problem.

I took the sample project attached to QTBUG-42699 and added a third button which enables or disables a BusyIndicator control placed in the main window. The results are quite strange:

  • On the physical machine (with Windows 8) with the "windows" render loop, the problem occurs when only the custom animation is enabled.
  • On the virtual machine (with Windows 7 running on VirtualBox) with the "windows" render loop, the problem occurs when the custom animation and/or the BusyIndicator is enabled.
  • On the same virtual machine with the "threaded" render loop, the custom animation works fine, but the SequentialAnimation and the BusyIndicator are broken.

In other words, only the "basic" render loop seems to work reliably, and both the "windows" and the "threaded" ones cause various problems depending both on the environment and the types of timers that are used by the application. It's definitely not a good sign that bugs like that not only slip into an official release of Qt, but also remain unresolved for months. The busy indicator is just a relatively harmless example, but just imagine what happens if all the objects in your game start moving three times too fast. Apparently there are plans to use the threaded render loop by default on Windows in Qt 5.5, and I hope that it will eventually be fixed before that version is released.

The important lesson is that if I didn't test my application in multiple environments, I wouldn't even discover this problem, because the busy indicator seems to work fine on the machine that I use for development. I realize that making such complex thing as Qt work reliably on so many different plaftorms and configurations must be very hard, but that's exactly one of the main reasons why developers use a toolkit like Qt!