First serious project using Qt - I need some guidelines

[Blackened Justice]

Hey everyone,

This past semester, I did a project for my programming class, using the C language with the Allegro graphical library. Anyway, I've been reading up and doing Qt tutorials for some weeks, and now wish to embark on a real project: porting that project to C++ and Qt.

Well, I've been having a hard time starting out. I have a general vision of how I want the interface to be, but I'm still a bit new to the whole OO paradigm, so I'm afraid I'm approaching the problem from the wrong angle. I tinkered with it for a bit, but just decided it was a better idea to start from scratch.

I have my code hosted at github: https://github.com/JPaquim/ATC-Qt
The C/Allegro version is in the c-allegro folder, I'm sorry about the Portuguese comments and readme, but the professor wanted it in Portuguese.

The project is a game like some out there, based on the monitoring and control of airplanes entering and leaving an airspace. So far I've made a few classes, namely a MainWindow (in order to have a menu bar and tool bars, along with a status bar) from a Trolltech tutorial, a MyWidget (QWidget which will be the central widget in the MainWindow) where I'll put the interface, an Airspace (which will be the heart of the program, a QWidget that will control the airspace graphical representation, containing the various entry gates, runways and airplanes.

I'm having a hard time figuring out how to progress right now... I want to take care of the loading of the airspace's configuration file first, and then take care of drawing the elements loaded from that file (gates and runways), but what is the correct way of doing that? Should I just load from the configuration file in the Airspace class's constructor?

Any help and comments would be welcome,
Cheers

[amleto]

Configuration could probably a few hours worth of lectures on its own. Do you have many stages of configuration in your app? Now is a good time to think about the process of configuration, and how many different steps there are, how many different classes will be affected. If there are multiple things that need to be configured, is order of configuration important?

There should probaly be separate class(es) to do the file handling and data manipulation of the config. Some related class would then forward the relavent data on to Airspace ()

[Blackened Justice]

Oh, it's just a simple configuration file with a description of the airspace, a map if you want to call it that. Right now I just want to be able to load it in, and populate the various variables with its contents. I'll think about making it possible for the user to create their own maps in the future, right now I just want to load it.

[amleto]

In that case, just stick to a class for reading the file and returning some data. The owner of this class should know where to pass the data to.

[d_stranz]

It probably is not appropriate to do the configuration in the Airspace constructor, but in an Airspace::onConfigureAirspace( const AirspaceConfiguration & ) slot. In the MainWindow, in the slot that handles the triggered() signal from the QAction attached to the "Load Configuration" menu item, you retrieve the name of the configuration file, pass it to the bool AirspaceConfiguration::load( const QString & fileName ) method, and then emit an airspaceConfigurationChanged( const AirspaceConfiguration & ) signal:



// MainWindow.h:

class MainWindow :: public QMainWindow
{
O_OBJECT;

// usual constructor stuff, etc.

signals:
void airspaceConfigurationChanged( const AirspaceConfiguration & config );

protected slots:
void onLoadConfigurationTriggered();

protected:
Airspace airspace;
AirspaceConfiguration currentConfig;
};

// MainWindow.cpp:

MainWindow::MainWindow( QWidget * parent )
: QMainWindow( parent )
{
// set up menus, actions, etc
// ...
connect( this, SIGNAL( airspaceConfigurationChanged( const AirspaceConfiguration & ) ), &airspace, SLOT( onConfigureAirspace( const AirspaceConfiguration & ) ) );

// more setup if needed
}

void MainWindow::onLoadConfigurationTriggered()
{
QString fileName = QFileDialog::getOpenFileName();
if ( !fileName.isEmpty() )
{
if ( currentConfig.load( fileName ) )
emit airspaceConfigurationChanged( currentConfig );
}
}


This way, all of the different parts of the program are separated, each with a well-defined function, and with minimal inter-dependence on other parts of the program. Communicating by signals and slots (in the Qt way) means that the two partners on each end don't need to know anything about each other, only that they share the connection with its well-defined protocol.

By making an AirspaceConfiguration class, you now have a way to change the configuration independently of other parts of the game. Presumably, the Airspace class itself is responsible for implementing all the rules (like, two planes can't be at the same place at the same time, on the same runway headed towards each other, etc.). You could then create a GUI for designing a new AirspaceConfiguration independently of the rest of the program, so instead of only being able to load a configuration from a file, you could change it interactively and emit the same signal.

Likewise, I presume you would implement a series of other classes to represent Aircraft, Gate, Runway, Taxiway, Terminal, or whatever else makes sense in the context of the game.