FaceBrick reached a bit of a mini-milestone today, as it recieved its first external contribution. Kamilla Bremeraunet, FaceBrick's GSOC student, submitted her first merge request adding changing of font sizes based on volume keys.

I made a number of notes where it could be improved, but all in all, it is a fairly solid piece of work.

Here's hoping it continues to move onto bigger and better things.

We've all written our own small toolkits, and the like in the past, and today I revisited my glory days: I made a button.

Actually, it was a bit more involved.

Some of you might have heard of a nifty thing called a QGraphicsScene (and friends), a fairly useful tool to allow for complex rendering/manipulating of 2D objects, animations, all the rest of the bling. It's been used for a lot of things over time, and recently I've been getting to know it in my copious "free time" over this weekend.

I decided to see how difficult it would be to create my own button inside a QGraphicsScene (yes, I know QGraphicsProxyWidget exists, but it is fairly slow, so using it isn't the best for many situations), so while I was at it, I decided to make it blend in with the rest of the widgets on my desktop too.

This is more a proof of concept than anything, but in case anyone else ever wants to write their own widgets and render them in a QGraphicsScene, here's a bit of a pointer in the right direction. ;)

#include <QApplication>
#include <QGraphicsWidget>
#include <QPainter>
#include <QStyleOptionGraphicsItem>

class AButton : public QGraphicsWidget
{
public:
    AButton()
        : QGraphicsWidget(),
        m_isPressed(false)
    {
    }
    QRectF boundingRect() const
    {
        // TODO: fetch QRectF from text() + icon() and cache
        return QRectF(0, 0, 40, 40);
    }

    void paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget = 0)
    {
        QStyleOptionButton opt;
        // TODO: QStyleOption::initFrom overload for QStyleOptionGraphicsItem would be nice
        //opt.initFrom(this);

        opt.state = (m_isPressed ? QStyle::State_Sunken : QStyle::State_Raised) | QStyle::State_Enabled;
        opt.text = text();
        opt.icon = icon();
        opt.rect = option->rect;
        opt.palette = option->palette;

        QApplication::style()->drawControl(QStyle::CE_PushButton, &opt, painter);
    }

    QString text() const
    {
        return "hi";
    }

    QPixmap icon() const
    {
        return QPixmap();
    }

    void mousePressEvent(QGraphicsSceneMouseEvent *event)
    {
        m_isPressed = true;
        update();
    }

    void mouseReleaseEvent(QGraphicsSceneMouseEvent *event)
    {
        m_isPressed = false;
        update();
    }

private:
    bool m_isPressed;
};

#include <QApplication>
#include <QGraphicsView>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    // set up scene
    QGraphicsScene scene;
    AButton button;
    scene.addItem(&button);

    // add a view
    QGraphicsView view(&scene);
    view.setRenderHint(QPainter::Antialiasing);
    view.resize(200, 100);
    view.setBackgroundBrush(QApplication::palette().background());
    view.show();

    return a.exec();
}

It's been quite a while since the Qt code was opened up now.

I've been meaning to write this up for a while, but (due to one thing and another) it's taken a little longer for me to write than I'd have liked. But, better late than never, eh? :)

This is a short note that Facebrick will have a pair of helping hands for 2010, in the form of Kamilla Bremeraunet, a keen Norwegian studying at the University of Hull, in the UK.

A brief list of what she'll be working on (possibly more, if I whip her enough!):

• A more useful replacement for the Nokia Facebook Desktop widget, which is scrollable,and links to the individual items instead of to www.facebook.com
• Inbox support: view, send and receive messages
• Change text size using the volume buttons: at the moment FaceBrick’s font size can’t be changed, and some of the users from the Maemo Community have requested a way of doing so.

I'm sure she'll be a useful help, and that you, the Maemo/MeeGo and Facebrick user community will make her feel more than welcome. You'll be hearing more about her and her intentions in the near future once she finishes up the remainder of her coursework for this semester.

Yes, they suck, we all know it. Yes, they're boring to write, and annoying when they break, and generally - the bane of every developer's existence.

But please, write them. A lot.

I've worked on a lot of projects during my life (especially if I count ones I just throw a patch at and never look at again), but one thing that often runs true is that they usually don't have enough unit tests written. This is of perhaps because they don't have enough anal-retentive people like me badgering other people to write unit tests.

Humour aside, unit testing is important, especially when you're working on a library. Bugs are natural, and will happen, but unit tests help to catch bugs (so you don't release horribly broken code), and to prevent the same bugs happening in the future, which is also quite possible.

