Dirk Hohndel, pracownik Intela w dziale Open Source Technology Center, przedstawił na odbytej niedawno konferencji linux.conf.au 2014, swoje doświadczenia odnośni pisania aplikacji w Qt i GTK. Jego wykład nosił tytuł: Gtk to Qt – a strange journey i opowiadał w nim o tym, jak z innymi osobami przepisywali aplikację Subsurface 4.0 z GTK na Qt, i jakie wnioski z tego wyciągnięto.
Dlaczego według Dirka, framework Qt jest lepszy, aniżeli GTK? Otóż problem z tym drugim nie leży w samym narzędziu i jego możliwościach, ale głównie w centralnej społeczności deweloperów. Podczas swoich prac, starał się wspomóc w pewnych kwestiach odnośnie pisania kodu i niestety, ale jego wypowiedzi, stawały się terenem wojen słownych oraz tekstów typu: robisz to źle, nie tak to powinno wyglądać. Dirk Hohndel nie chcąc tracić czasu, zwrócił się z podobnymi kwestiami do społeczności Qt, która bez problemów pomagała i angażowała się w sam projekt. Do tego było dostępne sporo dokumentacji dla deweloperów i nie istniały problemy w komunikacji, jak to było w przypadku deweloperów GTK.
Dirk Hohndel: Dlaczego Qt jest lepsze od GTK? | OSWorld.pl http://t.co/oHIlwXLLfs via @OSWorldpl
Jedyną wadą Qt jest to że z jakiś powodów producenci przeglądarek dużo częściej wybierają GTK.
Michał Olber liked this on Facebook.
Uwaga zaraz się zacznie: 3…2….1
Minęła godzina i nie zaczęło się… Przegrałeś.
Konrad Kania liked this on Facebook.
Od dawna mówiłem, że społeczność GTK- i Gnome to banda chamów zapatrzonych w siebie i zamkniętych na współpracę. Miło, że ktoś wreszcie oficjalnie i publicznie to potwierdził.
A technicznie GTK- też jest bublem i nie dorasta do pięt Qt.
Jak ty w ogóle dajesz radę uruchomić nvidia-settings?
Odprawia egzorcyzmy przed uruchomieniem.
Gusła chyba będą lepszym określeniem ;)
Zwyczajnie: alt+f2 'nvi’ tab enter
Używam wielu programów na GTK-, choćby samego Gimpa.
To nie twórcy aplikacji piszący w GTK- czy same te aplikacje są problemem. Owszem, aplikacje takie są gorsze, wolniejsze, słabiej integrują się z systemem, szczególnie jak nie używasz Gnome, nie potrafią nawet poprawnie się zestylować jak w tle nie chodzi mułowaty gniotowy rejestr w postaci gconfd tym bardziej udowadniający przywiązanie GTK- do środowiska Gnome. Ale poza tym najczęściej spełniają swoje zadanie.
To GTK- jest problemem autorów takich aplikacji. Bo używają wypaczonego błędu zamiast właściwego narzędzia. Na szczęście wszyscy przenoszą się coraz częściej na Qt i to jest bardzo dobry trend.
Wreszcie przestała działać obłudna propaganda Gnome o zamkniętości Qt, anty-społecznościowości i tym podobne bzdury. Okazało się, że rozwój Qt jest bardziej otwarty, nastawiony na społeczność, Qt chce integrować się z każdym środowiskiem i być przenośne. Propaganda Gnome się skończyła i przygniotły ich fakty.
A przede wszystkim Qt działa. A GTK- jest oparte na błędnych założeniach dodających sztucznie obiektowość do języka nieprzewidującego jej użycia, GTK- 2 jest przestarzałe, a GTK- 3 bardzo niedopracowane.
Szczególnie tą szybkość Qt widać na windows, a już szczególnie na przykładzie transmission. Dawno nie widziałem tak wolno rysującego się interfejsu i to nie jest odosobniony przypadek. Aplikacje KDE na windows też „działają” wolno
Qt ma bardzo duża zaletę: Jest wyjątkowo łatwo portatywne. W wielu przypadkach ten sam lub niewiele zmieniony kod programu kompiluje się na Linuksie, Windowsie czy np. Haiku i działa. Problemy zaczynają się z interfejsem – gdy np. wymuszamy położenie kontrolek a nie stosujemy gridów, to może nam się GUI z lekka rozjechać na jakimś systemowym stylu. Jeżeli przy uruchamianiu nie ustawiamy atrybutów komponentów przez pomiar używanych czcionek to na stylach klasycznych w Linuksie kładziemy taką aplikację niemal zupełnie (mam na myśli style Motifo-podobne). To jest jednak do rozwiązania narzędziami samego Qt.
Natomiast dużym problemem jest dostępny build na Windowsy, który jest kompletnie niewydarzony. Nie każdy ma 4TB dyski na przebudowę Qt ze źródeł. To, że ktoś zapłacił za Windowsy nie znaczy również, że ma płacić np. hostingowi, bo 40MB na DLLki dołączane do wydalin kompilatora to jest za dużo. I nie są to biblioteki Qt, tylko jakieś ?icu*?. Podobno można to załatwić przebudowując Qt ze źródeł, przy czym w Windowsach postępowanie zgodnie z większością procedur przebudowania powoduje zapchanie dowolnie dużego dysku.
Rozwój Qt powinien skupić się jeszcze na optymalizacji wydajnościowej buildów na różne systemy, bo aktualnie to troszkę leży, szczególnie jeżeli chodzi o procesor. Nie każdy ma 8 rdzeni, niech to będzie użyteczne również na subnotebookach.
Przeszedłem na Qt w pisaniu małych programów w GUI dlatego, że jest łatwiej (choć to, co odwala Creator przy półautomatycznej edycji GUI jest kilka lat przed Delphi 1.0) i szybciej można przekompilować projekt między systemami.
no całkiem z sensem kolega prawi… przy qt5 sporo się ogarnie ale fakt z mswin jest słabo może to kwestia dostępności wersji komercyjnej? w każdym razie pyciak i qt to bardzo ciekawe technologie i rozwinięte narzędzia
Jeśli piszesz interfejs bez użycia menadżerów układu i sam pozycjonujesz widgety, to mam nadzieję, że potem tylko ty używasz tej aplikacji. Inaczej szczerze współczuję użytkownikom, szczególnie, że skoro tak spartoliłeś UI, to jak bardzo mogłeś skopać logikę? Czyżby przyzwyczajenia z GTK-, gdzie layouty ledwo działały?
To wina windowsa, że nie dostarcza podstawowych bibliotek. Pisz do microsoftu. .net waży kilka GB, jak chcesz dać komuś aplikację w nim napisaną pod XP, gdzie nie ma go domyślnie, to zobacz ile zależności musisz dołączyć. Podobnie źle jest z Javą. GTK- też swoje waży choć to już bardziej poziom Qt. A ty marudzisz coś na temat 40MB? Przy czym zapewne twojej aplikacji wystarczy wybrać z tego 10-15MB.
Poza tym nie używam windows do budowania Qt, bo dużo lepiej od całego systemu microsoftu sprawdza się cross-kompilacja na windows pod Linuksem.
Layouty niestety są często przeceniane, właśnie czcionki trzeba mierzyć samemu, sprawdzać tekst i dostosowywać komponenty UI/rozmiar czcionki podczas tworzenia, bo w niektórych kompozycjach (MOTIF-podbne) zacznie się wszystko rozłazić! Tekst wyłażący z przycisków to tam norma. Mam nawet gdzieś takie VM do „testu wytrzymałościowego” GUI aplikacji w Qt, Okienka są skonfigurowane jak połączenie Motifa z TWMem.
Czasami jak piszę to musi to wyglądać jak WS_FTP ’95, gdzie wszytko było pisane czcionką typu mono.
Linux również nie dostarcza podstawowych bibliotek, szczególnie jeżeli chodzi o interfejsy obrazowania. Bo system nie może dostarczać wszystkich bibliotek. Od tego są repozytoria (Linux), serwer ze źródłami (BSD) lub strony producenta (Windows).
Jeżeli zainstaluję 2 wersje .net, aplikacje mi chodzą. Jeżeli zainstaluję programy Qt, muszę mieć DLLki różnych wersji w zależności od kompilacji. To jest chyba jedyna przewaga .neta w codziennym użytkowaniu :).
Jeżeli chodzi o 40MB, już mówię co jest problemem: Core i GUI żrą jakieś 12-14MB, o ile pamiętam. Nie piszę dużych programów i w 80% wyrabiam się tym bibliotekami. Często z powodów problemów z hostingiem wsadzam te biblioteki do osobnego archiwum, ale ogólnie jest OK.
Qt 4.8 na tym kończy. Natomiast Qt 5 dodaje jeszcze jakieś biblioteki, są to pliki o nazwach zaczynających się na „icu”, i to doprawia resztę do tych 40MB.
Nie jest lepsze. Tylko oddajcie mi pełną funkcjonalność Gnome 2. ;)))
Piszę z pozycji użytkownika.
A inna rzecz to skłócenie środowisk, faktycznie można odnieść wrażenie jakby ktoś celowo w nich mieszał kijem jak w mrowisku.
Jest jeszcze jedna wkurzająca rzecz, w GTK chcieli to wprowadzić, ale się nie udało, w Qt nawet o tym nie myśleli, a naprawdę jest to rzecz moim zdaniem dziś obowiązkowa.
Podam przykład z GIMPa i LibreOffice’a, ale dotyczy to niemal każdej aplikacji na Linuksie. Może z wyjątkiem FileZilla, ale oni to zrobili w sposób skrajnie „ręczny”.
Chodzi mi o okna dialogowe z pytaniami i ustawieniami. Jeżeli TabOrder (czyli kolejność przełączania się między kontrolkami tabulatorem) jest przemyślany, to już coś. Ale jeżeli mam okienko np. w GIMPie zmiany rozmiaru, czemu nie mogę potwierdzić wpisanych wartości Enterem? Więc jadę myszą z monitora, na któym mam obraz na monitor, na
którym mam wyświetlony „ustrój kontrolny” i szukam tego nieszczęsnego
„Zastosuj”. W LibreOffice to samo tyczy się okienka z pytaniem o zapis pliku – nie mogę szybko wcisnąć „Y”, „T”, czy „N”, jest podłączony tylko Esc. Skróty w takich okienkach podobno jakieś są, ale nie można łatwo zapamiętać ich modyfikatorów, a tym bardziej użyć na szybko.
To miało sens, gdy X’y stosowało się do wizualizacji wyników na grafoskopie podczas, gdy shell z programem obliczeniowym działał na alfaskopie – pióro grafoskopu było „odrębnym światem”, a nadanie klawisza nie mogło rozwalić pięknych wyników. Teraz, gdy te dwa terminale są połączone w obudowie peceta, ten prosty problem spowalnia pracę.
W GTK przewija się cały czas koncepcja unifikowanych okienek do stałych zadań, ale nigdy nie zostało to wprowadzone na szeroką skalę. Qt nie ma do tego wsparcia w ogóle, i trzeba je budować w postaci bibliotek własnych.
A co klawisze mają wspólnego z biblioteką, to twórca aplikacji podpina zdarzenie klawisza pod przycisk lub funkcję.
Powinna być możliwość użycia ergonomicznych okienek od systemu – aplikacje Windowsowe mają dzięki temu zunifikowane skróty w okienkach. W Linuksie system tego nie da, ale mogą zająć się tym biblioteki zamiast wymuszać na użytkowniku pisanie własnych rozwiązań tylko po to, żeby okienko z przyciskami Tak/Nie działało z klawiaturą.
„przyciskami Tak/Nie działało”
Takie proste okienka w Qt dostarcza QMessageBox i nie trzeba ich pisać, kod ich utworzenia jest prostym wywołaniem statycznej funkcji, chociaż można jak chcemy coś niestandardowego to utworzyć klasę i ustawić inaczej. Czy w GTK+ coś takiego istnieje nie wiem.
W Qt podstawowe skróty są standardowe, ale nie jest ich tak dużo ponieważ piszesz na wiele platform więc sam musisz wybierać jakie klawisze skrótów będziesz stosował w zależności od docelowej platformy. Taka jest cena biblioteki wieloplatformowej.
Skróty w QMessageBox są raczej kapryśne jeżeli chodzi o działanie przy różnych nie tyle systemach, co nawet środowiskach Linuksa. Prawdopodobnie właśnie z tego powodu, że jest to biblioteka wieloplatformowa, czyli „to powinien zrobić system”. Jak system robi pisałem wcześniej i naleciałość z czasów grafoskopów zaczyna hamować ergonomię aplikacji.