wie projekt aufbauen?

Hier können eigene Projekte, die mit Qt in Beziehung stehen vorgestellt werden.
Antworten
nini_knoxville
Beiträge: 29
Registriert: 1. März 2007 16:07
Kontaktdaten:

wie projekt aufbauen?

Beitrag von nini_knoxville »

hi,
bin grade dabei ein etwas groesseres projekt auf die beine zu stellen. aber ich wuerd gern mal wissen, wie ihr eure .uis benennt bzw die dazugehoerigen klassen oder wo was bei euch rein kommt (ordnerstruktur etc)
FaS
Beiträge: 184
Registriert: 25. Mai 2006 19:48
Kontaktdaten:

Beitrag von FaS »

Macht irgendwie jeder anders, oder?
Folgende Vorschläge sind persönliche Präferenzen, die ich mir selber ausgedacht habe, notfalls also nicht beachten ;-)

Nach eigenen Erfahrungen und Benutzerfreundlichkeitsanalysen mit dem Fokus auf IDE-Unabhängigkeit hat sich für mich folgender Aufbau etabliert, welchen man auch in eclipse einprügeln kann:
"win" und "linux" sind stellvertretend für verschiedene Systeme, hier 32-Bit-Windows und einem nicht näher definierten Linux-System.

Code: Alles auswählen

Programmverzeichnis/
    bin/
        win/
            <Programme, DLLs und Qt-Plugins>
        linux/
            <Programme, Bibliotheken und Qt-Plugins>
        qt_de.qm
    dev/
        make-win/
        make-linux/
        src/
            <Quellcode inkl. *.ui>
            project.pro
    <Verknüpfungsprogramm(e)>
Makefiles erstellen: im Ordner make-win (bzw. make-linux usw.) mit qmake ../src/project.pro
Kompilieren: im Ordner make-win (bzw. make-linux usw.) mit make release o.ä.

project.pro-Besonderheiten:

Code: Alles auswählen

[...]

win32 {
  DESTDIR = ../../bin/win
} else {
  DESTDIR = ../../bin/linux
}

[...]
main()-Besonderheiten:

Code: Alles auswählen

int main( int argc, char **argv )
{
  [...]

  assert( QDir::setCurrent( "../.." ) );
  
  QApplication app( argc, argv );
    
  QTranslator translator; 
  translator.load( "bin/qt_de" ); 
  app.installTranslator( &translator ); 

#ifdef Q_OS_WIN32
  QCoreApplication::addLibraryPath( "bin/win" );
#else
  QCoreApplication::addLibraryPath( "bin/linux" );
#endif

  [...]
}
Vorteile:
- Systemunabhängig, man kann den selben Ordner in jedem System zur Entwicklung verwenden und muss nichts dafür anpassen, und man kann das Programm sogar in jedem System ausführen, gibt ja nur max. 2 Anwendungsverknüpfungen im Hauptverzeichnis (oder 3 mit Mac OS oder mehr mit 64-Bit Systemen usw. usf.), stört ja nicht weiter..
- Übersichtlich, im Hauptverzeichnis stören lediglich die Ordner "bin" und "dev", keine DLLs o.ä. Und aus der Entwicklerperspektive ist der Code auch von den systemspezifischen makefiles, Objekt-Dateien, moc-Dateien usw. getrennt, weiterhin erzeugen letztere beim Systemwechsel keine Konflikte.
Ach ja zur Anwendungsverknüpfung:

<Verknüpfungsprogramm> ist ein optionales bibliotheksloses Programm, welches als Verknüpfung für bin/*/Programm dient (aus Bequemlichkeitsgründen), es muss also in dieses Verzeichnis wechseln und dort das Programm ausführen. Das eigentliche Programm wiederum wechselt ganz am Anfang 2 Ebenen höher, um also im Programmverzeichnis ausgeführt zu werden, egal um welches System es sich handelt. Dadurch ist es theoretisch auch möglich den Inhalt von bin/*/* ins Hauptverzeichnis zurückzuverlagern ohne viel Code zu verändern.


Namensgebung: Zum Beispiel
window_main.ui
window_main.cpp
window_main.h
Klasse MainWindow
keine Ahnung was so üblich ist... Wichtiger sind mit da ordentlich durchdachte Syntax-Konventionen.

MfG,
FaS
Antworten