Quick thoughts on GOG client

I’m a fan of GOG, and of course CD Projekt (makers of The Witcher games, Cyberpunk 2077, etc). As a person who will be finishing his bachelor’s degree it would be one a heck of a goal if I were to make it to GOG team. Sadly, I don’t think I have the experience enough to meet their criteria.

Initially, when Origin client came out I noticed one thing. Origin uses Qt, and as you would assume GOG does as well. The two don’t necessarily have to share the same backend. In fact, I think GOG may be a bit different from what I had in mind. For starters, I thought GOG client would be a QML application, which it isn’t. Alright, fine, so maybe it’s a Qt project that uses WebKit, custom JavaScript injections to communicate with the C++ backend back and forth? Close, but not so much!

GOG client apparently is a hybrid composed of Qt and Chromium Embedded Framework which caught me by surprise as including WebKit would be better in the long run, maybe. How are they maintaining the calls from their the HTML5/JS frontend to C++? Well, I have a couple of ideas but nothing concrete to write a small application to provide proof. The idea however shouldn’t be far from WebKit interaction with your Qt application internals.

As far as I know the GOG client is written in AngularJS primarily with some shades of jQuery, some custom fonts (mainly Lato). I would say that when a user wants to download a game either it uses CEF or Qt Network(module). Either way, I’m having a bit of trouble understanding the need of Qt, apart of using it for configuration (settings window).

I find it intriguing that they decided to go HTML5/JS on the frontend and use C++ as the backend. It’s not that different than going full QML (well, actually QML is a whole new world itself).

Update: 08/09/2015

Oh, apparently I’ve been out of the loop as of late. I completely forgot that QtWebkit is going to be deprecated and QtScript to be removed… now all the decisions on GoG client makes sense.

Simplifying the design

Recently I got all excited on my progress with C++. Sometimes when there’s a blocker in your way and you can’t tackle it with your current knowledge then it’s time to sit, and think of a different strategy. In my case it was a case of selfishness and petty design that led me to this convoluted design in the application I’ve been working on.

I use most of what Qt offers me in terms of resources, all the classes for maximum compatibility between platforms. In this case I wanted to do this “pretty” design where everything is handled by different classes. There’s a catch, you meet “unexpected” corner cases where you just set scratching your head wondering why is it like that.

I have a class, let’s call it A:

class A : public QObject
{
    Q_OBJECT
public:
    A(QNetworkAccessManager* nam);
    ~A();
    void process();

private:
    QNetworkAccessManager* nam;
    void processFeed(FetcherReply* fetched);

public slots:
    void finished();

};

So when I put it in a Qt container

QList<A> list;
list << A(nam);

It happens that there’s a implicitly deleted copy constructor on behalf of QObject, which the documentation covers everything so far. Later on I work on a solution of just declaring the copy constructor myself and copying QNetworkAccessManager pointer to the copied class. It happens that that doesn’t go well because NAM doesn’t allow it.

Like I’ve said before, I’m really green behind the ears when it comes to these types of issue. I think part of the problem was thinking of some sort of grand design for the application when I should have aimed for a simple and flexible design rather than going Java.

C++ is undeniably full of surprises. This problem took me a while to admit defeat because I hate admitting defeat. I did learn some things to be aware of later on. Yet, I’m sad that I couldn’t break through the issue myself.

The road to become something decent is thorny as hell.

Toying with QML StackView

I didn’t have time to program today, I had to attend to some issues that’s been piling up. So, basically what I did today was part of what I’m going to do in the application I’m building. Now that I got most of the puzzle complete I have to sit down and do some design decisions in the application on how I’m going to lay everything out:

  • Communication between objects
  • How to ensure responsiveness on different displays.
  • How to organize QML files, which is by far the hardest since I’m not that familiar with QML. There seems to be no standard way to organize the files you create.

Anyway, this is what I did today:

Code:

import QtQuick 2.0
import QtQuick.Controls 1.2
import QtQuick.Dialogs 1.2


StackView {


    id: stack
    initialItem: redview

    Component {
        id: redview
        Rectangle {
            id: reddy
            width: parent.width
            height: parent.height
            color: "red"
            border.color: "black"
            border.width: 3

            Text {
                id: blah
                color: "white"
                anchors.centerIn: parent

                text: qsTr("Jump to [lightblue view]")
 
            }
               MouseArea {
                    anchors.fill: parent
                    onClicked: stack.push(lightblueview)
                }


        }

    }

    Component {
        id: lightblueview

        Rectangle {
            id: bloo
            width: 400
            height: 500
            color: "lightblue"
            Text {
                id: blah
                color: "white"

                anchors.centerIn: parent
                text: qsTr("Jump to [red view]")
            }
            MouseArea {
                anchors.fill: parent
                onClicked: stack.push(redview)
            }
        }
    }

}

StackView isn’t that bad to use. It’s incredibly easy and the more I read it seems that I’m going to have a good time using it. Hopefully things will work out on my end.

I think QMLs only difficulty right now is actually knowing the all the attributes, members of each QtQuick control, dialog, UI element. I feel it’s really overwhelming.

Working with YouCompleteMe + Vim + Clang/Cmake + Tmux

