C++ framework voor grafische interfaces.

[conara]

Ik ben zelf al een tijdje opzoek naar een goed framework om een grafische (windows) interface voor een c++ programma te maken. Uiteraard ben ik opzoek geweest naar mogelijke frameworks, maar zie eerlijk gezegd door het bomen het bos niet meer. Omdat er vast en zeker tweakers zijn die hun ervaringen willen delen heb ik dit topic geopend. Het doel van het topic is om ervaringen te delen met betrekking tot C++ frameworks waarmee grafische interfaces gemaakt kunnen worden.

Zelf heb ik nog geen ervaringen met dergelijke frameworks, maar zoek een goed framework om mee te beginnen. Nu kan ik natuurlijk alle mogelijke frameworks gaan testen op functionaliteit ect, maar dat zal dan de nodige tijd kosten (die momenteel niet beschikbaar is). Om het topic op gang te brengen zal ik mijn eisen opsommen die ik aan het framework stel. Daarnaast mogelijkheden waarnaar ik kort heb gekeken.

Het framework moet grofweg aan de volgende eisen voldoen:

- Relatief eenvoudige leercurve voor de basis, maar met het framework moet wel veel mogelijk zijn. (Ik ben redelijk goed bekwaam in het programmeren in c++)
- Goede documentatie en/of tutorials/voorbeelden.
- Moet met windows werken. Andere besturingssystemen is leuk maar niet perse nodig.
- Grafische gedeelte moet eenvoudig gewijzigd kunnen worden --> OOP achtige oplossing.
- Gratis ingebruikname, zowel voor open source als voor eventuele commerciële projecten.
- Voorkeur gaat uit naar oplossingen die ook in het bedrijfsleven worden gebruikt, maar is niet verplicht.

Mogelijkheden (let op: ik heb nog geen praktische ervaring met de onderstaande frameworks) :

QT - http://qt-project.org
Over QT heb ik gelezen en is op het eerste oog een goede mogelijkheid. Een gebruiksvriendelijke "editor" om het programma op te bouwen. Grote communitie en online ook redelijk veel te vinden over het framework. Valt onder de LGPL licentie, dus is ook in commerciële projecten te gebruiken.

GTK++ - http://www.gtk.org
Volgens mij ook wel een redelijk populair framework.

WxWidgets - http://www.wxwidgets.org
Ook wel redelijk populair.

Waar werken jullie mee? en waarom? Oftewel deel jouw ervaring!

[Caelorum]

Ben zelf erg gecharmeerd van Qt (let op de kleine letter t ). De documentatie op hun website is uitstekend en met het ietswat verouderde boek C++ Gui programming with Qt 4 heb ik zelf mijn eerste stappen in c++ gewaagd.
GTK+ (niet ++) wordt best veel gebruikt in linux OS vanwege voornamelijk GNOME. Dus dat is ook best een redelijk alternatief. Wel vind ik persoonlijk dat de programma's onder Windows nogal opvallen doordat ze niet helemaal aansluiten bij de "normale" stijl. Dit is met Qt dan weer totaal niet zo IMO.

[ Voor 35% gewijzigd door Caelorum op 16-05-2014 17:24 ]

[Soultaker]

Heeft Microsoft geen handige tools/libraries voor het ontwikkelen van GUIs met C++/C# in .NET?

Dat lijkt me eigenlijk de meest voor de hand liggende keuze als je specifiek voor Windows wil ontwikkelen. Alle andere alternatieven hebben juist als voordeel dat ze platform-onafhankelijk zijn. Als daar toch een van kiest, zou ik voor Qt gaan.

[Cilph]

Qt is werkelijk prachtig om mee te mogen werken. Kan ik van GTK+ niet zeggen. De enige reden dat GTK+ populair is is omdat de status quo zich voortzet.

[ Voor 32% gewijzigd door Cilph op 16-05-2014 19:19 ]

[Caelorum]

Ja, GTK# (directe wrapper om GTK+) was ook al niet zo'n pretje om mee te beginnen. Het is vooral het documentatiegedeelte dat te wensen overlaat en niet eens zozeer het framework zelf. Qt heeft als added-bonus dat je het hele framework meekrijgt. Dat maakt bijv. Boost redelijk overbodig.

