[Qt / C++] Programmeervolgorde

[FireAge]

Vroeger programmeerde ik in C++/Pascal, tegenwoordig werk ik voornamelijk in Labview.
Nu heeft Labview een mooie addon genaamd labview vision, waarmee ik allerlei beeldbewerkingen kan uitvoeren. Ideaal, althans, je moet wel 300 euro neerleggen per PC waarop je vervolgens zo'n applicatie wilt draaien.

Het grote voordeel van Labview is voor mij dat je er lui in kan programmeren en toch heel snel goeie resultaten in kan bereiken waarbijje automatisch ook je GUI voor mekaar hebt.

Ik wil nu eigenlijk mezelf weer opnieuw C++ verdiepen en daarbij meteen het GUI gedeelte oppakken. Mijn keus is gevallen op Qt omdat ik niet vast wil zitten aan windows (Visual C++/Borland).

Maar nu vraag ik mij af hoe ik het beste een programma op kan bouwen. In labview bedenk ik me altijd eerst hoe de GUI er uit komt te zien qua functionaliteit. Welke knoppen en inputs heb ik nodig, wat wil ik weergeven. Vervolgens knoop ik de code daaraan vast.

Ik ga iig eerst de Qt tutorial en manual doorlopen, om me bekend te maken met het programma, maar wil wel al vlot beginnen met het schrijven van een programma wat ik in gedachten heb.

Hoe organiseren jullie de opbouw van een GUI programma? Eerst nadenken over hoe de gebruiker benaderd wordt? Of eerst zorgen dat de code en berekeningen klaar liggen en die dan in een GUI passen? Of een complete andere manier?

[vdvleon]

Ik zou ook eerst de GUI maken. Je hebt voor Qt een handig programma (voor meerdere platforms) genaamd Qt Designer (als ik me niet vergis). Kan je gewoon makkelijk een layout (GUI) mee maken. Dit word dan een ui bestand. Deze kan je weer in c++ verwerken (je kan zelfs via de designer al wat standaart knoppen instellen, zoals quit, etc.).

[Soultaker]

Ik probeer zelf ook GUIs van te voren te bedenken (bedenken welke functies er in moeten, op papier wat dingen uittekenen, et cetera) maar in de praktijk blijk ik toch vaak dingen vergeten te zijn, waardoor ik alsnog van alles aan moet passen.

Ik denk dus dat je er sowieso van uit moet gaan dat je eerste versie een prototype is, die je daarna moet herzien om de GUI in een vorm te krijgen die je bevalt. Als je voor het eerst met Qt werkt komt daar bij dat je waarschijnlijk nog niet direct bekend bent met alle widgets e.d., dus de kans is groot dat je gaandeweg betere manieren ontdekt om bepaalde problemen op te lossen.

Ik denk dus dat het zinnig is om zo snel mogelijk echte GUI code te gaan schrijven om een beetje met de toolkit te kunnen experimenteren. Of je dan aan de hand van een tutorial een demo-applicatie code of je al direct aan je echte applicatie gaat werken maakt niet zoveel uit, lijkt me. De GUI uitstellen totdat de rest af is lijkt me niet echt een goed plan.

[Eddy Dean]

Als de GUI slechts een frontend is voor een ingewikkeld programma maak ik eerst de ingewikkelde code met een gewone command line interface, omdat ik dat makkelijker werken en testen vind. Daarna maak ik dan de GUI erbij. Als je bij iedere test die je doet eerst een weg moet banen door de GUI om een bepaalde functie te bereiken ben je tijd aan het verspillen.

Als de GUI juist de belangrijkste functionaliteit is (denk aan programmaatjes als een adresboek en dergelijke) maak ik die eerst, en dan pas de achterliggende code.

Meestal is het een combinatie van deze twee dingen. In ieder geval maak ik de lastige functies eerst met een command line interface en daarna pas de gui er omheen.

[leuk_he]

Daar zijn toch ook tooltjes voor?

2 seconden googlen (dus niet uit eigen ervaring)

http://doc.trolltech.com/.../qt/qtjambi-designer.html

Qt Designer is a visual tool for designing and building graphical user interfaces (GUIs) from Qt components. It allows you to design and build widgets and dialogs using on-screen forms. Components created with Qt Designer can also take advantage of Qt's signals and slots, and they can be previewed so that you can ensure that they will look and feel exactly as you intended.

[FireAge]

Ja ik werk inderdaad in de Qt Designer IDE.

Goed punt trouwens over waar de focus op ligt, want dat is in dit geval zeker de code en niet de GUI. Ik wil een stuk software schrijven dat verschillende beeldbewerkingen uit kan voeren op een door de user geselecteerd plaatje.

User selecteerd locatie van image, en de bewerkingen die gedaan moeten worden. Output zal weer een plaatje zijn.

