Co do narzędzi do programowania – nie wiem, w czym Qt ma być takie niby lepsze (tylko proszę, nie mówcie o QtDesigner czy QtCreator). Tu akurat wychodzi słabość Qt — normalne narzędzia nie obsługują na przykład moc-a z marszu i trzeba albo instalować dziwne pluginy, albo bawić się w obchodzenie tego.

Porównanie Qt (nawet jako samej biblioteki do GUI) z GTK i GTKmm to zupełnie inne sprawy. Z GTK nie chcę porównywać, bo może możliwości podobne, ale całkiem inna filozofia programowania. Jak dla mnie GTK jest pod tym względem niezbyt akceptowalne, ale to tylko kwestia preferencji. Za to porównanie z GTKmm – to może za 10 lat. Bawiłem się tą biblioteką jakiś czas temu (około roku) i zrobienie czegokolwiek było drogą przez mękę. Nie dlatego, że C++, tylko ze względu na braki, braki, braki, braki… No i ta dokumentacja. Tłumaczenie, że można się podpierać gołym GTK to jakaś paranoja — nie po to jest framework, żeby pisać w niższych warstwach. W Qt możesz powiedzieć, że można się podpierać framebufferem, X-ami albo WinAPI… I jeszcze co – niestety, styl, w jakim jest napisane GTKmm jest może i całkiem niezły, ale wymusza silne powiązania już na etapie kompilacji. W Qt wiele rzeczy przenoszonych jest na czas linkowania bądź wręcz uruchomienia. Przy takich zastosowaniach, do jakich służą obie biblioteki, jest to sprawa nie do przecenienia.

To, o czym piszesz, jest może świetne na etapie pisania projektów na studia albo małego projekciku, ale nie w wypadku czegoś, co ma być pisane dla przemysłu. A błyskotliwy kod C++ jest akurat niezły do pisania bibliotek, ale przy GUI się sprawdza słabiej (i nie chciałbym być tu źle zrozumiany — sam, kiedy tylko mogę, używam "ekstremalnego" C++, przynajmniej do poziomu wspieranego przez współczesne kompilatory, tego też wymagam od ludzi – ale nie wymagam ani od siebie, ani od zespołu, pisania takiego kodu tych rejonach, gdzie nie ma z tego żadnych korzyści). A łączenie takiego C++ z C (tam, gdzie sugerujesz łatać za pomocą GTK) na pewno nie pomoże stylowi wyjściowego kodu. Raczej wprowadzi kod dużo gorszy, niż w Qt (mówię o kodzie pisanej aplikacji — kod biblioteki mam gdzieś, bo dla mnie ważne jest działanie i interfejs).

Acha – jeszcze końcowa kwestia – wsparcie. Komercyjnego (no, ja akurat sobie mogę pozwolić – firma płaci) nie porównam — nie wiem, jak jest z GTK(mm). Ale nawet darmowe, społecznościowe – na oficjalnych forach Qt kręci się mnówsto trolli (oj, przepraszam — teraz już nojów), którzy naprawdę potrafią pomóc, a jeśli odpowiedź nie wystarczy, a problem jest poważny – wrzucić coś do kodu. Przykłady z tutoriala są genialne (bo pokazują dokładnie to, co mają pokazać). No i biblioteka podąża w kierunku, który dyktuje rynek. Nie zawsze jest to dobre pod względem stylu, ale na pewno pomaga osobom piszącym aplikacje (szczególnie gdy te powstają nie tylko dla linuksa z X-ami czy inną, konkretną platformę).

Życzę GTK i szczególnie GTKmm jak najlepiej — przy czym zdaje mi się, że o ile to pierwsze osiągnęło już fazę produkcyjną, o tyle drugie nie ma w najbliższym czasie szans na wyjście z fazy "akademickiej". Jeśli nawet to się nie uda, to choć będziemy pamiętać całkiem udany, choć (niestety) niedokończony eksperyment, wyciągniemy wnioski i stworzymy coś innego — bo przecież o to głównie chodzi… 😉

A co takiego nowoczesnego maja stringi z glibmm?

Faktycznie, roznice powalajace! Od dzisiaj przestaje uzywac Qt i przerzucam sie na rewelacyjne Gtkmm, bo ma przestrzenie nazw! Co tam kretynski model obiektowy, fileselector doprowadzajacy do drgawek i powszechne traktowanie uzytkownika jak idiote. Sa przestrzenie nazw!

Java właśnie umarła (zaczęła umierać), Sun się sprzedał a to on trzymał spójność tego środowiska. Teraz wyszstko się rozlezie bo każdy będzie ciągnął w swoją stronę, nowy właściciel Sun'a niekoniecznie może być skłonny utrzymywać ten projekt na wysokich obrotach.

IMHO Java to fajny pomysł ale akademicki. Pomysł na marnowanie ogromnej ilości zasobów (RAM i CPU) tylko dlatego, bo deweloperowi nie chce przekompilować kodu do natywnej postaci jest jakiś taki brzydki i w drodze ewolucji powinien zostać wyeliminowany jako nieoptymalny. Ja się dziwię się dlaczego to tak długo trwa?!?

Owszem Java nadaje się do pewnych projektów, ale już nie do dużych aplikacji z rozbudowanym GUI – patrz Eclipse, bez 4GB ramu nie podchodź, a podczas kompilacji programów G++ najwięcej czasu CPU zajmuje proces o nazwie Java….