qt

Razor-qt 0.4 - Qt based Desktop Environment

Michael Reed — Mon, 30 Jan 2012 16:49:52 +0000

Razor-qt is a new desktop environment based on the QT toolkit. I installed it from the PPA and gave it a quick go. It’s early days for the project, but it might eventually become a refuge for lovers of KDE 3 in the same way that Xfce has become popular with people who want to recreate the Gnome 2.x experience.

The website declares that the project already has enough finished and working components to be considered a desktop environment. So far they have a desktop, a panel, application launcher menu and pop-up, desktop widgets, a settings manager and a session manager. The panel is pretty standard fare, featuring the usual application menu, quick launch taskbar, clock and status area, all of which are implemented as configurable plugins. The panel is drag and drop enabled, allowing for easy additions to the quick-launch bar. Two functional desktop widgets, a clock and a folder viewer, ship with the current version.

The application launcher. It's nothing to write home about but it gets the job done and it's drag and drop enabled.

Razor-QT doesn’t aim to be a window manager. On my Xubuntu netbook it defaulted to Openbox, and on an Ubuntu box it used Metacity. It looked pretty much identical in both cases. Before you ask, yes, Kwin, the KDE4 WM, can be used, giving the KDE4 window decorations but without the Plasma desktop.

Editing the widget layout.

It’s worth noting that nowhere on the website does it actually say that recreating KDE3 is an goal of the Razor-QT project. However, lots of commentators are clamoring for it to take on such a role, and as a QT based desktop environment, it does seem like a fairly good fit. However, apart from a few small utilities, it doesn’t have anything to offer in the way of original applications, and applications are half of what has always made KDE so great. Perhaps, if they really do want to recreate KDE 3, they could hijack some of the KDE 3 era apps or adopt other ones. For example, it doesn't come with an email client or a file manager at the moment. If you installed the current version of KMail, you'd end up bringing along all of the Akonadi and Nepomuk baggage that has turned a sizable contingent of former KDE users away. In same way, you could add Konqueror as a file manager, but the KDE 4 version of Konqueror isn't quite the same as the KDE 3 version that we all loved.

Go to Full Article

Qt and Layouts

Johan Thelin — Thu, 02 Sep 2010 14:21:47 +0000

by Johan Thelin

When I first started with graphics - I plotted pixels onto the screen by calculating a memory address and then poking the corresponding value. Times have changed since then. My murky history contains gwbasic, STOS, HiSoft Basic (compiled!), VisualBasic (numerous versions) until I found C and AES (on the Atari ST), Win16 (that is Windows 3.1) and even Presentation Manager on OS/2 (in the pre-Warp days).

Finding myself at university, I ran in to the Tru64 platform. That means Alphas and a Unix dialect that wasn't really compatible with anything that I knew. I dabbled with xlib and GTK but then some friends of mine and I set out to build KDE (the school provided FVWM). That meant building Qt along with loads of other stuff. This was a time when 64-bits was exotic - and guess what Tru64 runs on.

If our hands weren't full from just building the project, we also had to build it on a temporary drive as our accounts where too limited. That meant keeping the build times short enough to avoid the rm -rf that was run on the temporary area every night by sysop. We also had to place parts of the binaries in web directories and use symbolic links to get them into the tree spread over our home directories (there were some heated discussions when they realized what we did). The lesson for the sysop was to run quota on all disks - not just the /home tree...

Enough nostalgia, and on towards the point. Through all my previous experiences, graphics were placed at a specific pixel location. Usually relative to the upper left corner (i.e. base address of the framebuffer memory) or to the upper left corner of the current parent widget (i.e. inside a window). Windows complicated this by using dialog units, i.e. basing the locations on the font size.

Building Qt meant trying to use Qt, and this moved me beyond fixed pixel locations. I'm not claiming Qt was first, nor is best at this. As all great ideas, this must have been inspired from somewhere. In Qt (and GTK+ and most other modern toolkits) widgets (controls, elements, call them what you like) are placed in "layouts" and that is pure genious. By letting widgets hint about what size they want and then provide size policies, the layouts let the widgets negotiate for space.