Wat dat aangaat kan ik het eerst wel via de command line doen.

[Punkie]

De GUI en de core (in dit geval de transformaties die je gaat loslaten op een beeld, lezen en schrijven v plaatjes, laden van drivers, libraries, detectie van gpu, ... kortom al de rest) van je programma zijn 2 aparte delen. Bedenk ze apart, schrijf ze apart (eventueel in andere talen), test ze apart. Daarom maakt het eigenlijk niet uit welke je eerst ontwikkeld. Bedenk echter wel beide delen beinvloed zijn door de use cases van je prog. Best eerst deze doordenken en alle functies van je gehele programma opsommen.

[epic007]

Punkie schreef op dinsdag 02 juni 2009 @ 15:55:
De GUI en de core (in dit geval de transformaties die je gaat loslaten op een beeld, lezen en schrijven v plaatjes, laden van drivers, libraries, detectie van gpu, ... kortom al de rest) van je programma zijn 2 aparte delen. Bedenk ze apart, schrijf ze apart (eventueel in andere talen), test ze apart. Daarom maakt het eigenlijk niet uit welke je eerst ontwikkeld. Bedenk echter wel beide delen beinvloed zijn door de use cases van je prog. Best eerst deze doordenken en alle functies van je gehele programma opsommen.

+1

Het is goed om de core en GUI zoveel mogelijk van elkaar te scheiden. Zo kan je je core functies later nog als command line programma of via een script interface gebruiken.

[Hydra]

Eddy Dean schreef op dinsdag 02 juni 2009 @ 12:05:
Als de GUI slechts een frontend is voor een ingewikkeld programma maak ik eerst de ingewikkelde code met een gewone command line interface, omdat ik dat makkelijker werken en testen vind. Daarna maak ik dan de GUI erbij. Als je bij iedere test die je doet eerst een weg moet banen door de GUI om een bepaalde functie te bereiken ben je tijd aan het verspillen.

Het grote gevaar is daar dat je GUI simpelweg een verzameling controls wordt die je functionaliteit ontsluiten. Als de workflow enigzins complex is (complexer dan een bestandje laden en op GO! drukken) is het meestal beter om eerst / afzonderlijk een GUI te ontwerpen. Wij proberen altijd in een zo vroeg mogelijk stadium GUI ontwerpen te maken, zelfs al voordat het functioneel ontwerp afgerond is. Met wat mockups kun je nl. erg goed duidelijk maken aan een 'klant' (kan intern zijn) hoe jij zijn wensen geinterpreteerd hebt.

[FireAge]

In dit geval ben ik zelf de klant, dus dat scheelt. Verder wordt het inderdaad een programma met een GO! knop om mee te beginnen. Maar ik wil dit later uit kunnen breiden.

Waar ik bij Labview in het begin tegenaan liep was dat in serieel werkte. ALs het programma druk aan het rekenen was, dan kon ik geen knoppen meer bedienen, omdat de uitlezing daarvan pas in de volgende loop weer gebeurde. Dit is iets wat ik in ieder geval wil voorkomen. Het GUI gedeelte zal dus parallel moeten lopen en via events zijn informatie door moeten geven.

Hoe ik dit in C++ moet doen weet ik nog niet maar daar kom ik vanzelf achter. Ik heb nog nooit iets niet-serieel in C++ gedaan.

[Wim Leers]

FireAge schreef op woensdag 03 juni 2009 @ 11:56:
In dit geval ben ik zelf de klant, dus dat scheelt. Verder wordt het inderdaad een programma met een GO! knop om mee te beginnen. Maar ik wil dit later uit kunnen breiden.

Waar ik bij Labview in het begin tegenaan liep was dat in serieel werkte. ALs het programma druk aan het rekenen was, dan kon ik geen knoppen meer bedienen, omdat de uitlezing daarvan pas in de volgende loop weer gebeurde. Dit is iets wat ik in ieder geval wil voorkomen. Het GUI gedeelte zal dus parallel moeten lopen en via events zijn informatie door moeten geven.

Hoe ik dit in C++ moet doen weet ik nog niet maar daar kom ik vanzelf achter. Ik heb nog nooit iets niet-serieel in C++ gedaan.

Google maar eens op multi-threaded programming. En Qt heeft daar uiteraard een cross-platform abstractie voor: QThread.

[FireAge]

Ik heb me even een beetje verdiept in multithreading in C++.
Goeie tutorial: http://www.paulbridger.com/multithreading_tutorial/

Ik denk dat dit een brug te ver is. Het is al even geleden dat ik met C++ gewerkt heb, dus ik ga me eerst maar een toeleggen op een fatsoenlijk singlethread programma. Daarna kan ik altijd nog gaan werken aan een GUI en eventueel multithreading om de GUI en de calculaties parallel af te handelen.