[Soultaker]

Je kunt van Qt ook zeggen dat het een heleboel functionaliteit uit de standaardlibrary (strings, containers, et cetera) dupliceert. Verder zitten er een heleboel dingen in Qt die feitelijk niet in een GUI toolkit thuishoren (zoals XML parsers) vandaar dat de ontwikkelaars het ook een “application framework” noemen.

GTK+ is vergeleken daarmee simpeler. Wel is het zo dat de op C toegespitste API niet heel fijn werkt onder C++. Vandaar dat ik ook Qt aanraadde: dat past beter in een C++-applicatie. Overigens is GTK+ wel heel eenvoudig te gebruiken in Vala (wat weer meer op C# lijkt).

[Caelorum]

Ja, dat is inderdaad iets waar je even op moet letten als je Qt gaat gebruiken. Waarschijnlijk kan je beter zoveel mogelijk bij de STL blijven zodat je in de toekomst makkelijker van GUI toolkit kan veranderen, maar als dat niet zoveel uitmaakt, gewoon het beste van beide werelden gebruiken, of wat maar sneller programmeert.

[Infant]

Een van de Microsoft wrapper heet MFC, maar heb ik zelf nooit gebruikt.

Ik babbel altijd gewoon direct tegen de API aan, en gebruik Visual Studio om alle knopjes en grut te tekenen.

Nou ben ik wel benieuwd: Waarom zoek je per se een framework?

[conara]

Ik ben niet perse opzoek naar een framework, maar naar een goede manier om een grafische interface te maken. Ik had gelezen dat direct tegen de API praten nogal omslachtig is, vandaar dat ik opzoek ben gegaan naar een goed alternatief. Knopjes tekenen ect kan dat nog met de nieuwste versie van visual? Want in een oude versie kon dit geloof ik wel, maar visual studio 2013 ben ik het nog niet tegengekomen...

Heeft Microsoft geen handige tools/libraries voor het ontwikkelen van GUIs met C++/C# in .NET?

Geen idee, maar je maakt wel een goed punt wat mij betreft. De discussie gaat voornamelijk over Qt en GTK++, waarbij Qt qua gebruiksvriendelijkheid een aantal stappen voor heeft. Nu is mijn vraag gebruiken bedrijven dan ook deze programma's of gebruiken die meer windows specifieke tools? Of zijn ze nu juist aan het over stappen naar meer multiplatform frameworks, omdat ze hun programma op meerdere OS'en wille ondersteunen?

[Caelorum]

conara schreef op zaterdag 17 mei 2014 @ 11:34:
[...] De discussie gaat voornamelijk over Qt en GTK++, waarbij Qt qua gebruiksvriendelijkheid een aantal stappen voor heeft. Nu is mijn vraag gebruiken bedrijven dan ook deze programma's of gebruiken die meer windows specifieke tools? Of zijn ze nu juist aan het over stappen naar meer multiplatform frameworks, omdat ze hun programma op meerdere OS'en wille ondersteunen?

Ik kan niet veel zeggen over wat er in het bedrijfsleven wordt gebruikt, maar het is duidelijk dat het nogal ligt aan het bedrijf. Ik vermoed dat best veel bedrijven die nu nog met c++ bezig zijn op windows (en dus niet C# en dergelijke) of al multiplatform bezig zijn of dit in de toekomst gaan doen en die zullen dus allemaal naar niet windows-specifieke toolkits kijken.
Van de genoemde crossplatform toolkits krijg ik zelf sterk de indruk dat GTK+ meer in zwang is bij de opensource crowd (vanwege GNOME) en Qt wat bij de commerciële instellingen (want Digia is dat zelf ook en er is een commerciële licentie beschikbaar).
Een blik op Wikipedia (niet echt goede bron maar ok) bevestigd dit ook. De artikelen Wikipedia: List of GTK+ applications en Wikipedia: Category:Software that uses GTK+ staan voor 95% vol met opensource programma's waarvan een groot deel van GNOME zelf overigens. Een blik op het Qt artikel Wikipedia: Qt (software) geeft mij al een tiental grote namen in de IT wereld en een verdere blik hier Wikipedia: Category:Software that uses Qt geeft me ook nog wat niet commercieel KDE spul.

[EddoH]

conara schreef op zaterdag 17 mei 2014 @ 11:34:
Ik ben niet perse opzoek naar een framework, maar naar een goede manier om een grafische interface te maken. Ik had gelezen dat direct tegen de API praten nogal omslachtig is, vandaar dat ik opzoek ben gegaan naar een goed alternatief. Knopjes tekenen ect kan dat nog met de nieuwste versie van visual? Want in een oude versie kon dit geloof ik wel, maar visual studio 2013 ben ik het nog niet tegengekomen...


[...]


Geen idee, maar je maakt wel een goed punt wat mij betreft. De discussie gaat voornamelijk over Qt en GTK++, waarbij Qt qua gebruiksvriendelijkheid een aantal stappen voor heeft. Nu is mijn vraag gebruiken bedrijven dan ook deze programma's of gebruiken die meer windows specifieke tools? Of zijn ze nu juist aan het over stappen naar meer multiplatform frameworks, omdat ze hun programma op meerdere OS'en wille ondersteunen?

In het bedrijf waar ik werk maken we erg veel gebruik van Qt, voor zowel Windows applicaties als (embedded) Linux applicaties. Het grote voordeel dat Qt hier heeft is dat we ontwikkeling hoofdzakelijk op een Windows machine kunnen doen, om de hele boel vervolgens te cross-compilen en op een embedded apparaat te draaien.

Waar je wel aan moet denken is dat niet alle GUI componenten native componenten zijn. D.w.z dat ze er misschien niet altijd uit exact zo uit zien als in een native Windows programma. Het blijft een implementatie, inclusief visuals, van Qt. In de praktijk merk je daar echter weinig van.

Het Qt platform biedt verder zoals eerder gezegd meer dan alleen een GUI toolkit, en zorgt ook voor een abstractielaag voor het onderliggende OS. Inclusief threading, file access, etc.

[ Voor 8% gewijzigd door EddoH op 17-05-2014 13:24 ]

[conara]

Bedankt voor de comments. Ik ga sowieso kijken naar het Qt framework. Als er nog goede alternatieven zijn die ook het bekijken waard zijn hoor ik het graag. Mensen die specifiek voor windows ontwikkelen werken die toch niet Qt of zijn er nog andere goede libraries/frameworks/APi's.

[epic007]

Kijk dan ook zeker naar QML (onderdeel van Qt), hiermee kan je mooie UI's maken. Het is geen c++ maar een javascript/json achtige definitie taal waar je via c++ weer aan kan binden.
Zo krijg je een mooie scheiding tussen code en ui (model/view).

Ik ben zelf over gestapt naar C# .NET om de UI te maken. De c++ code zit in een aparte dll en via een mixed/mode wrapper class kunnen die twee met elkaar communiceren.
Zie voor een voorbeeld van zo'n wrapper hier:
http://www.windowsdevcent...004/03/29/mcpp_part3.html

[ Voor 37% gewijzigd door epic007 op 19-05-2014 08:50 ]

[WernerL]

QTCreator is trouwens een fantastische IDE voor C++ dus als je met QT aan de slag gaat kun je daar ook gelijk je UI in bouwen. Ik heb in het verleden 1 project in QT gedaan en ik was er erg positief over. Goed gedocumenteerd en het ging makkelijker dan ik verwacht had. :-)

[dinux]

Qt is naar mijn ervaring de beste keus, makkelijk te poorten naar linux ook. Het nadeel van GTK++ is dat het vrijwel volledig Linux is ingericht en voor Windows maar een magere ondersteuning bied. Wx heeft dat niet maar is weer een stuk complexer qua code.

[Vishari Beduk]

conara schreef op vrijdag 16 mei 2014 @ 17:13:
Waar werken jullie mee? en waarom? Oftewel deel jouw ervaring!

Je kan ook eens de officiele adviezen van Microsoft hierover lezen:
http://www.microsoft.com/net/nettechnologyguidance

[DJMaze]

Ik vind Qt en FLTK wel heel lekker werken: http://www.fltk.org/

[ Voor 10% gewijzigd door DJMaze op 19-05-2014 17:00 ]

[Verwijderd]

-

[ Voor 125% gewijzigd door Verwijderd op 19-05-2014 20:31 ]

[R4gnax]

epic007 schreef op maandag 19 mei 2014 @ 08:38:
Ik ben zelf over gestapt naar C# .NET om de UI te maken. De c++ code zit in een aparte dll en via een mixed/mode wrapper class kunnen die twee met elkaar communiceren.

Dit lijkt me, heel eerlijk, gewoon de beste optie. Makkelijkste weg om nu een GUI op Windows aan de gang te krijgen. Daarnaast is er ook eindelijk vaart gekomen in de beweging om .NET echt cross-platform beschikbaar te maken, waardoor je tzt waarschijnlijk dezelfde UI ook gewoon op Linux en Mac kunt draaien.

[Stukfruit]

.NET is een framework met veel meer dan alleen UI-spul. Misschien bedoelen jullie Windows Forms of WPF?
Die laatste is trouwens wat langzaam, maar wel heel erg lekker qua databinding

GTK+ en Gtkmm (c++ wrapper) zou ik trouwens ver bij uit de buurt blijven. Maakt alleen maar een lelijke en inflexibele ui met veel boilerplate code (al is Gtkmm wat dat betreft wel een verbetering).

wxWidgets leunt te veel op de onderliggende toolkits en is daardoor snel irritant om mee te werken, plus er zit niet genoeg mankracht achter om de toolkit vooruit te duwen qua bugfixes en features.

Dus dan blijft eigenlijk alleen Qt nog over. En daar is tegenwoordig weinig mis mee

[Refro]

Wij hebben naar Qt gekeken maar zijn het uiteindelijk niet gaan gebruiken door het intensieve gebruikt van eigen string libs en dergelijke. Hierdoor is het voor ons lastiger de software te porten naar (en tussen) embedded platforms.

Wij hebben uiteindelijk gekozen voor een stuk buisness logic (soft realtime) in C++ met oa boost libs, De GUI is opgebouwd in .net (compact framework) met een tcp/ip communicatie tussen beide modules.

[VyperX]

Waitwut...? Qt was uiteindelijk bedoeld om gebruikt te worden op de mobiele telefoons van Nokia.

Op wat voor embedded platform draaien jullie dat die portablitity een probleem is...?

[EddoH]

Daar ben ik inderdaad ook heel benieuwd naar... Ik kan me eventueel ergens voorstellen dat als veel geheugenallocaties bij het werken met strings een probleem is dat dat roet in het eten zou gooien, maar dan heb je het over embedded platforms waar C++ überhaupt een foute keuze zou zijn (en dan zou een .Net GUI ook niet heel zinnig zijn)

Wij gebruiken Qt *juist* omdat het zo perfect portable is...

[farlane]

Refro schreef op dinsdag 20 mei 2014 @ 09:51:
De GUI is opgebouwd in .net (compact framework) met een tcp/ip communicatie tussen beide modules.

Voor een remote UI is dat wel een voor de hand liggende oplossing, maar voor iets dat lokaal op het device draait maak je dan wel een aardige omweg, met relatief veel overhead.

[Caelorum]

Sowieso vind ik zijn redenatie een beetje vreemd:

Wij hebben naar Qt gekeken maar zijn het uiteindelijk niet gaan gebruiken door het intensieve gebruikt van eigen string libs en dergelijke. [...]

Dan gebruik je toch alleen het GUI deel van het framework en doe je met de rest niets? Niemand verplicht je om QString te gebruiken en bij Qt geven ze zelf ook aan dat het soms handiger is om de standard library te gebruiken.

[Refro]

farlane schreef op dinsdag 20 mei 2014 @ 10:15:
[...]

Voor een remote UI is dat wel een voor de hand liggende oplossing, maar voor iets dat lokaal op het device draait maak je dan wel een aardige omweg, met relatief veel overhead.

Dat valt reuze mee met de localhost afkortingen die het OS neemt. En op onze borden met een UI kan dit er makkelijk vanaf.

Wij gebruiken Qt *juist* omdat het zo perfect portable is...

Dat ligt denk ik ook voor een groot deel aan het speelveld. Voor onze headless systemen op een STM32 (72 mhz) bied het voor ons geen voordelen.

Op wat voor embedded platform draaien jullie dat die portablitity een probleem is...?

De belangrijkste 2 zijn een STM32 met keil RTX en een AM33 met linux/winCE. En vooral op de STM kunnen wij er niet zo veel mee.

[EddoH]

Op die systemen snap ik het op zich wel, maar wat ik niet snap is waarom de String functionaliteiten van Qt een probleem zouden vormen, en waarom een .Net GUI er wel goed op zou werken.

Daarnaast zou je core functionaliteiten gewoon in standaard C/C++ kunnen schrijven en dan nog Qt kunnen gebruiken. Wat ik eigenlijk probeer te zeggen is dat het alternatief dat je aanhaalt voor zover ik kan zien geen voordelen biedt ten opzicht van deels Qt gebruiken?

[Refro]

Op het moment dat wij deze evaluatie gedaan hebben hadden we al ervaring met .net (in pc omgeving) Er bleven voor de ui dus Qt en .net over en toen zijn we voor de ons bekende gegaan.

[Amanoo]

Is Qt ook niet handiger voor crossplatform dingen dan GTK+? Of vergis ik me hierin? Zoals genoemd heeft GTK+ nogal iets met Gnome, in ieder geval, waar je Qt overal tegenkomt. Volgens mij is GTK+ redelijk op Gnome gericht. Maar ik ben geen GUI-ontwikkelaar, ik heb me er nooit in verdiept, dus ik kan er wel eens lelijk naast zitten.

[Caelorum]

Het uiterlijk van GTK+ applicaties oogt nogal niet-native in Windows en OSX. Verder is er niet al teveel op aan te merken, behalve dan de wat outdated documentatie en manier van GUI's programmeren. Wat dat betreft is Qt een stuk meer met de tijd meegegaan. Maar in principe is GKT+ (of GTK#) nog best wel te doen, alleen zou het niet mijn eerste keus zijn buiten Gnome-applicaties om.

[dinux]

Ook voor Gnome begin ik standaard in Qt, gewoon omdat KDE en Windows dat ook prima weergeven zonder weinig code aanpassingen. Zelfs nog redelijk native op Windows 7 en 8. Zelf denk ik dat de GTK tijdperk langzaam aan het aftreden is. (hoewel de scripting ondersteuning wel enorm goed is.)

[farlane]

Refro schreef op dinsdag 20 mei 2014 @ 11:47:
Dat ligt denk ik ook voor een groot deel aan het speelveld. Voor onze headless systemen op een STM32 (72 mhz) bied het voor ons geen voordelen.
[...]
De belangrijkste 2 zijn een STM32 met keil RTX en een AM33 met linux/winCE. En vooral op de STM kunnen wij er niet zo veel mee.

En met de manier waarop je het nu doet is het wel portable tussen de STM32 en een ding met Linux/WinCE?

Eerlijk gezegd vind ik het flauw om Qt af te rekenen op het niet portable zijn naar zulk een systeem, zelfs C++ is op een dergelijke MCU niet compleet.

[MSalters]

VyperX schreef op dinsdag 20 mei 2014 @ 09:55:
Waitwut...? Qt was uiteindelijk bedoeld om gebruikt te worden op de mobiele telefoons van Nokia.

Bull. Qt is ontwikkeld door TrollTech, niet Nokia. Ik gebruikte het 5 jaar voordat Nokia Trolltech opkocht. De reden voor de overname was dat Symbian (Nokia's OS) een absolute ramp was, met een API die technologisch op het nivo van DOS stond, en teveel verschillende en incompatible smaken. Het bestaande Qt product had dat moeten gaan oplossen.