Planet maemo: category "feed:a93f39245539231538463d349e184dd2"

Robin Burchell
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();
}

Categories: meego
Robin Burchell

Qt: how to love and embrace being open

2010-05-06 16:03 UTC  by  Robin Burchell
0
0
It's been quite a while since the Qt code was opened up now.
Click to read 1670 more words
Categories: oss
Robin Burchell

GSOC 2010 - Facebrick

2010-05-03 22:12 UTC  by  Robin Burchell
0
0
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.
Categories: meego
Robin Burchell

Qt Unit Tests - you can help!

2010-05-03 17:28 UTC  by  Robin Burchell
0
0
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? :)
Categories: meego
Robin Burchell
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.)
Categories: meego
Robin Burchell
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.
Click to read 936 more words
Categories: meego
Robin Burchell

FaceBrick - a Facebook client for Maemo

2010-04-12 16:53 UTC  by  Robin Burchell
0
0
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. ;)
Categories: qt
Robin Burchell

Qt on Maemo: a warning

2010-04-06 15:22 UTC  by  Robin Burchell
0
0
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.
Click to read 1198 more words
Categories: qt
Robin Burchell
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.
Click to read 2314 more words
Categories: pyside
Robin Burchell
The third PySide tutorial here (part two: signals and slots available at http://blog.rburchell.com/2010/02/simple-pyside-tutorial-2-signals-and.html and part one: basic introduction/hello world: http://blog.rburchell.com/2010/01/simple-pyside-pyqt-tutorial-aimed-at.html), we're going to delve into something a little more involved and unique than the last two tutorials.
Click to read 1874 more words
Categories: pyside
Robin Burchell

Application compatibility and MeeGo

2010-02-17 11:42 UTC  by  Robin Burchell
0
0
So, as I mentioned in my previous entry (http://blog.rburchell.com/2010/02/future-of-n900-what-meego-means.html), there isn't a huge need to worry about MeeGo.

After doing some more reading around the internet, I thought I'd best address another facet of this - that of application compatibility.
A lot of people seem to be of the assumption that MeeGo will be completely incompatible with everything out there, and really, this isn't the case.
For starters, take Maemo. MeeGo has a very similar stack to Maemo. It's basically Linux. It has X, Qt and Gtk+, and all the other things you're used to. Software using it will continue to work. It might need some packaging work, but that's not a big deal, and better minds on mine will hopefully come up with ways to minimise the amount of work needed here.
For Qt applications, this will already be very minimal with tools like MADDE helping cross compilation and packaging, and one can only presume that this *will* get better. In fact, Qt if anything, as with Maemo, is *helping* application compatibility, as software written for totally different platforms is easier to get running, due to Qt doing most of the heavy lifting for just about all parts of an application (audio, video, graphics..).
Again, I'd like to appeal for some sanity and a sense of calm here. This isn't the end of things, it's the start of something *much* bigger, and we're all a part of it.
Categories: meego
Robin Burchell

Meego - RPM vs DEB debate.

2010-02-16 17:58 UTC  by  Robin Burchell
0
0
Hopefully I've helped settle a few minds with this post to meego-dev.


After a lot (and boy, do I mean a lot) of reading, writing, and
discussing the RPMvsDEB scenario ad nauseum, and a more recent
discussion, I thought it might be good to put some positive energy
into the discussion, so here goes.

I'm sorry to add yet more fuel to this fire, but hopefully this will
help douse the flames, rather than raise them higher.

RPM - Why?
----------

Full disclaimer - I am not a packaging expert, but am writing this to
try summarise what I know for the benefit of the community as a whole
so that we can all channel the energy that has been devoted into this
issue into something more productive and exciting.

I would welcome any commentry on this. Should it be seen as suitable,
perhaps it might be an idea to put something similar to this up as an
FAQ item, as this certainly has been asked frequently.

--

A lot of discussion and questions have arisen over the past few days
through the Maemo and Moblin merge into MeeGo, with a lot of it
centering around one particular issue: that of RPM vs DEB packaging.

The current state of things is as such - Moblin uses RPM, Maemo uses
DEB - but this issue is not as simple as a packaging format, it's an
entire toolset. I'd also like to very quickly and emphathetically note
that this is purely addressing RPM and DEB, not Fedora and Debian, or
yum vs apt-get, or anything like that.

Maemo's toolset, in the form of scratchbox, sbmock, autobuilder and
co) has a number of kinks which have caused all sorts of fun issues,
but at the end of the day, have worked.

Moblin's toolset has equivilents to do package building - but then, a
lot more, which is not currently available for Maemo. There are
various other tools which are needed to further aid development, such
as the image creator
(http://moblin.org/documentation/moblin-image-creator-2/using-moblin-image-creator).

With this in mind, it is clear that Moblin's toolset has a number of
more capabilities to add that will infinitely benefit development and
QA, which is definitely an advantage to MeeGo, unfortunately, some
elements within this chain do not work with RPM.

It may of course be theoretically possible to rework these tools to
work with a different format (or multiple formats), but let us take a
step back and consider how pragmatic a decision that is, when at the
end of the day, we are talking about a format - both of which bear a
lot in common.

While possible, perhaps - just perhaps - there are other more
important priorities to focus on, and a bigger picture - above the
religious warfare - to keep in mind: that while we have gained RPM, we
have also gained organisation, a solid process and great tools built
to engage the wider community.

Categories: meego