O przyszłość nie pytaj.
Bo to taki temat jak “wyższość Bożego Narodzenia nad Wielkanocą”.
Nie to nie jest prawda. JSa używasz w QtQuick do manipulacji węzłami, ewentualnie do MVVM. Ale to jest tylko część składki QtQuick które jest kompilowane do czegoś w rodzaju bytecodu interpretowanego przez moduł QtQuick. Code::blocks to tylko IDE, może i wspiera inne języki ale bez odpowiedniej konfiguracji i adapterów nie sprawi, że Qt będzie można użyć w prosty sposób w innych językach - w sposób porównywalny do natywnego użycia tak jak w C++.
Uczę się od ciebie, dziękuję za cierpliwość i prosty język 
ps.
Chociaż tych węzłów nie rozumiem (i MVVM), ale zrzucam to na barki mojej niewiedzy 
Język Quick z tego co pamiętam poszczególne elementy interfejsu nazywa węzłami, to trochę są takie elementy drzewa DOM. Jak chcesz nimi manipulować, animować, albo reagować na interakcję z userem to najlepiej to zrobić w ES (EcmaScript, JS implementacją tego języka podobnie jak NodeJS). MVVM to jest wzorzec projektowy którego warstwa View w Qt też jest robiona właśnie w ES. Odbierasz w nim ViewModel i aktualizujesz dane w View.
Chciałbym umieć pisać takie programy jak: odtwarzacz muzyki, notatnik, przeglądarka obrazów czy środowisko graficzne. Chciałbym pisać w GTK.
Jakiego języka powinienem uczyć?
Można by rzec, że naturalnym językiem dla GTK+ jest C. Wtedy w ruch idzie biblioteka GLib. Do obsługi multimediów można wykorzystać GStreamer.
Nic nie stoi jednak na przeszkodzie, że skorzystać z bindingów do C++ i rozwijać oprogramowanie w tym języku. Biblioteka gtkmm wraz z całą resztą (libsigc++, cairomm, glibmm, pangomm, atkmm, a także gstreamermm, gtksourceviewmm, gtkspellmm czy czego tam potrzebujesz) jest całkiem spoko, chociaż czasem można odnieść wrażenie, że czegoś tam brakuje.
Ja mimo wszystko poleciłbym Ci pójście w Pythona. Od razu zaznaczam, żeby była jasność: nie tykaj PyGTK, tylko od razu zacznij od PyGObject. Dzięki GObject Introspection masz pewność, te bindingi są aktualne i dopracowane. Nie przejmuj się przy tym ewentualnymi narzekaniami, jeśli znajdziesz takie w sieci. Wynikają one głównie z migracji z PyGTK. Każdy taki proces będzie problematyczny, więc nie warto nad tym przesadnie lamentować.
Czego nie polecam:
- Vala - Ten wybryk natury przed laty promowany przez GNOME jest już praktycznie martwy a przynajmniej nie stosuje się go do nowych projektów.
- Ruby - Popularność tego języka w ostatnich latach mocno poszybowała w dół, ale to jeszcze nic w porównaniu do z tym co stało się z Ruby-GNOME2.
- PHP - Tak, istniało coś takiego jak PHP-GTK, ale na szczęście dokonało już swego żywota.
- C# - Gtk# miało jakiś sens gdy Novell mocno inwestował w rozwój Mono (również pod kątem SUSE Linux Enterprise Desktop), obecnie to ślepa uliczka, chociaż niektórzy jeszcze próbują coś z tym zrobić.
- Java - Java na desktopie jest jeszcze bardziej martwa niż aplikacje wykorzystujące Gtk# na Linuksie.
- Pascal - Chociaż w zasadzie powinienem tu mówić o bibliotece LCL (Lazarus Component Library), która pod Linuksem może wykorzystywać GTK+ czy Qt, bo to raczej z niej byś korzystał gdybyś już zdecydował się na FPC/Lazarus. Normalne bindingi są bowiem niczym yeti - niby ktoś je gdzieś widział, ale nikt przy zdrowych zmysłach publicznie się do tego nie przyznaje. W każdym razie zarówno FPC, Lazarus i LCL to relikty przeszłości. Od kiedy Borland przegrał z Microsoftem walkę o dominację IDE, brnięcie w tym kierunku straciło jakikolwiek sens.
Powinienem jeszcze wspomnieć o wxWidgets. Tutaj naturalnym językiem jest C++. Niby są jakieś bindingi, ale w większości martwe. W każdym razie naczelnym celem tej biblioteki było dostarczenie natywnego toolkitu na każdej platformie. To była bardzo kusząca idea i wxWidgets zdobył wtedy pewną popularność, szczególnie że Qt przez lata nie radziło sobie dobrze na systemie Apple a GTK+ wyglądał tam po prostu koszmarnie. Tym niemniej świat parł do przodu a rozwój wxWidgets był powolny, przez co zostali w tyle. Na Cocoa w Mac OS X czy GTK+3 pod Linuksem trzeba było czekać aż do wydania wxWidgets 3, ale gdy ono ujrzało światło dzienne, dla tej biblioteki było już za późno. Ostatecznie wxGTK2 nie jest wcale takie złe (pomijając oczywiście ograniczenia samego GTK+2), ale już nie wykorzystasz tam kontrolki webowej, bo przestano ją łatać i większość dystrybucji jej nie dopuszcza ze względów bezpieczeństwa. Tego problemu nie miałbyś w wxGTK3, ale ten z kolei jest koszmarnie niedopracowany, i to bez względu na to czy weźmiesz wxWidgets 3.0 czy 3.1 (wersja rozwojowa). Tak więc ludzie z tego uciekają jak tylko mogą.
Wracając do tematu, gdy zdecydujesz się na C czy C++ i będziesz zastanawiał się nad własnoręcznym tworzeniem Makefile albo skorzystaniem z Autotools, to z góry mówię - odpuść sobie. Idź od razu w Meson, ewentualnie CMake 3. Pamiętaj, że mówimy o aplikacjach z graficznym interfejsem użytkownika, więc bez względu na wybrany język wypadałoby jakoś ogarnąć tłumaczenia oraz tworzenie i instalację ikon, pliku desktop i AppData. Oczywiście w przypadku Pythona możesz to po prostu zrealizować w setup.py, nie ma problemu.
Co do CI, to rozejrzyj się za Travis CI, Buildbot i GitLab Runner, najlepiej w tej kolejności.
Jako IDE możesz wypróbować GNOME Builder, a jeśli nie przypadnie Ci do gustu, to nada się cokolwiek innego, chociaż pewnie najlepszym wyborem byłaby w tym wypadku Anjuta. Ważne tylko, żebyś do budowania interfejsu używał Glade.
Na Twoim miejscu jeszcze dobrze zastanowiłbym się czy faktycznie interesuje Cię wyłącznie GTK+ czy może jednak dałbyś szanse Qt. Za czasów GTK+2 i Qt3 sytuacja była klarowna: GTK+ wyglądało już jako tako (pierwsza wersja była koszmarna, nie obsługiwała nawet Unicode), zaś Qt miał dosyć nieprzyjazną licencję. To ostatnie zmieniło się wraz z Qt4. Cyrki zaczęły się wraz z GTK+3. O ile GTK+2 istotnie miał swoje bolączki i wymagał zmian, tak rozwój GTK+3 był dla wielu naprawdę irytujący. W dużym skrócie rozchodzi się o to, że wszystko było robione pod dyktando GNOME, zaś jego deweloperzy nie liczyli się z nikim innym. Wszelkie argumenty zwyczajnie rozbijały się o ścianę. Do tego dochodzi nieprzemyślany cykl rozwojowy. Wydaje mi się, że Qt ma o wiele zdrowsze podejście pod tym względem i też nie ucieka się do bardzo radykalnych kroków. W każdym razie wielu programistów poważnie zastanawiało się nad migracją na Qt5. I żeby nie było, ta biblioteka też ma swoje bolączki, ale przynajmniej nie stara się wywracać świata do góry nogami i wmawiać wszystkim, że to nowy standard.
Jeśli chodzi o Qt to naturalnym językiem wydaje się być C++, ale i tutaj poleciłbym Pythona. PyQt5 jest naprawdę niczego sobie. Ponadto masz pewność, że nie jest to tylko chwilowa moda.
Do poważniejszych programów chyba C++ by się nadał
A takie rzeczy jak edytor do nieliniowej obróbki wideo, aplikacja do OCR czy menadżer e-booków są niepoważne? Bo wiesz, coraz częściej takie rzeczy powstają w Pythonie. Nie mówię, że wykorzystanie w takim wypadku C++ jest złe, ale inne języki pozwalają osiągnąć lepsze rezultaty w krótszym czasie. Osoba która zadała pytanie i tak nie będzie tworzyła na własną rękę kontrolki webowej, frameworka multimedialnego czy nawet biblioteki do wczytywania plików PNG. Zamiast tego skorzysta z gotowych komponentów. Do tworzenia takich aplikacji PyGObject czy PyQt5 nadają się jak ulał.
Jest stosunkowo prosty i sporo materiałów.
Nalegam, jeśli nie znasz języka, to chociaż nie opowiadaj ewidentnych bzdur.
Przeczytaj, a potem wybierz ten język który Tobie odpowiada:
Jeśli już coś polecasz to zadbaj o to, żeby to było w miarę aktualne. Linkowanie do artykułu sprzed kilkunastu lat nie służy niczemu dobremu. Poza tym bez urazy, ale jak tam widzę surowy opis języków a później kompletnie oderwany od tego zarys toolkitów. W praktyce wybór jednego ma ogromny wpływ na drugie, i należałoby to uwzględnić. Tak samo Hello World nie powie nam nic o złożoności C czy C++ w stosunku do C#.
Jeśli chcesz pisać w GTK to C, jeśli miałeś na myśli GTK+ to C++.
Nalegam, skoro nie znasz GTK+ to staraj się unikać takich wypowiedzi na jego temat. Plus w nazwie GTK+ wziął się stąd, że pierwotny toolkit został przeprojektowany na bardziej zorientowany obiektowo. Było to jeszcze przed wydaniem wersji 1.0 (przyznaję się bez bicia, że sam wiem o tym tylko z tego co przeczytałem, bo osobiście nie miałem styczności z aż tak dawną wersją). Nadal jednak cały czas wszystko było napisane w C. Od wersji 2.0 wszystko kręci się wokół GObject. Wraz z wersją 4.0 usunięto plus z nazwy.
Jeśli zaś chodzi o bindingi do C++, to należałoby tu wymienić gtkmm i spółkę (przede wszystkim libsigc++, cairomm, glibmm, pangomm i atkmm).
Gdyby GTK nie było wyznacznikiem to możesz to wszystko o czym wspomniałeś napisać w prawie dowolnym języku.
Tak samo można jeździć TIRem po zakupu do osiedlowego spożywczaka, ale nie jest to zbyt praktyczne i w rzeczywistości nikt tak nie robi. Tworząc typową aplikację nie chcesz wynajdywać koła na nowo tylko zazwyczaj starasz się skorzystać z gotowych komponentów, np. kontrolki webowej, frameworka multimedialnego czy czegoś do sprawdzania pisowni. W zależności od tego co robi twoja aplikacja, możesz szukać API które pozwoli Ci w prosty sposób na importowanie i przetwarzanie plików PDF, tworzenie dokumentów ODF czy dostęp do skanera. Wybór toolkitu i języka w dużej mierze determinuje masę innych rzeczy. Ba, już sam wybór biblioteki graficznej zawęża nam wybór języka (i na odwrót), bo istnieją lepsze i gorsze (a niektóre wręcz fatalne) bindingi. Zresztą, ani GTK+ ani Qt nie możemy obecnie traktować wyłącznie jako toolkitu. To coś znacznie więcej, co pociąga za sobą chociażby to jak będziemy podchodzili do zagadnień sieciowych, np. GIO w GTK+ czy Qt Network w Qt. Tak samo wybór Pythona będzie się zapewne wiązał z wykorzystaniem Pillow jako biblioteki do manipulacji na bitmapach.
To wszystko nie żyje w próżni. Mamy tu raczej do czynienia z całym ekosystemem bardziej i mniej połączonych ze sobą elementów. I właśnie tak należy do tego pochodzić.
Prawdę mówiąc jeśli pragnie szybko i bezboleśnie tworzyć aplikacje typu notatnik, kalkulator, odtwarzacz czy przeglądarkę i niema nacisku na bardziej ambitne projekty, to polecam pobawić się tym:
https://www.pilotlogic.com/sitejoom/DP: https://www.dobreprogramy.pl/CodeTyphon,Program,Windows,36735.html
cytat z opisu:
Aktualnie obsługiwane są następujące typy interfejsów: WIN32 GDI, GTK+ 1.2.x (Unix, Mac OS X), GTK+ 2.x, Qt 4 (C++) i Windows CE.
Na pewno mu to nie zaszkodzi a przynajmniej nie zrazi się klepaniem “hello world”
No to lecimy po kolei:
- GTK+1 to już totalny archaizm, nie wspiera nawet Unicode.
- GTK+2 jest uznawane za przestarzałe. Nie posiada wsparcia dla Portal API i Waylanda. Nie obsługuje także HiDPI ani przezroczystości. Ponadto skorzystanie z kontrolki webowej jest problematyczne, delikatnie mówiąc. WebKitGTK jest dziurawy jak sito i z tego względu lata temu został zbanowany w większości szanujących się dystrybucji. WebKit2 zaś wymaga użycia GTK+3.
- Qt4 jest w podobnej sytuacji co GTK+2.
Oczywiście, wspierają GTK+3 czy Qt5, które jak najbardziej można uznać za nowoczesne, no ale wypadałoby o nich napisać. W pewnym uproszczeniu mamy tu bowiem do czynienia ze zwykłym FPC i Lazarusem, a co za tym idzie LCL, ze wszystkimi jego bolączkami. To wszystko ładnie wygląda na papierze, ale w praktyce rozkracza się ze względu na zawiłe różnice pomiędzy różnymi platformami oraz zwyczajne błędy i niedoróbki, które trudniej obejść mając przed sobą kolejną warstwę abstrakcji.
Poza tym jeśli ktoś chce poznać GTK+, to przez LCL na pewno tego nie dokona.
W każdym razie zamiast polecać egzotyczne IDE, którego samemu do końca się nie zna, lepiej zasugerować coś z czego faktycznie się korzysta:
- GNOME Builder bądź Anjuta i Glade dla aplikacji GTK+
- KDevelop bądź Qt Creator dla Qt
Oczywiście, to nie jest tak, że te rozwiązania są jedyne słuszne. Zawsze można użyć Eclipse, jednego z IDE od JetBrains (w zależności od wybranego języka) czy Visual Studio Code. Myślę jednak, że osobie która dopiero raczkuje, o wiele bardziej przystępne wyda się coś, co zostało stworzone z myślą o danej platformie/toolkicie.
Nie, oficjalnie biblioteka jest tylko pod C++, można go używać na każdej platformie jedynie, a to nie jest jednoznaczne z językiem.
I czym to się niby różni od GTK+, poza tym, iż ta biblioteka jest w napisana C z użyciem GLib? Tak samo jak w przypadku GTK+, pod Qt również masz dobre i złe bindingi. PyQt5 jest całkiem niezłe i powstało w tym sporo aplikacji, ale za to już bindingi do Mono/.Net Framework wyglądały dobrze już tylko na papierze. Taki QtSharp, pomijając już nawet przywiązanie autorów do Windows, ustępował na każdym polu Gtk#. Może w przypadku Qml.Net wygląda to lepiej, bo to nie tyle binding Qt co QML, ale z tego co pamiętam problemem była tam ekstremalnie uboga dokumentacja, przez co to rozwiązanie nie zyskało dużego uznania w świecie aplikacji graficznych dla Linuksa.
Owszem. Im bardziej nielogiczna struktura tym lepszy pseudokod 
Te projekty żyją? Od 2ch lat sprawiają wrażenie martwych/wygasłych.
Chyba nie zauważyłeś, ze pytanie o “cool” język powtarza się tysiące razy i nic z tego nie wynika.
99% pytających swoją przygodę kończy na “Hello Word” ewentualnie w momencie kiedy trzeba rozróżnić stała od zmiennej.
Aktualne ? Do czego ?
Rozumiem, że do odczytu pliku i wyświetleniu go trzeba użyć zaawansowanej techniki programowania i koniecznie musi być to technologia z pierwszej top 5.
Sorry… ale oddychaj, szkoda oczu.
Nie, ale nie musi to być też coś martwego typu turbo Pascal.
Tak jak z językiem obcym: jak uczyć się to chińskiego, a nie dialektu ningbo, który rozumie marne 5 milionów osób tylko w tym mieście.
Turbo Pascal to Borlandowska implementacja Pascala dla Dos . - Dawno jest trupem.
Natomiast Lazarus czy bazujący na Lazarus CodeTyphon to zintegrowane środowisko IDE.
Wzorowane na Borlandowskim Delphi. - to jest Object Pascal.
Twierdzisz, że jest to trup… To czemu ?
Lazarus Release 2.0.6 - November 01, 2019
CodeTyphon Studio At 08-Jan-2020 we released a new version 7.00
Embarcadero Delphi - na bierząco coś nowego.
Przykładowe forum:
https://4programmers.net/Forum
No jak na martwy język a 150 tyś postów to tylko C/C++ go przebija bo ma o 7 tys więcej.
Przykładowy program napisany w Lazarusie:
https://www.dobreprogramy.pl/Double-Commander,Program,Windows,33197.html
Data aktualizacji: 2 lutego 2020
Praktycznie potrafi to samo co płatny Total Commander.
Originally coded using Delphi, latest Windows 64-bit versions were done with Lazarus.
Nie rozumiem tego hejtu na pogrobowców Pascala - to są cały czas rozwijane języki/środowiska/technologie.
Bo żyją tym co im pokazali w szkole…
Dziś to wygląda tak:
A nawet tak poważny sprzęt za kilkanaście milionów złotych ma napisany soft w Delphi.
Chyba nie zauważyłeś, ze pytanie o “cool” język powtarza się tysiące razy i nic z tego nie wynika.
99% pytających swoją przygodę kończy na “Hello Word” ewentualnie w momencie kiedy trzeba rozróżnić stała od zmiennej.
Tu nie chodzi o to co jest teraz na topie i o czym się mówi, bo moda może szybko przeminąć. Tu chodzi o to co jest faktycznie powszechnie wykorzystywane i dobrze wspierane.
Aktualne ? Do czego ?
W artykule który został podlinkowany była mowa o wxWidgets 2.6 i 2.8. To było dobre, ale jakieś 8 lat temu. Dzisiaj te gałęzie są już martwe, bo zostały zastąpione przez wxWidgets 3.x. Jak wspominałem, wxGTK2 jeszcze jako sobie radzi, pomijając przestarzały toolkit, natomiast wxGTK3 jest strasznie niedopracowane. Miałem styczność różnymi projektami które próbowały migrować z wxGTK2 na wxGTK3 i niestety, ale layout się strasznie przy tym rozjeżdża. Ludzie myślą, że skoro pod spodem jest Gtk+3 to nie będzie problemów z obsługą Wayland, a tu zonk, bo np. wykorzystanie wxGLCanvas to uniemożliwia. Podobnie z HiDPI - wiele wartości jest wpisanych na sztywno albo zwyczajnie nie działa to jak trzeba. Oczywiście, można zgłaszać błędy, ale czy nie lepiej korzystać z czegoś co faktycznie jest dopracowane, jeśli mamy taką możliwość?
Stabilną gałęzią wxWidgets jest 3.0, ale budując pod nią taki Aegisub może Cię czekać niemiła niespodzianka przy wprowadzaniu znaków Unicode. Ten problem znika przy 3.1, wersji rozwojowej, ale tam z kolei przez długi czas trzeba było ręcznie łatać bibliotekę, bo w module wxTranslations znajdował się dosyć poważny błąd, który doprowadzał do crashowania aplikacji która z tego korzystała. Mógłbym tak jeszcze długo wymieniać, ale wydaje mi się, że już uargumentowałem to wystarczająco dobrze.
Wracając do głównego tematu, FPC na Linuksie jest praktycznie martwe. Z bardziej znanych aplikacji korzysta z tego jedynie PeaZip oraz Double Commander, no i rzecz jasna sam Lazarus. Niegdyś używały tego easyMP3Gain i WinFF, ale realny rozwój tych projektów zatrzymał się lata temu.
W każdym razie nie masz tego ani w runtime Freedesktop ani w GNOME czy KDE. Żeby w ogóle myśleć o budowaniu pakietu flatpak dla takich aplikacji trzeba by najpierw stworzyć runtime extension dla Freedesktop. Jak to w przypadku kompilatorów bywa, do zbudowania fpc 3 potrzebny jest… fpc 3. Musisz więc zacząć od bootstrappingu. Sądzisz, że początkującej osobie będzie chciało się w to bawić?
W przypadku PyGObject nie musisz się o nic martwić, bo to jest już w GNOME. Moduły do innych zależności stosunkowo łatwo da się wygenerować przy wykorzystaniu flatpak-pip-generator (mała uwaga: nie zadziała to dla PyQt5 - tam trzeba ręcznie stworzyć moduł do niego i SIP).
GCC czy Clang są zawarte we Freedesktop, zaś w GNOME dodatkowo znajdziesz valac. Jeśli chodzi o biblioteki, to GTK+3 jest w samym Freedesktop, Qt5 zaś w KDE. Z kolei gtkmm z zależnościami (libsigc++, cairomm, glibmm, pangomm i atkmm) musisz już sobie zbudować na własną rękę, ale to nie jest duży problem.
Rozumiem, że do odczytu pliku i wyświetleniu go trzeba użyć zaawansowanej techniki programowania i koniecznie musi być to technologia z pierwszej top 5.
Do otwarcia pojedynczego pliku w miarę możliwości wypadałoby wykorzystać GtkFileChooserNative, czy - mówiąc bardziej ogólnie - org.freedesktop.portal.FileChooser.
https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html
https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.FileChooser
Czy pod LCL nie będzie z tym problemu? Szczerze mówiąc, nie wiem. Pytanie czy Ty wiesz.
Poza tym, tak jak już wcześniej mówiłem, używając LCL za cholerę nikt nie nauczy się GTK+, a o to zdaje się pytał autor.
Milczeniem pominę już to, jakie szanse są na znalezienie pracy związanej z programowaniem w języku ObjectPascal, a jakie w C, C++ czy Python. Oczywiście, pod względem zarobkowym mógłbym wspomnieć o JavaScript i Node.js, ale ciężko to pogodzić z tworzeniem aplikacji GTK+ dla Linuksa. Nie mówię, że to absolutnie złe, ale mimo wszystko jest to w pewnym sensie ciało obce. Z komercyjnego punktu widzenia wygląda to wyśmienicie, ale z perspektywy użytkownika oczekującego głębokiej integracji z interfejsem systemu już tak średnio.
Te projekty żyją? Od 2ch lat sprawiają wrażenie martwych/wygasłych.
Generalnie rzecz biorąc tak, chociaż oczywiście czuć parcie na GNOME Builder. Nie każdy go jednak akceptuje. Oczywiście należałoby zaznaczyć, że chociaż aktualna wersja Anjuta to 3.34.0 wydana raptem parę miesięcy temu, to realny rozwój znacząco przystopował lata temu, właśnie na rzecz GNOME Builder. Co do Glade, to w GNOME Builder zostało ono zintegrowane z aplikacją. W środowiskach które nie zapewniają takiej integracji używa się po prostu samodzielnego Glade. W zasadzie nie ma innego sensownego sposobu na projektowanie interfejsu dla aplikacji GTK+. No chyba, że nie używasz bezpośrednio tej biblioteki, tylko poprzez np. wxWidgets/wxGTK (wxGlade - to sobie odpuść, wxFormBuilder, wxCrafter) czy Eto.Forms (Eto.Forms Visual Studio Addin).
Z bólem serca muszę Ci przyznać rację.
Z perspektywy osoby która robi Winformsy w dotnecie, jestem przerażony co za sajgon jest pod linuxem 
Dyskusja trwa, a autor tematu ani razu się nie wypowiedział (nie wliczając pierwszego psota). Wygląda to jak jakiś temat do rozpoczęcia g-burzy 
To nie jest temat do gówno burzy.
Załóżmy, że przerobiłem kilka książkowych kursów języka C++. Czy potrafiłbym już napisać coś konkretnego?
A może zamiast pisać swoje programy od zera, to lepiej robić forki istniejących już programów?
Mam po prostu swoją wizję, jak powinno wyglądać środowisko graficzne, tylko nie wiem ile czasu praktyki mi potrzeba, by myśl przerobić w czyn…
Zacznij pisać. Bez tego nie dowiesz się.
1 polubienie