Let's take an example. The very simple dialog shown at the start of this article consists of three widgets: a text editor (QLineEdit), a button (QPushButton) and a list widget (QListWidget). All of them are placed in a grid layout (QGridLayout) with the list spanning two columns.

Go to Full Article

Using qDebug

Johan Thelin — Thu, 15 Jul 2010 14:00:00 +0000

by Johan Thelin

GUI debuggers are the norm these days, however, I still feel the urge to do a little printf-debugging now and then. It might be wrong, it might be silly but it works.

I like to develop the odd graphical application and I like use Qt. For Qt, the nice Norwegian Trolls have provided the qDebug function. You can use it right away just like your old trusted printf:

if(complexStatement(x))
{
    qDebug("This code executes when x = %d", x);
    ...

This works great for integers and other basic types. But, take the fairly common class QColor. Your first thought would probably be to write out each component manually:

qDebug("Color is: %x, %x, %x",
       color.red(),
       color.green(),
       color.blue());

This can be rather tedious, and there are types which are complex to print. For instance, QString, stores unicode strings and uses implicit sharing to reduce copying overhead. This gives you quick internationalized applications, but you cannot easily print the thing. To the rescue: qPrintable.

qDebug("A string: %s", qPrintable(myString));

The qPrintable macro is handy, but you also need to be aware of its quirks. The returned const char pointer is only valid for that very call. I.e. you cannot store it and re-use it - that will most likely give you garbage output.

// Do not do this
const char *text = qPrintable(myString);
// ...
doSomething(text);

For those who refer to printf debugging as cout debugging, and those who like to have a more convenient API, I recommend including the QtDebug header. This way, you can stream most of Qt's types to qDebug. This means a more convenient API for when you need to print QColor values, etc:

qDebug() << color;

Printing using qDebug usually results in console output (you might have to add CONFIG += console to your project file to get output at all on some platforms). However, you can also install a message handler to present your messages in a GUI window, translate them, paint them in colors or just put them in a log file.

Go to Full Article

The Qt Virtual Framebuffer

Johan Thelin — Wed, 12 May 2010 20:18:43 +0000

by Johan Thelin

Qt comes with a handy tool that lives a rather anonymous life in the tools/qvfb directory. This tool does wonders when it comes to demoing, training users and creating documentation.

The QVFb, or Qt Virtual Framebuffer, is a tool that makes it possible to run Qt applications on a virtual system with a limited screen resolution, limited bit-depth, and with limited input abilities. All of this on your desktop (or laptop) PC, saving you the hazzles of cross-platform debugging, cross-compiling, transfering files to the target, etc.

The trick with the QVFb is not really how to use it, but rather, how to build it. It is interesting enough that I've actually given a number of speeches on it. The problem is not that it is difficult to build, rather, that you have to build Qt two times to get a working environment.

When building Qt, the result of the configure script is a binary: qmake. This binary processes *.pro files and builds target specific Makefiles. The qmake tool carries your configuration, so if you are targetting two systems with your Qt project, you will have to run "make distclean" followed by "qmake-target" to aim your project at a specific target (where "qmake-target" can be "qmake-x11", "qmake-osx", "qmake-arm-fb", etc).

With this knowledge, and some careful thought when configuring Qt (do not forget to use the -prefix option to avoid having three Qt installs in one directory), building QVFb is quite easy.

I usually build three instances of Qt when targeting an embedded system - all with roughly the same configuration. This is to make sure that what I test on my PC also works on my target. The Qt builds are:

Qt for host/X11 - used to build the Qt tools for the host machine.
Qt for target/fb - used to build the actual target files.
Qt for host/qvfb - used to build binaries for QVFb.

Qt for host/X11 is simple, just build Qt as you usually do. However, when you have built it, cd into tools/qvfb and do "make && make install" for QVFb as well.

Qt for target/fb can be a completely different story. It's usually dead simple to build Qt for your target. However, as we all know, the devil lives in the details. This build can be tuned in so many ways that this is one of the things I do for a living.

Qt for host/qvfb is basically Qt for target/fb, but for the host machine. I also make sure to include graphics and input drivers for QVFb. This means adding -qt-gfx-qvfb, -qt-kbd-qvfb and -qt-mouse-qvfb to the configure command line.

Go to Full Article