I was wandering around Qt's code the other week, and was a bit astonished to notice just how few tests some of the base parts of Qt had (QList, QVector, etc.) Now, it's perfectly possible to argue that due to the very fundamental nature of those classes, any breakage would be caught pretty much immediately when compiling Qt itself, but I personally feel it's a lot nicer having proper tests that validate the way your API is supposed to function, *especially* when it's for something that low level and important.

So, I did something about it, and QList and QVector are now fully covered test-wise. Hoorah!

There are still plenty of other areas that could probably use some test loving, so why not check out Qt from git and lend a hand today? :)

I've had a fun weekend.

Carsten Munk, of Mer and other fame got me interested in insane schemes (once again): this time playing around with libdui (or libmeegotouch, as it is now apparently known), as we had repeatedly heard from many sources that it relied on GL, which meant that it couldn't be used with devices that require software rendering. Having found the -software flag to widgetsgallery, and poked around the source of DUI in the past, I thought this was a bit of a funny claim to make, until we actually used it and found out how horribly slow it was. Maybe they had a point?

Why was it slow? Well, it happened again. Not completely the same, of course, but this is a very similar issue to one I wrote about recently in Qt on Maemo. Something that a lot of developers, particularly ones working in higher level libraries or languages like C# or Qt forget from time to time is that image (or pixmap) scaling - in particular, smooth scaling - is generally not a fast operation.

DUI did a lot of scaling.

DUI has a class called MScalableImage, the purpose of which is to draw (and scale) a pixmap as needed, which is a good enough reason to have a class. MScalableImage is passed a pixmap, and stores it.

So far, so good.

Now, onto the details of scaling. When being asked to draw, QPainter pointer is passed, as well as an x, y, width and height. The width and height are checked against the stored pixmap's width and height, and if they match, it's drawn instantly, no questions asked.

So far, so good.

What happens, though, in the case where they don't match?

Oops.

DUI currently copies and rescales the stored pixmap to the target width/height, and then proceeds to draw as normal.

This behaviour is obviously wasteful. In the (frequent) case of GL acceleration, this doesn't really matter so much, because scaling on GL hardware - abstracted away by Qt - isn't all that slow, which is why this problem was probably not noticed previously. In the case of software rendering, though, that's a whole different story.

Patching this away to use the application-wide QPixmapCache drastically improves the performance of software rendering. My laptop isn't exactly slow, and I still ended up with a boost from an (unusable) 5-6 FPS to around 170-180 FPS.

Hopefully this post serves as an educational warning to help prevent future such mistakes.

(Oh, and the conclusion? No, DUI doesn't require GL. It helps, obviously, but it's not required.)

One thing which has increasingly become apparent to me - from wandering around some of the threads on talk.maemo.org - is that there is a very big difference between typical commercial software development, and open development.

Another great example of how open source is all about 'scratch your own itch'. I started writing code for a Facebook client on Maemo (although once MeeGo is in a more usable state with regards to UI and application development, I'll be porting it to work there as well) a week or two ago now. I finally got tired of using the Nokia Facebook widget which is totally and utterly useless (if I wanted a link to facebook on my desktop, I'd make one. Ok, it's nice being able to see status updates - but come *on*. Let me click them at least.)

So, I started writing code after having found libqfacebookconnect, using Qt. Within a day or two I had something that could read newsfeeds, and post status updates. I found a Qt on Maemo bug along the way, and spent some time digging into that, but it's progressing nicely, and seems to have been quite popular with the folks in the Maemo community.
(facebrick, pre-v0.1)



A few weeks later, and it's growing really well. I'm happy with the progress (although I have a really long list of stuff I still want to do, including replacing that useless desktop widget).

It's going to keep me busy for a fair while to get it up to scratch, but I'm having fun, and the feedback and mini-community I'm forming around this are awesome.
(facebrick, first release)


I'd also like to take a moment to thank m165 (from talk.maemo.org) amongst others for their many ideas and feedback, lcuk (for his interesting discussion), and MohammadAG (from #maemo and TMO) for his help with packaging (though I still have *a lot* to learn in that department)
(facebrick, latest release)










As (I hope) is visible, it's evolving fairly rapidly, mostly through suggestions from the die-hard early adopters I've found, but it's got a long way to go yet.

Thankfully, most of the fun of software development comes from the ride. ;)

Just a quick post to share a fairly important piece of information I found out today with the rest of the internets - hopefully this will help if someone is searching to find out why the list in their Qt application is so slow.

In the previous tutorial (http://blog.rburchell.com/2010/02/pyside-tutorial-model-view-programming.html), we covered the basics of how to create a read-only model, with multiple views presenting the data.