Qt 5.0 z obsługą HTML5 i C++11

Ciekawe kiedy przeczytam chociaż jeden Twój komentarz, który nie będzie krytycznie nastawiony. Chociaż jeden pozytywny komentarz.

QT dla mnie jest zbyt odbłe i brzydkie po prostu. Nie wnikam w technologię, bo się na tym nie znam. A pisząc "idiotyczne pseudostandardowe biblioteczki rozszerzające" nie bardzo rozumiem co masz na myśli. Rozjaśnij, proszę.

Nie rozumiem "brzydkie" w kontekście biblioteki. Nie podoba Ci się API? A może jakieś rozwiązania w wewnętrznej implementacji?
Bo jeśli chodzi o wygląd zewnętrzny, to samo Qt nie ma nic do gadania, temat sobie można zmienić. Ja np. mam ten sam, co w GTK (i to działa!).

Może nie podobają mu się wcięcia w kodzie ;-) A na serio to wydaje mi się o wygląd zewnętrzny aplikacji QT.

Największą słabością QT jest brak możliwości programowania w innych językach niż C++. Trochę próbuje to ratować Qt Quick. W Gtk można pisać w C, C++, JavaScript i bardzo fajnym języku Vala. Składnia Vali jest o niebo lepsza niż C++, za to Gtkmm jest na mój gust jest paskudny, w QT pisze się o wiele lepiej, do tego dokumentacja jest całkiem niezła. Jakbym chciał pisać w C++ to na pewno byłoby to QT. Tyle, że na szczęście nic mnie nie zmusza, abym pisał w C++ ;)

Od kiedy wyszło QML to chyba już nie trzeba tak dużo pisać w tym C++. Jedynie model i trochę logiki. Od biedy możesz sobie to zaimplementować w C i w C++ tylko na styku Qt. To nawet dobre podejście w dzisiejszych czasach.

Jakoś mnie nie ciągnie do pisania w javascriptopodobnym języku ;) QT ma tę zaletę, że dodaje różne elementy takie jak chociażby wygodne QString więc łączenie go z C do przyjemności nie należy. Niektóre elementy QT w szczególności z QTCore powinny być wbudowane w C++. Nie wiem czy próbowałeś pisać coś w Vala, ale tak właśnie powinien wyglądać współczesny C++. Jak zaczynasz używać bardziej wygodnych języków to później trzeba mieć na prawdę poważny powód aby wrócić do C++.

Oczywiście, że próbowałem używać Vala, taka samo jak C#. To świetne języki, ale z Valą miałem ten problem, że po jakimś czasie stare programy kompilowały się bez błędów, a po uruchomieniu wywalały segfaulta. To mnie wystarczająco odstraszyło.

Mi JS nie przeszkadza. Lubię ten język. Kiedyś lubiłem PyGTK, ale mi przeszło po ostatnich wyczynach, w których wieloplatformowa została mi tylko linia 2.xx.

Każdy język ma jakieś wady. Mój kolega nazwał to kałoplastyką. Trzeba sobie z nimi radzić na swój sposób. Jeśli używam C++, to robię to w dość ograniczony sposób, tak jak w Pythonie. Prostactwo bez czarów.

Największą wadą Vala jest młodość. ;)

Fajne osiągnięcia w niej mają twórcy ElementaryOS. Ich narzędzia są estetyczne i lekkie.

Można programować w takich oto językach:

Ada
C
C# & .NET (x2)
D
Haskell
Harbour
Java
Lisp
Lua (x2)
Pascal
Perl
PHP
Python (x3)
QML
R
Ruby
Scheme
Tcl

(więcej na http://en.wikipedia.org/wiki/Qt_(framework)#B… )

Wybacz mu. Polscy emeryci mają ciężkie życie. Facet musi gdzieś mieć ujście. ;-)

Jedni wolą Qt, inni GTK, moim zdaniem obie biblioteki mają swoje wady i zalety, GTK jest znacznie lżejsze, a Qt to cały framework, który wymusza pewien sposób budowy aplikacji, nie jest już tylko biblioteką GUI. GTK ma wsparcie dla Cairo, w Qt trzeba było się męczyć QPainterami, które dla mnie były uciążliwe (do wszystkiego te QPeny i QBrushe, wymagane referencje, omg gdzie to trzymać?), za to w Qt jest gotowy silnik rysowania grafiki wektorowej oparty na scenach, który też ma swoje zalety (obecnie pracuję nad czymś podobnym dla Javy, choć zastanawiam się nad przejściem na JavaFX).

