Administrace komentářů

Tvrzení o identifikaci řetězci je blud. K vlastnostem existují obvykle dva způsoby přístupu: generické (g_object_set(), identifikace řetězcem) a specifické metody get_něco(), set_něco().

Tvrzení o marshallingu bylo samozřejmě nadhozeno v konferenci Gtk+ (a myslím ne jednou), ale nikdo ho nikdy nedokázal podpořit čísly. Dokážeš to ty?

Pokud jde o Qt a OpenGL, doporučuji méně myslet a více si zjišťovat fakta.

Pokud jde o signály, vystačil jsem si s obyčejnými GObject signály, takže mě metakompilátory a templaty netrápí.

Pokud jde o navážení se do C, tak děláš-li to z posice C++, mohu se leda smát. C je nízkoúrovňový jazyk, takže to, že v něm lidé (já také) dnes píší GUI aplikace, je patrně omyl. Ovšem C++ je C zatížené second-system efektem ;-) Není ani dost vysokoúrovňové, aby ses nemusel sám starat o alokaci a uvolňování paměťi a psalo se v něm bez hromady balastu (srv. Python), ale ani dost nízkoúrovňové jako C, abys v něm měl tu alokaci pevně v rukou, děláš-li systémové programování (nepoužíváš-li ho prostě jako C-kde-je-const-opravdu-const). Většinu špatných věcí o C můžeš říci i o C++, a k tomu spoustu nových.

Pokud o to, který další jazyk nativně podporovat, tak nechápu. Že se jeden binding (GTK#) prohlásí za oficiálně podporovaný? To by se mohlo stejně dobře udělat s pygtk i dalšími. Že se celé Gtk+ přepíše do C#? No, to asi ne. Takže Gtk+ zůstane implementováno v C, a o co tedy jde?

Borci z Trolltechu dotáhnou věci do konce, až bude Qt na všech platformách free. Do té doby si ho mohou dát zarámovat.

Pokud jde o portabilitu C++ a bugovost kompilátorů C++, tak je to dnes lepší než před lety, což znamená jen nic moc, už ne naprostá katastrofa. A pročpak si asi každý drhuhý v C++ implementuje svůj vlastní ekvivalent STL?