Poszukuję bibliotek GUI do c++, wiem, że w googlach, można wiele odnaleźć, ale chciałbym usłyszeć wasze propozycji, dotyczące biblioteki GUI
Np.
-
Windows Form w VC
-
QT
-
GTK+
-
wxWidgets
Jednak zanim zabierzesz się za nie, poznaj WinAPI, bo to podstawa, którą powinieneś znać pisząc GUI-e w C++.
Chyba że piszesz pod linuxa.
WinAPI podstawą? WinAPI to relikt, którego stosuje tylko wtedy gdy naprawdę trzeba, albo by opakować to w cokolwiek innego (np. wxWidgets). Czy na Linuksie tworzy ktoś okienka w gołym X11? Używa się tylko wtedy, gdy nie ma innej możliwości.
Qt (nie QT!) jest IMO najłatwiejszy i najbardziej opłacalny w nauce.
GTK+ o ile na Linuksie to dość dobry wybór, to do dziś nie wiem jak go zapędzić do działania na Windowsie (może po prostu jestem leniwy i gdy sudo apt-get install libgtk3-dev nie działa, nie chce mi się ręcznie biblioteki konfiguować).
WinAPI to podstawa windowsa, parę lat temu był tylko on.
Może się w nim już nie pisze, ale to nie znaczy że nie jest potrzebny, każdy programista programujący na windowsa powinien go znać.
Dlatego że przy nim uczy się podstaw i logiki programowania.
Zgodnie z maksymą “Poświęcę trzy miesiące na naukę czegoś, do czego potem z radością nie będę wracał, bo są inne, prostsze i przyjemniejsze rozwiązania”, przez którą na niektórych uczelniach nadal katują Pascala.
Twoja maksyma, nie moja.
Po za tym, ja piszę żeby chociaż poznał podstawy i logikę WinAPI, a nie od razu uczył się go na pamięć!
Bo wtedy łatwiej będzie mu później cokolwiek zrobić lub zrozumieć.
Tylko że tam wszystkiego trzeba się uczyć na pamięć, nazwy pisane samymi wielkimi literami, tajemnicze skróty albo długie nazwy, a stworzenie prostego okna to 100 linii bezużytecznego kodu które da się zastąpić 10 linijkami w Qt dając znacznie większą funkcjonalność.
Warto rozumieć co się z własnym kodem dzieje w trakcie kompilacji, a nie jak dana biblioteka funkcjonuje od środka (są przypadki kiedy to jest potrzebne, ale początkujący nie ma co sobie tym głowy zawracać, będzie potrzebował – zajrzy). Może każesz mu też się nauczyć budowy procesora x86? Przecież to absolutna podstawa programowania na PCty. Wtedy będzie mu najłatwiej zrozumieć czemu program się wysypuje, albo coś bardzo długo liczy.
A jeżeli ktoś zacznie uczyć się Javy od czytania bajtkodu, to potem będzie mógł lepiej zrozumieć pętle. Fakt, że na cały proces poświęci pół roku (a nie 10 minut jak wszyscy), jest już mało istotny.
Błąd. Win32API trzyma się narzuconych wytycznych i wszystko “trzyma się kupy”(za wyjątkiem zaszłości historycznych(które w sumie też się kupy trzymają) i błędów ludzkich). Skróty są tylko przy typach(notacja węgierska), długie nazwy nie są złe, bo od razu wiadomo, co dana funkcja robi. “Nazwy pisane samymi wielkimi literami” to makra(wyjątek - makra na funkcje *A/*W). “Na pamięć” nie trzeba się niczego uczyć(z wyjątkiem kilku reguł), tylko warto mieć pod ręką dokumentacje(kompatybilność wsteczna).
Te 100 linii nie jest takie bezużyteczne, bo pozwala na dużo. Kwestia taka, czy to “dużo” nam jest potrzebne, ale to już inna bajka.
Nie porównuj nauki WinAPI w C++ do nauki bajtkodu w Javie.
Bo to tak jak byś porównywał Angielki do Chińskiego.
Jeśli umiałbyś dobrze szukać i byś sobie to zapisywał, to byś musiał znać na pamięć tylko parę rzeczy.
Że niby dlaczego?
Możesz siedzieć paręnaście minut i naklepać okienko w WinAPI albo zrobić to w paręnaście sekund w Qt.
Możesz siedzieć paręnaście minut i naklepać HelloWorld w bajtkodzie albo zrobić to w paręnaście sekund w Javie.
Nauczysz się bajtkodu i będziesz go przy programowaniu w Javie używał w ekstremalnie rzadkich sytuacjach.
Nauczysz się WinAPI i przy programowaniu w Qt będziesz tego używał raczej rzadko… o ile nie pracujesz na Linuksie, Maku, Androidzie, IOS itd., bo wtedy już w ogóle.
Tu nie kwestia zapisywania i używania starych kodów, tylko samego faktu że jest go strasznie dużo i robi to samo co parę linijek w Qt. Sprawia że kod staje się nieczytelny i pracuje się nieefektywnie, łatwiej popełnić błąd. A Assemblera znasz? Do niego sprowadza się C++.
IOS to system Cisco, tak, wiem, jestem nazewniczym nazistą.
Assembler i bajtokody przydają się przy analizie kodu. Czasem coś nie dzieje się po naszej myśli (jak np. używane inkrementacje w wyrażeniach), wtedy sięga się po bajtokod/assembler i bada. Albo jak się chce sprawdzić, czy kompilator usunął z kodu rekurencję, albo cokolwiek innego – przydatne, ale nie dla każdego.
Znam Asemblera i wole go od każdego innego języka.
No i on jest dla mnie bardziej zrozumiały niż C++ z Qt, a dlatego że jest prosty, logiczny i czytelny.
Dlatego bo podałeś że ktoś zacznie uczyć się bajtkodu, a nie będzie znał podstaw Javy.
W WinAPI nie da się pisać bez używania C++ lub jakiegoś innego języka.
Więc co ma do rzeczy WinAPI do bajtkodu?
A po za tym 5-minut do 50-sekund to nie duża różnica, a szybszy i tak będzie program napisany w WinAPI.
Znam Asemblera i wole go od każdego innego języka.
No i on jest dla mnie bardziej zrozumiały niż C++ z Qt, a dlatego że jest prosty, logiczny i czytelny.
Owszem, logiczny i zrozumiały – na małym fragmencie kodu. Dam ci pewien mój stary fragmencik kodu Asma na ARMa (czytelniejszy od x86, pisany ręcznie), ciekawe ile godzin zajmie ci znalezienie o co w nim w ogóle chodzi. Młotek też jest prosty, podobnie ręczna wiertarka, ale kto dzisiaj używa w pracy ręcznej wiertarki, skoro są nieco trudniejsze w obsłudze wiertarki elektryczne, ale pozwalające pracować wydajniej?
Tak, każdy użytkownik widzi różnicę pomiędzy interfejsem rysującym się 1ms a 5ms, przecież to 5-krotna różnica, jak można tego nie zauważyć! Pomińmy już fakt, że takiej różnicy nie ma. To co ty klepiesz ręcznie w WinAPI jest już napisane w takim Qt gotowe, do wywołania jedną metodą.
Szukasz oszczędności nie w tych miejscach.
Problem nie w tej różnicy czasu, tylko możliwości popełnienia błędu i ewentualnego znalezienia go. A poza tym: czas = pieniądz.
-
Litości, mówimy o prostym okienku. Jak bardzo zauważalnie szybsze będzie okienko z WinAPI od każdego innego?
-
Nauka Javy od bajtkodu to głupota. Nauka Qt od WinAPI to IMO jeszcze większa głupota. Cała Java opiera się na bajtkodzie i istnieje szansa, że umiejętność czytania takowego się zwróci. Qt (z tego, co mi wiadomo) na WinAPI się nie opiera i łączyć je można jedynie na Windowsie, gdzie Qt jest raczej średnio popularne i wykorzystywane głównie przez multiplatformowe aplikacje tworzone początkowo z myślą o Linuksach.
Assembler jest czytelny nawet na milionowym kodzie, tylko trzeba myśleć.
A po za tym u mnie liczy się szybkość i maksymalne osiągnięcia programu, a nie szybkość pisania go,
nawet jeśli będzie to 10-sekund szybciej.
A czemu nauka Qt od WinAPI?
Przecież to oddzielna biblioteka.
A i jeśli on zrozumie WinAPI to z Qt pójdzie mu migiem.
Robicie burze w szklance wody, bo ja wymieniłem żeby zrozumiał trochę WinAPI przed naukom innych.
I niby to jest warte takich kłótni?
Każdy będzie miał inne zdanie i będzie się jego trzymał.
Tak jak w tym temacie mnóstwo kłótni o nic, sam nie mieszałem się tam bo wiedziałem co będzie.
Nie no, po prostu powiedziałeś głupote i dlatego wszystkich to razi… Proponuje zacząć naukę binarnego, na pewno pomoże Ci napisać wydajne okienka.
Powiedz mi w jaki sposób poznanie winAPI ułatwi zrozumienie Qt, albo innych bibliotek?
Możesz mi powiedzieć jakie programy napisałeś w assemblerze? Jaki był najbardziej złożony?
Sam popełniasz głupotę, bo rozpalasz zagaszony piec.
Nie biorąc udziału w wcześniejszej dyskusji, wtrącasz teraz nosa, po co?
Na pewno jest grupa osób która by poparła moje słowa.
Kod binarny będzie jedynym językiem w jakim ludzkość będzie programować, ale to dopiero
za jakieś tysiąclecie bo dopiero wtedy ogarniemy jego złożoność i potęgę, więc o nim nie wspominaj.
Ułatwi i to bardzo, tak jak ułatwiło, to i kiedyś mnie.
Gdy zobaczyłem po raz pierwszy Qt pomyślałem że to jakieś żarty że programowanie staje aż tak łatwe.
A co do programów nie pamiętam bo programowałem w asmie jakieś 10-lat temu,
potem nadszedła całkowita era programowania wysokopoziomowego i już musiałem przejść na nie ze względów pracy.
Pamiętam jeszcze że z zespołem programowałem maszyny itp.
Elik, ten twój piec przygasł kiedy wungiel sie jeszcze nie wypalił… W kadym razie widać, że twoim kryterium oceny języka jest możliwść zoptymalizowania w nim kodu. Wolałbyś, żeby Crysis był napisany w asm przy tym pożerając niebotycznie większe pieniądze na programowanie i przez to działał dajmy na to, o 50% szybciej? Ja wolę mieć tani dobry, tani produkt stworzony z małym narzutem zbędnej pracy. Skoro specjalnei przesiadłeś się na programowanie wysokopoziomowe to sam powinieneś do tego wniosku dojsć.
Któż wątpi, że w binarnym da się zrozbić bardzo dużo? Paradoksalnie w jezykach nieco wyższego poziomu da się zrobić jeszcze wiecej, bo zanim napiszesz parser xml w asm, to w C/C++ masz instytucje wyrażeń regularnych i wielu bibliotek… Skoro ASM jest tak potężne, to podaj mi przykład systemu operacyjnego, który jest w znacznym stopniu w nim napisany. Pomimo eoretycznie większego zakresu możliwości asm wychodzi na to, że praktycznie ma on możliwości mniejsze niż język wyższego poziomu.