Recently I’ve had this idea of using Vim to continue development on my application. Most of the development is done in my desktop where I sit and fight wars with QtCreator. Now, there’s something I really enjoy about using YouCompleteMe is on how incredibly fast it is. The subsequence algorithm it uses is perfect (for me) as I can “lazy type” the things I want, something I can’t do in QtCreator autocomplete because it doesn’t have the same search mechanism as YCM.

Another reason is because QtCreator FakeVim isn’t that good; no matter how much I use it there’s always something lacking.

All you need to do to get this working is

  • Use CMake (… well, not really, cmake just makes it easier with CMAKE_EXPORT_COMPILE_COMMANDS to be ON either as a switch in your cmake call or as a variable in your CMakeLists.txt
  • Use clang, as far as I know it doesn’t work with GCC.
  • Have some basic knowledge of YCM extra configuration file.

It works incredibly well.

C++ Starter: Memory leaks

C++ Adventures is a section where I mostly speak of my encounters and struggle while learning the C++ language. This section by no means may contain insights of C++ as a language, or any factual content that may be used as a point of discussion. I’m just a penguin on a journey.

Yesterday I spent some time hunting a memory leak that was caused in a separate thread from the main GUI one. I noticed the memory first almost by accident I had the system monitor opened and with a quick glance I noticed my application had sucked 1.4GiB of ram by letting it poll through over 64 sites per second. That caused a collection of unmanaged QNetworkReply to pile up.

The way I got around to fix it I believe isn’t the “correct way” but it works for me. Hopefully someday someone will tell me what I was doing wrong, sadly I don’t know anyone I could befriend and chit-chat about my encounters.


void SomeClass::requestFinished(QNetworkReply* reply) {

   // process data
   reply->setParent(0); //isolate from parent
   reply->deleteLater(); // let Qt handle the rest
}

Leaving your network replies is bad. Even Qt documentation states that the developer has to deal with each reply disposal. It can get really ugly fast if you do constant polls (2-3 seconds) with QNetworkAccessManager and leave things unmanaged.

Now, another subject I wanted to talk about is memory usage and the root of all evil that is premature optimization. Don’t worry, I haven’t fell into a pit of despair after running into my first memory leak.

Lately, I’ve been pondering that on the GNOME 3 environment my application, stripped out of networking stuff I’m working on consumes 18MiB memory, but once I add the networking side it bumps to 24MiB. Where am I going with this exactly? Well, I’ve been pondering on how a person can exercise mindful techniques to not let your application use something more than 80MiB+.

Here’s the thing though, 20, 60, 80 MiB is nothing these days. For a feed reader it might look awkward. At first I felt like 25MiB seemed too much and I’m not even done with my application. Worrying about it is not something I’m constantly doing though.

My initial views on QML

My preconceived notions of technology have led me to really stupid decisions in the past. I’m a fool, a blithering fool.

With that opening I hope to at least share some thoughts on QML. My first view on QML wasn’t proper, it was all doom and gloom when I saw QML was some sort of hybrid monster coming to get you with JavaScript. And JavaScript have left me a bit bitter when it comes to debugging and organization in general, more towards debugging though. Debugging is what we do literally every day, there’s no such thing as write 300 LOCs and call it a day.

And I was led on with that thought, my dislike of JavaScript kept me away from trying QML for a while. Until I saw this introduction video.

After finishing the video there was this surge of ideas coming to me. What works? What doesn’t work? What should I try first? How to redistribute this later on? How to take care of cross-platform in a way that sucks less? Exciting times, really.

Now let me mention JavaFX for a moment before Sun Microsystem “killed it” in favor of a traditional API. QML and JavaFX shares similarities. QML, I feel, has the upper hand in some ways.


import javafx.scene.control.*;
import javafx.scene.layout.VBox;
import javafx.geometry.Insets;
 
var list = ["apples", "bananas", "oranges", "pears", "cabbage"];
 
ScrollView {
  width: 250
  height: 250
  managed: false
  node: VBox {
    padding: Insets {top: 10, left: 10, bottom: 10, right: 10}
    spacing: 10
    content: [
      PasswordBox {promptText: "enter password"}
      Separator {}
      ChoiceBox {
        items: list
      }
      ListView {
        vertical: false
        items: list
      }
    ]
  }
}

Taken from Steve On Java

That was JavaFX before it got killed. I still remember when it was first announced I got all excited because building UI applications in Java wasn’t exactly a walk in the park. It was hard and there wasn’t a “best practice” guides to keep me informed on how to manage each guide and how to see each object. I feel like Qt documentation explains Qt Widgets UI elements way better than other UI toolkits I’ve used, which isn’t many by the way.

But, in a way JavaFX script shouldn’t have died.

On the other hand we have this beast the Qt Team developed. A scripting language that could communicate using JavaScript, QML, and C++ and the things it does blows my mind.

So, my initial views on that were; “My God, it’s going to be hell communicating with the C++ backend”. It turned out to be a not so bad experience. You could even expose C++ classes to the QML and register them, and even protect some of the methods you didn’t want to share.

Most importantly, the ability to make your application support scripting. Bringing a whole set of APIs in your core C++ application and expose it to JavaScript sounds like I’ve won a trip to Disney land with all expenses paid.

Wrapping it up, I’m hoping to cook something good for QML and I’m really looking forward to see what I can do!