Nie ma rzeczy idealnych.

Swojego czasu GTK był bardziej opłacalny ze względu na licencję Qt.

W Qt5 widziałęm, że wprowadzili odpowiednik interfejsu webowego Canvas 2D. Zatem jest prawie jak w GTK. Z tą różnicą, że Qt-owy ma prawie zerową akcelerację (czyli praktycznie jak Cairo.

Cairo używa OpenVG i OpenGL, zależy co dostępne, więc akceleracja jest, Qt "pod spodem" też sięga po OpenGL'a, gdzie to możliwe.

Graphics2D Javy też sięga po akcelerację, jeśli to możliwe.

Cairo teoretycznie używa akceleracji (w bardzo małym zakresie, głównie do patternów), bo w większości przypadków to by zajechało GPU i sprawiło, że sterownik zaczął brać 1 GB RAMu na tyle kontekstów (w Ubuntu zawsze był taki fajny regres).
I nie w zależności od tego co dostępne, tylko jak skompilujesz.

Ja też lubię ten interfejs kontekstowy w stylu Applowego Canvasa, ale nie czarujmy się. Oprócz niego implementacja też musi być dobra. Może niech zaczną używać biblioteki Skia.

Bo na canvasie sie w QMLu nie robi jakiegoś GUI złożonego, dodano to dla pełności i łatowości portowania kodu javascript np. z HTML5. Ten Canvas nie jest podstawą QtQuick-a, podstawą tu jest Scene Graph w 100% akcelerowany, coś zupełnie o innej architekturze niż GTK+ czy QWidgety w Qt.

"do wszystkiego te QPeny i QBrushe, wymagane referencje, omg gdzie to trzymać?"

Widzę tu nieumiejętność programowania w C++ lub pythonie itp. a nie problemy w Qt. Niektórzy pozosatli na etapie globalnych funkcji C jak to jest w cairo, co nie uprawnia do krytykowania innch rozwiązań, których (jak na razie) chyba nie rozumieją.

Szkoda, że o_O tego nie rozumie.

Pracowałem jakiś czas w QtJambi, nie powiem że to było przyjemne, a przynajmniej praca właśnie ze sceną 2D. To była tragedia, aczkolwiek Python świetnie się dogaduje z Qt.

Polemizowałbym. Tworzenie w Pythonie modeli dla Listy w QML to bezsensowna męczarnia. Gorsze jest tylko MVC w PyGtk TreeView.

Tak kiedyś używałem, to akurat chyba najlepszy sposób używania QT. Nie brałem pod uwagę języków dynamicznie typowanych. (można też pisać ponoć w QT w Ruby). A o QJambi słyszałem niezbyt pochlebne opinie.

Po prostu nie ma sensu ładować 10MiB bibliotek by nadpisać coś, co w Javie już jest. Sam port jakością nie zachwyca, ale Swing też przecież daje radę. Te 10 MiB już bym wolał poświęcić na Scalę, którą ostatnio bardzo polubiłem, nigdy jeszcze nie pisałem w równie "luźnym" języku :)

Ale sam Swing nie jest chyba zbyt wygodny, ani wydajny. Do tego nie ma natywnego wyglądu. Cóż nie istnieją idealne rozwiązania. Chociaż właśnie w Scali Swing jest całkiem fajny.

Swing ma natywny wygląd (LAF), ale nie zawsze włącza się domyślnie. Przy tworzeniu własnych komponentów lepiej jednak użyć nie natywnego, a Nimbusa, albo innego uniwersalnego LAFa, już się przekonałem o tym że niektóre LAFy się rozjeżdżają w pewnych sytuacjach, jak np. GTK. Osobiście podoba mi się Darkula, ale nie wiem jak z jego licencją, powinna być lGPL…

Wygoda to fakt, trochę oporny jest Javowy Swing, Scalowy znacznie wygodniejszy dzięki lambdom, ale w Javie 8 też mają być lambdy :) Mam nadzieję że nie będzie trzeba dalej tworzyć ActionListenerów dla każdego przycisku, tylko po prostu przypisać lambdę i po robocie.

