Ik zit voor een opdracht van Visualization aan de TU/e (lekker met OpenGL spelen, geweldig 
) aan een applicatie te werken. Samen met iemand die op Windows werkt, dus moest het maar een QT applicatie worden. CentralWidget is de QGLWidget die de simulatie tekent, en ik heb er een dock naastgezet die uit een .ui file komt.
Er zitten nu heel veel parameters in de GUI. Op mijn QGLWidget heb ik inmiddels 70 signals en slots, die allemaal in de GUI moeten worden ingesteld c.q. teruggekoppeld. Dat is heel leuk, lekker makkelijk met de geweldige QT Designer in elkaar gesleept, maar dan beginnen 2 problemen de kop op te steken:
- Om een parameter toe te voegen moet ik op 3 plekken zijn: QT Designer om hem toe te voegen, geen probleem. De QGLWidget moet een slot (en eventueel een signal) erbij krijgen, ook geen ramp. Maar de klasse die afgeleid is van QMainWindow moet ik ook zijn, om eerst aan het dock-object te vragen om het goeie object, en daarna signal en slot te verbinden. Het vervelendste zijn de buttongroups, die niet meer werken zoals in QT3. Voorbeeldje uit de QMainWindow, waarbij visSettingsWidget het dock-object is (gegenereerd uit een .ui bestand), en fluidSim de QGLWidget:
Zoals te zien is, werkt dit typo's nogal in de hand. Vooral omdat dit toch wel copy/paste gedrag uitlokt: ik heb al een aantal keer gehad dat ik vergat het getalletje op te hogen, vergat hedgeColGray in heightColGray te veranderen, of bij de connect-statement vrolijk het oude object liet staan. Los van het feit dat het nogal wat scroll-werk vergt: 280 regels aan connect-statements
Wat doe ik hier verkeerd? Ik heb ergens het vage vermoeden dat dit handiger moet kunnen. Misschien niet om in dit projectje aan te passen, maar wel in de volgende.
En als er iemand een hint kan geven voor een online boek/howto/... waarin wordt uitgelegd hoe je handig een OpenGL applicatie kan opdelen in verschillende objecten houd ik me ook aanbevolen: 1800 regels in 1 klasse wordt wat onoverzichtelijk
) aan een applicatie te werken. Samen met iemand die op Windows werkt, dus moest het maar een QT applicatie worden. CentralWidget is de QGLWidget die de simulatie tekent, en ik heb er een dock naastgezet die uit een .ui file komt. Er zitten nu heel veel parameters in de GUI. Op mijn QGLWidget heb ik inmiddels 70 signals en slots, die allemaal in de GUI moeten worden ingesteld c.q. teruggekoppeld. Dat is heel leuk, lekker makkelijk met de geweldige QT Designer in elkaar gesleept, maar dan beginnen 2 problemen de kop op te steken:
- Om een parameter toe te voegen moet ik op 3 plekken zijn: QT Designer om hem toe te voegen, geen probleem. De QGLWidget moet een slot (en eventueel een signal) erbij krijgen, ook geen ramp. Maar de klasse die afgeleid is van QMainWindow moet ik ook zijn, om eerst aan het dock-object te vragen om het goeie object, en daarna signal en slot te verbinden. Het vervelendste zijn de buttongroups, die niet meer werken zoals in QT3. Voorbeeldje uit de QMainWindow, waarbij visSettingsWidget het dock-object is (gegenereerd uit een .ui bestand), en fluidSim de QGLWidget:
C++:
1
2
3
4
5
6
7
8
9
| QButtonGroup *hedgeColor = new QButtonGroup(this); rb = visSettingsWidget->findChild<QRadioButton*>("hedgeColGray"); hedgeColor->addButton(rb, 0); rb = visSettingsWidget->findChild<QRadioButton*>("hedgeColRainbow"); hedgeColor->addButton(rb, 1); rb = visSettingsWidget->findChild<QRadioButton*>("hedgeColCustom"); hedgeColor->addButton(rb, 3); connect(hedgeColor, SIGNAL(buttonClicked(int)), fluidSim, SLOT(setHedgeColor(int))); |
Zoals te zien is, werkt dit typo's nogal in de hand. Vooral omdat dit toch wel copy/paste gedrag uitlokt: ik heb al een aantal keer gehad dat ik vergat het getalletje op te hogen, vergat hedgeColGray in heightColGray te veranderen, of bij de connect-statement vrolijk het oude object liet staan. Los van het feit dat het nogal wat scroll-werk vergt: 280 regels aan connect-statements
Wat doe ik hier verkeerd? Ik heb ergens het vage vermoeden dat dit handiger moet kunnen. Misschien niet om in dit projectje aan te passen, maar wel in de volgende.
En als er iemand een hint kan geven voor een online boek/howto/... waarin wordt uitgelegd hoe je handig een OpenGL applicatie kan opdelen in verschillende objecten houd ik me ook aanbevolen: 1800 regels in 1 klasse wordt wat onoverzichtelijk