Tuesday, November 16, 2004
QT
It looks like we're going to be using QT for designing the interface of our programme. This morning I've been reading over the whitepaper for it (it had finished compiling when I got here - wonders never cease). Here's what I've learnt.
QT is like Java in that it's object-oriented, and (supposedly) platform independent. This is good news for me: Geoff wants me to make the app work on Linux, Mac and Windows. It seems to have a lot of abstraction in it, which means creating stuff may be a little more complex, but I can use inheritance to do lots of the work for me.
Everything extends QObject. Controls extend QWidget. Everything in QT begins with Q (or at least, that's what it seems like).
All the common controls have reasonable names: QRadioButton, QCheckBox, QComboBox, QTextEdit, etc. They also take the underlying OS graphical display automatically: this means that when we compile on a mac, things should look like a mac, on windows, like windows, etc. They even support the different Windows families (XP and non-XP). One thing I'm not sure about is MacOS9 support - I don't think its an option. OSX has been around for a few years now, so hopefully this won't be a problem by the time we release.
QT also has LayoutManagers, just like Java. It looks like there's just three: QHBoxLayout, QVBoxLayout, and QGridLayout. The whitepaper claims that the layout managers automatically pick the best sizes for widgets, so they look nice when the window's resized.
An important aspect of QT is the signal/slot mechanism. This is a way to send messages to other objects, without knowing what they are or who they're from. Basically, you define the various signals in your h file, under a signals: section, and the slots under slots: section. You also need to have Q_OBJECT there - I think this is a signal to the preprocessor. Your class has to extend QObject, too.
You then implement both in your cpp file. When you want to send a signal, you just go emit function(value). You define what happens when you receive a signal by implementing your slot method, and doing the correct action.
Slots can ignore some of their arguments, so if you have a function with three, a signal that only emits one may call it. The compiler automatically chooses the right one, but I bet that function's gonna bite me in the ass.
You couple the signals and slots together in your app file, using connect. In the whitepaper, they do this:
BankAccount x, y;
connect( &x, SIGNAL(balanceChanged(int)),&y, SLOT(setBalance(int)) );
x.setBalance( 2450 );
If it can't find an appropriate slot, it spits out a warning, but doesn't crash. Phew.
Saving settings looks okay. You can use the QSettings class to do this - on Windows it stores things in the registry, on other platforms, a text file. I think Phil said he saw this, but he decided to write his own - I'm not sure why, I'll have to ask. It may be a good idea to do this, but I'm sure he'll have his reasons.
Text can easily be translated too: you put your text in a call to tr() and it looks up the right one. You have to define it somewhere, but if we want to internationalise, this could be an easy way to do it.
QT is like Java in that it's object-oriented, and (supposedly) platform independent. This is good news for me: Geoff wants me to make the app work on Linux, Mac and Windows. It seems to have a lot of abstraction in it, which means creating stuff may be a little more complex, but I can use inheritance to do lots of the work for me.
Everything extends QObject. Controls extend QWidget. Everything in QT begins with Q (or at least, that's what it seems like).
All the common controls have reasonable names: QRadioButton, QCheckBox, QComboBox, QTextEdit, etc. They also take the underlying OS graphical display automatically: this means that when we compile on a mac, things should look like a mac, on windows, like windows, etc. They even support the different Windows families (XP and non-XP). One thing I'm not sure about is MacOS9 support - I don't think its an option. OSX has been around for a few years now, so hopefully this won't be a problem by the time we release.
QT also has LayoutManagers, just like Java. It looks like there's just three: QHBoxLayout, QVBoxLayout, and QGridLayout. The whitepaper claims that the layout managers automatically pick the best sizes for widgets, so they look nice when the window's resized.
An important aspect of QT is the signal/slot mechanism. This is a way to send messages to other objects, without knowing what they are or who they're from. Basically, you define the various signals in your h file, under a signals: section, and the slots under slots: section. You also need to have Q_OBJECT there - I think this is a signal to the preprocessor. Your class has to extend QObject, too.
You then implement both in your cpp file. When you want to send a signal, you just go emit function(value). You define what happens when you receive a signal by implementing your slot method, and doing the correct action.
Slots can ignore some of their arguments, so if you have a function with three, a signal that only emits one may call it. The compiler automatically chooses the right one, but I bet that function's gonna bite me in the ass.
You couple the signals and slots together in your app file, using connect. In the whitepaper, they do this:
BankAccount x, y;
connect( &x, SIGNAL(balanceChanged(int)),&y, SLOT(setBalance(int)) );
x.setBalance( 2450 );
If it can't find an appropriate slot, it spits out a warning, but doesn't crash. Phew.
Saving settings looks okay. You can use the QSettings class to do this - on Windows it stores things in the registry, on other platforms, a text file. I think Phil said he saw this, but he decided to write his own - I'm not sure why, I'll have to ask. It may be a good idea to do this, but I'm sure he'll have his reasons.
Text can easily be translated too: you put your text in a call to tr() and it looks up the right one. You have to define it somewhere, but if we want to internationalise, this could be an easy way to do it.
# posted by Stuart @ 10:02 AM 
