The daily ramblings …

QT : Signals and Slots Mechanism

Posted in QT by akamal on January 16, 2007

One great feature installed inside Qt is the signal and slot mechanism. It’s specially developed for event driven software approach, where no single use case dictates the flow of the software. This feature indeed is central to the whole of Qt concept, which probably made it different to other frameworks.

Signals and slots primarily allows communications between objects. Just like in any other GUI programming, when we change / execute a widget, we often want another widget to be notified. Beneath the concept, we want the objects to ba able to communicate with one another.

e.g:
When a user clicks the close pushbutton, we’d probably want the mainWindow to close, by calling a close()
function.

Now, for most frameworks, (wxwidget, fltk, win32) the only way to achieve this is to use callbacks, basically a pointer to functions. Based from my experience, callbacks inherits 2 fundamental flaws, firstly they are not type safe, meaning that we can never be certain whether the processing function
will call the callback with correct arguments.

Secondly, a callback is strongly linked to the calling function since the processing function must know which callback to call. In large software development, things can go complex when there’s too many callbacks to call.

[EXAMPLE]

An example syntax of signals and slots in Qt is shown below:
QObject::connect(&button_1,SIGNAL(clicked()), &application(quit()));

Like the name says, button_1 is given a signal flag, in the form of a click. When the signal is executed, the application will recevie instruction to respond to the signal, by quitting.

Advertisements

QT : GUI Toolkit Review

Posted in QT by akamal on January 16, 2007

I’ve had my hands on most C++ GUI toolkit available in the market so far, from OSS oriented products like wxWidgets, FLTK, fox toolkit to the commercial ones such as QT, and not forgetting those savvy yet difficult-to-implement GUI libraries, win32 and mfc.

Well, It doesn’t take a rocket scientist to realize, being resource short on mapower, concludes me to
axe both win32 and mfc, due to the amount of commitment need to be thrown at.

So, of all toolkits available, 2 are on my mind. Qt and wxWidgets. I have been an avid fan of wxWidgets all
these while, having at least 50% of previous UI work built using it, but I have to say of recent, the features and hype with Qt programming struck me.

One central feature of QT is in the dealing of object communication, signal and slot mechanism. It’s so
flexible and limitless, where usually with callback routines, you can only call a function (callback)
from a processing function, but with signals+slots, chains of events can be constructed with a single
call!

Plus, just like wxWidgets, there are so many utility classes provided by Qt, and since I am involved heavily in 3D graphics development for scientific interpretations, qt’s support for 3D through openGL plus its wrapper framework to Coin3D library, certainly gave a plus point.

The best thing in Qt is of course it’s cross-platform assurance, since qt doesn’t take on native widgets
when drawing GUI, instead it is built on its own. So, if I am ever required to deploy an app on linux, no / minimum coding is only required.

I’m currently in process of transfering the already developed seismic viewer program, originally built on top of wxWidgets, and though the portings are taking my time, I do think it’s worthwhile to migrate now, then to continue with the current library. One thing leaving me out of terms with wxWidgets was always of its limited 3D graphics extendability. Even though it supports openGL, the lack of external integrated graphic toolkit, left me fazed, not expecting myself to code everything including plotting libraries and all.