A wydajny? Czy GUI musi być wydajne? Ma się je szybko i w miarę wygodnie tworzyć, wydajny to ma być silnik gier, nikt nie zauważy ani nie odczuje czy obsługa buttonu trwa 1ms, czy 5ms.

Nie widziałem jeszcze Swinga wyglądającego natywnie. Najlepiej wygląda Netbeans, a IDEA jest brzydka.

Co do wydajności to zastanawiam się czy negatywne opinie wielu użytkowników o programach napisanych w Java, dotyczących ich niskiej wydajności nie wynikają przypadkiem właśnie z niskiej wydajności Swinga.

Java ma w ogóle opinię "wolnego języka", więc wszelkie niedogodności (nawet z tym w ogóle nei związane) są przez laików zwalane właśnie na to, ale to pozostałości po czasach gdy jeszcze JIT nie pracował. Osobiście nie spotkałem się z tym, żeby program działał zauważalnie wolno tylko dlatego że używa Swinga. No może NetBeans czasem, ale po 5-10 minutach działania dochodzi do normy i działa dobrze, ten kombajn jest po prostu przeładowany.

Swing na Linuksie (a raczej: środowiskach gnomopochodnych) domyślnie używa GTK, na Macu tamtejsze coś, a na Windzie też sięga po natywne komponenty, choć chyba nie standardowo.

IMO NetBeans na Metalu wygląda żałośnie, obecnie używam Nimbusa, bo GTK się rozjeżdża, poza tym używam ciemnego motywu KDE, co przekłada się też na wygląd GTK, a to znów na natywny LAF Swinga, a sporo elementów ma przypisany niedomyślny kolor samej czcionki pozostawiając ją ciemną na domyślnym (u mnie ciemnym) tle, co jest tragedią (przykładowo JOptionPane ustawia czcionkę na czarną, a tło pozostawia domyślne). Eclipse nowy też wygląda słabo na tym motywie.

Niepotrzebnych kompilacji (JIT) w skali globalnej to już nikt nie liczy?!

Java? Nie dziękuje!

Tam gdzie coś raz ma być włączone i działać 24 godziny na dobę i zaliczać wielomiesięczny uptime, to Java i jest dobra, ale to rynek korporacyjny a nie desktop. Ja na swoim komputerze korzystam z programów napisanych w Javie, Pythonie, et consortes, kiedy nie znajduję żadnego zamiennika napisanego w C, C++, Free Pascalu, etc. Czyli prawie w ogóle. Albo inaczej, program ma być już skompilowany, a nie interpretowany, etc.

Wy patrzycie na to od strony programisty, a ja ze strony użytkownika końcowego (którego np. nie obchodzi wygoda programisty, ale wydajność i ficzery).

Kolejna sprawa jest taka, że dopóki nie zacząłem intensywniej używać Haiku, to myślałem, że muszę kupić dysk SSD. Coraz trudniej jest mi tolerować wszelkie lagi, przymulenia i rzeźbienie po dysku. Porównałem działanie mojego komputera (jednordzeniowy procesor, gigabajt RAMu) napędzanego przez Haiku, z laptopem mojej kobiety ( 2-rdzenie + HT i 4 GB RAMu) gdzie jest Windows 7. Różnica była na korzyść mojego komputera. Podobne odczucia mają osoby które pisały komercyjny soft na QNX.

Nie jest to atak na Jave jako taką, patrząc na powszechność jej użycia, jest to dobre narzędzie (tak jak i Windows :P ). Tylko odnoszę wrażenie, że niepotrzebnie jest to pchane na desktop. Nie ten target.

@Premislaus: " Java? Nie dziękuje"

Nie za bardzo zapalczywie? :-)
Sam przecież za chwilę piszesz, że jednak używasz. Osobiście również jak mam wybór to wolę programy natywnie kompilowane, ale są sytuacje gdy albo nie ma wyboru, albo program w Javie ma dużo lepszą funkcjonalność.
Przewaga Javy uwydatnia się w bardzo dużych programach, gdzie w języku natywnie kompilowanych zaczynają się problemy z doprowadzeniem programu do stabilności. Do tego dochodzą koszty wytwarzania oprogramowania – dużo niższe w przypadku Java.
Równie dobrze ktoś mógłby narzekać, że nie chce programów w C tylko w asemblerze :-)
Nie widzę również, aby było dużo programów w Javie na desktop, więc nie ma obawy, że ktoś coś pcha na desktop.

Teoretyzujecie jak politycy…