Je ešte GTKMM rovnocenným súperom Qt5 na poli GUI? Čo chystá ako odpoveď na Qt5? Moje požiadavky sú udržovateľnosť a čiteľnosť kódu, prípadne podpora IDE. Je mi ukradnutý výkon, licencie a multiplatformnosť. Chcem programovať len na desktope.
Viem, že GTKMM preferuje STD C++ kdežto Qt si vytvára v podstate vlastný jazyk pomocou makier. Pre mňa to bol show-stopper pre Qt, až kým som si neprečítal čo vravel Guaillaume Laurent. Zaujímalo by ma či to ešte platí. Tiež by ma zaujímalo akú podporu plánuje GTKMM pre C++11.
Kazda liska chvali svuj ocas, nemam zkusenost s GTKMM, ale s Qt ano, dela se s tim dobre, je to prakticke a mnozstvi maker neni tragicke.
Kdo zkusil foreach(prvek, container), nechce uz jinak, vim, ze v novem C++ standardu uz je to lepsi, ale v Qt4 je od zacatku a je to strasne navykove. Napriklad.
Nebo copy-on-write u kontejneru atd. atp.
A neviete teda čo pre nás chystá GTKMM? Lebo ako som pozeral vývojové verzie glibmm 2.29 (unstable) a gtkmm 3.1 (unstable) tak dátum poslednej modifikácie je až v lete 2011! Preto si myslím, že GTKMM už nie je rovnocenným súperom Qt.
@Luboš Ja neverím bludom, ale sú dve veci ktorým sa v C++ vyhýbam: makrá a nepoužívanie STL. Qt má obe. Gtkmm nemá žiadne. Chcel som len vedieť aké zlé to je a či má tendenciu sa to zlepšiť v Qt5. Podpora pre C++11 je v tomto smere veľké plus. Tiež vidno, že Qt sa snaží upraviť svoje kontajnery pre kompatibilitu s STL, ak je to možné.
QTcko mi porad jeste prijde lepsi nez GTK(i kdyz v GTK uz uz 10 let nedelal), protoze ma za sebou full-time placene vyvojare. Posledni dobou se ale spis soustredi na nove vlastnosti a nove uzivatele, nez aby fixovali stare bugy.
Treba zrovna ty kontejnery. Viz QTBUG-12941. V jejich Coding convetions je uvedeno:
Don’t mix const and non-const iterators. This will silently crash on broken compilers.
Nejak uz ale nezminuji, ze broken compilers jsou vsechny verze g++ a MSVC.
@Luboš Ja neverím bludom, ale sú dve veci ktorým sa v C++ vyhýbam: makrá a nepoužívanie STL. Qt má obe. Gtkmm nemá žiadne. Chcel som len vedieť aké zlé to je a či má tendenciu sa to zlepšiť v Qt5.
Zlé to není a tudíž není důvod se to snažit "zlepšit". Třeba u maker se na ně stačí podívat (např. http://qt.gitorious.org/qt/qt/blobs/4.8/src/corelib/kernel/qobjectdefs.h#line67 nebo http://qt.gitorious.org/qt/qt/blobs/4.8/src/corelib/kernel/qobjectdefs.h#line157) a je vidět, že je to jen pomůcka na to, aby to člověk nemusel všechno psát pořád dokola ručně (což nakonec klidně i může, ale nikdo rozumný to dělat nebude, protože se v tom dá udělat chyba a je to daleko míň přehledné). Makra nejsou dobrá nebo špatná, dobré nebo špatné je jen použití.
Stejně tak nepoužívání STL mi přijde spíš jako výhoda. Pro mě je používání std::string nebo std::vector proti QString nebo QVector docela utrpení. Třeba s QVector se test, jestli obsahuje prvek, píše 'qvector.contains( element )', což by nejspíš pochopila i moje babička (kdyby uměla anglicky). A jak se to napíše se STL?
Kdo chce velkou flexibilitu, "úžasný" design, "čistý" návrh a podobné záležitosti, ať si klidně používá Gtkmm a STL. Qt je pro praktické lidi.
Ďakujem za cenné postrehy z praxe. Ešte som chcel zmieniť, že práve skúšam nové Kubuntu 12.10 postavené na Qt 4.8.3 a len za poslednú hodinu mi crashol KWin a plasma-desktop v dvoch rozličných bugoch pri bežnom používaní na aktualizovanej distribúcií. Celkovo je KDE u mňa menej stabilné ako GNOME. Zaujímalo by ma, či sú tieto druhy chýb nejak spojené s kódom pre Qt, alebo sú to chyby v bežnom kóde.