A glance at Monodevelop

Monodevelop has grown to something really beautiful, at least what I’ve used is less buggy than the previous version where it wouldn’t even add a reference properly, and by properly I mean actually include it in the autocomplete, do the whole reflection of the classes I’m working on, etc.

snapshot1

I’m no C# developer, don’t even ask me about Gtk; usually I try to stay away from it. I find Qt to be a better toolkit, of course that’s my opinion. Anyway, let’s go back to the not being a C# developer. Well, as you see in the screenshot I toyed with Gtk containers, which by they way they are incredibly straightforward to use–added some widget elements to my little app, even a Pixbuf to show my love for wrestling.

All in all? I love it. I would love to do something serious with C#/Gtk/Monodevelop in the future. I feel like I can actually work with it now.

C# has always had that elegant feeling into it, like something Java developers would crave for. winks We’ll see how things go from here, so far I’m going full force with C++ and I’m not planning to drop it. I did, however, took a little break because I needed to cooldown and see an issue with fresh eyes, such is the nature of threading, and by no means I’m doing something complex.

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!

C++ Starter: I’m still awful

The most awful thing you can do is mistake C or C++ as your typical high-level language where’s everything is managed for you. Sometimes the hours spent in figuring things out can be incredibly rewarding and every little breakthrough I make, while not remarkable in comparison to other people who have been in the grind for far too long; means something to me.

I spent too much time beating around the single question of “when to use references” and “when to use pointers” after I was bit on a really simple problem.

It turns out that my naive thought of passing by reference was okay. Which backfired almost instantly as I needed to pass the whole pointer else the API wouldn’t work correctly. In this case I’m talking about QNetworkAccessManager. I’ll admit I’m still wet behind the ears, even though I get most of the basic concepts things like pointers and references always leaves me scratching my head for a while because I’m not used to care about the lifetime of an object. I think the biggest doubt I have is “why couldn’t I convert the reference back to a pointer as it was before”. Which I tried, but… the errors the compiler threw were alien to me, for now.

Discovery requires experimentation, I’m afraid. I guess this fool here will eventually find an answer to my question, eventually.

And that’s the gist of it. In languages like C or C++ you have to care about the lifetime of objects. A garbage collector won’t be looking out for you if you leave an object be.

I’m okay with struggling; I will keep pushing forward as always. The learning process in this one has been challenging so far; I’m just glad that I keep winning the small battles. Maybe in six months I’ll win the war, who knows?

C++ Starter: A new road ahead

I’m spent. Pretty much all day I’ve worked to migrate from Ghost blogging platform to WordPress, and you know what? It was worth doing it. I’ve learned from mistakes, really stupid mistakes I’ve come to realize later on. And yet, I still have energy to talk about something I’ve been building for a few weeks now.

Maintaining interest in a project is really hard, heck, I have an stalled project called Lafarel because I gave up on the belief that it was going to be useful. The concept was weird after all, maybe if I start working out the kinks of what made it stall in the first place.

As of this month I’m working on a software application called FeedPal. While the screenshot contains nothing, a lot has been done internally!

FeedPal

You guessed right, it’s yet another feed reader application that will come into play. I’ve been pouring over 3-4 hours a day(maybe even more than that) on QT5 documentation, C++ references, and a lots of brainstorming to provide a solid experience of how articles should be presented to the user.

A few key features I’ve been polishing

  • OpenSearch integration
  • Exporting articles to (PDF, ODT)
  • Visual presentation
  • and other features that for now I’ll keep quiet

Why C++? It’s a feed reader for pete’s sake! You could have done that in Ruby language implemented on NodeJS running on the JVM!

If you haven’t come to realize I’ve been pushing forward to learn C++ for quite a while. I’ve been looking for open source projects to participate, yet I keep going back to square one.

After moving away from Ghost I’ve come to realize something very important is that there’s always a market for everything. A feed reader may very well be dime in dozen, yet we can’t predict the future on how the community embrace it. It could be the next top application, or maybe not.

I believe that developers shouldn’t be too opposed to build software that already exist, sometimes you can polish the wheel even better. Yet, there’s a strong opposing view that people shouldn’t reinvent the wheel.

There’s always room for improvement.

The quickest way (at the moment) of importing your Ghost blog to WordPress

To commemorate my sudden switch to WordPress I’ll give you a small hint on how to get your data exported rapidly through RSS.

All you need to do is open is edit [GHOST FOLDER]/core/server/models/post.js look for the text // Set default settings for options, you will see the limit is set to 15, alter that to “900000”.

Restart ghost server, go to your site http://mysite.com/feed and save as the feed. You will notice all your posts are there.

There’s a gotcha: No images will be imported (of course, this is a RSS file after all) and no tags will be imported (sounds fishy on behalf of RSS importer, maybe a bug). As to why I did it… well, let’s say I wasn’t satisfied with Ghost and its dashboard leaves more to be desired. I wasn’t planning to spend the next hours writing an importer because honestly I don’t have many posts, and the hours spent wasn’t going to cut it either.