Cześć.
Na dziś dzień, gdy potrzebuje stworzyć jakąś GUI aplikację sięgam do C++ i Qt. I tak to się toczy od kilkunastu lat. Kiedyś próbowałem sił z PyQt i jako prototypowanie sprawdza się całkiem dobrze. Jednak czas potrzebny by taki prototyp przenieść na C++ sprawił, że po kilku próbach odpuściłem.
W czym innym pisać? Jest jeszcze QML - nie ruszałem tego. Brzmi to jak osobna warstwa, szybki w pisaniu frontend.
W .Net i Javę dopiero bym wszedł. Siedzę głównie na Linuxie - co sprawia że .Net staje się trudniejszy (od biedy Win na VM i mogę używać). W co iść? Jakie frameworki lub biblioteki? Qt twardo i skutecznie dostarcza pełną funkcjonalność od kilkunastu lat. O Javie czytam, że jest zmienna i pływa, że Fusion, AWT i inne swingi, a co drugi komentator w necie wieszczył koniec jednego, niestabilność drugiego, kłopoty trzeciego, niespójność stylistyczna i kolorystyczna z OSem, czy wręcz brzydota niektórych frameworków. (np)
.NET to chyba tylko WPF (co wygląda bardzo podobnie do QML).
Co radzicie? Co jest stabilne i przyszłościowe?
Przyszłościowe są aplikacje webowe.
Webowość kojarzy mi się od razu z HTML+CCS+(coś skryptowego).
Są jakieś bardziej ludzkie rozwiązania? Gdzieś obiło mi się o uszy Node.Js/webkit (podobno spotify w tym napisano). Na ile to się różni od w/w sekwencji? Czy oferuj coś na poziomie widgetów z Qt?
Proszę rozwiń.
Pisze si rowniez duzo kodu po stronie serwerowej -> backend.
Korba napisał(a):
Webowość kojarzy mi się od razu z HTML+CCS+(coś skryptowego).
Są jakieś bardziej ludzkie rozwiązania? Gdzieś obiło mi się o uszy Node.Js/webkit (podobno spotify w tym napisano). Na ile to się różni od w/w sekwencji? Czy oferuj coś na poziomie widgetów z Qt?
Proszę rozwiń.
Node.js to framework dla java scriptu. Tak czy siak bez HTML i CSS się nie obejdzie jeśli chodzi o webówkę. Co do tych widgetów z Qt, wszystko tak na prawdę ma swoje odzwierciedlenie w html'u (zwłaszcza 5!).
Ja (na razie hobbystycznie) piszę sobie w Scali.js i świetnie działa. Wcale nie trzeba pisać w językach skryptowych, by mieć aplikację na przeglądarkę.
HTML/ CSS/ DOM etc nie są takie złe jeśli zaprzęgnie się Bootstrapa, Reacta i tym podobne rzeczy.
Zaletą webowych aplikacji jest to, że użytkownik nie musi niczego instalować czy aktualizować (oprócz przeglądarek, które to mają wbudowane mechanizmy aktualizacji), a same przeglądarki są mocno osandboxowane.
Zanim nabierzesz doświadczenia to pewnie wiele się zmieni, ale trend się nie odwróci - aplikacji desktopowych jest coraz mniej, a coraz więcej jest webowych.
Chcecie powiedzieć, że nawet jeśli apka będzie odpalana przez usera do przetworzenia np. logu, narysowania jakiegoś diagramu na jego podstawie wraz z jakąś interaktywnością - to pisze się to jako stronę?
Krwawy Młot: zgadzam się, backend to już inne podejście. Czy to C++, czy coś pośredniego (np. Javy/.net po np. natywne skryptowe języki)
to pisze się to jako stronę
Tylko nie jak stronę o której myślisz.
Tak to wygląda: http://jsfiddle.net/guillaumemaka/jwm6k66c/
Więc właściwie to powinieneś być zadowolony, w końcu masz do dyspozycji coś ala widżety qt ;)
Pisząc widgety Qt mam na myśli gotowe standardowo zachowujące się elementy. Nie trzeba przecież za każdym razem od nowa wymyślać koła i np. rysować button po swojemu.
Tego mniej więcej oczekuje. Czegoś co przyzwoicie i wygodnie pokaże to co logika wyliczy.
Dziękuję spartanPAGE za link do demonstracji.
do reacta jest coś takiego http://www.material-ui.com/#/ , ale w sumie i tak nie musisz "wymyślać koła", nawet jak nie użyjesz reacta to i tak jest masa gotowców, a i każdy kod źródłowy(html+css+js) możesz sobie podejrzeć i skopiować i zmienić dowolnie :D
W czym innym pisać?
Może zastanów się, co ci się w Qt nie podoba? Czy po prostu znudziło się?
Korba napisał(a):
Chcecie powiedzieć, że nawet jeśli apka będzie odpalana przez usera do przetworzenia np. logu, narysowania jakiegoś diagramu na jego podstawie wraz z jakąś interaktywnością - to pisze się to jako stronę?
Tak.
Po pierwsze jeśli wystawisz na serwerze odpowiednie endpointy to możesz robić dokładnie to samo co mógłbyś robić zwykłą apką - w końcu logika i interakcja z otoczeniem nie musi być zawarta w całości w przeglądarce, pewne rzeczy mogą się dziać na serwerze. A serwer można nawet i lokalnie postawić. Chociaż nie trzeba. Są aplikacje, które kiedyś wydawałyby się lekko absurdalne, czyli np internetowe programy biurowe zastępujące Worda czy Excela. Niby operują na dokumentach, ale nie trzeba ich przecież trzymać cały czas lokalnie na dysku, nie? Robi się kopię w chmurze i wszystko gra.
Po drugie interaktywne diagramy można bezproblemowo robić w przeglądarce. Popatrz sobie na d3.js: https://d3js.org/ Można bawić się shaderami w WebGLu: https://www.shadertoy.com/ Możesz nawet uruchomić w przeglądarce Windowsa 95 skompilowanego EmScriptenem (poguglaj to sobie), chociaż jest to sztuka dla sztuki. Możliwości przeglądarek stale się zwiększają i jest coraz mniej rodzajów aplikacji do których webowe technologie się nie nadają.
Nadawać to się może nadają, tylko czy to takie wygodne, kiedy na siłę tworzy się aplikację webową zamiast normalnego programu?
Webowe Wordy i Excele to dla mnie raczej ciekawostka niż nadające się do użytku narzędzie.
A jakie masz konkretnie zastrzeżenia? Wynikają one z tego że aplikacja jest przeglądarkowa czy może po prostu internetowy Office nie jest jeszcze tak rozwinięty jak ten stacjonarny?
Internetowe apki nigdy nie będą tak szybkie i wydajne, jak desktopowe. Głównym problemem jest nie tylko pośrednik (czyli sieć), ale też bezstanowość protokołu HTTP. Tak mi się wydaje.
@teez Nie wprowadzaj innych w błąd. node.js to nie framework. To backendowe środowisko javascriptu. W skrócie pozwala na odpalenie na serwerze javascriptu który będzie serwował treść. Chociaż dla osoby mało doświadczonej bym go nie polecał ze względu na bezpieczeństwo.
Co do samego tworzenia frontendu w aplikacjach desktopowych jest to fajne z 3 powodów.
- Piszesz raz i działa. Nie musisz pisać osobnej aplikacji na pc, mac, android, ios. Czyli masz parę razy mniej pracy co przekłada się na pare razy mniejszy czas, co daje parę razy mniejszy koszt.
- Kompatybilność. Nie interesuje Cię czy user ma system 32bit czy 64bit. Czy może jeszcze jakiś dziwny typ procesorów pod który musiał byś kompilować.
- Łatwość tworzenia. Do javascrptu masz miliony pluginów. Potrzebujesz zrobić graf? Piszesz <script src="graf.js"> Wrzucasz mu dane i masz łady graf. 2 minuty roboty.
Chociaż wiadomo że nie jest to rozwiązanie dobre do wszystkiego. Bardzo zasobożerne aplikacje, lub takie w których liczy się ich wydajność czy stabilność działania lepiej naklepać w jakimś c++/c#.
Takie pytanie jeszcze do innych. Czy c# lub java mają cos co w androidzie nazywa się webview? I jeśli ma to jak to wygląda wydajnościowo?
Juhas napisał(a):
Internetowe apki nigdy nie będą tak szybkie i wydajne, jak desktopowe. Głównym problemem jest nie tylko pośrednik (czyli sieć), ale też bezstanowość protokołu HTTP. Tak mi się wydaje.
Jaka bezstanowość? Stan można spokojnie przechowywać:
- sesje są do przechowywania stanu po stronie serwera,
- po stronie klienta mamy local storage,
Aplikacje w JS mogą być spokojnie offline i mieć kupę stanu.
Jak jesteś dobry w QT to zostań przy QT. 11 lat doświadczenia to sporo :) Zostań przy QT, doucz się QML i jest dobrze.
Jeśli chodzi o aplikacje desktopowe to możliwości jest mnóstwo, nowością jest chyba electron (JS).
Azarien napisał(a):
Nadawać to się może nadają, tylko czy to takie wygodne, kiedy na siłę tworzy się aplikację webową zamiast normalnego programu?
Webowe Wordy i Excele to dla mnie raczej ciekawostka niż nadające się do użytku narzędzie.
Pełna zgoda!
Niektóre aplikacje zostaną desktopowe na wieki, bo ich przeniesienie do weba nie ma sensu, nic nie daje. Przykładowo wiele aplikacji inżynierskich typu CAx.
Jeżeli jakaś aplikacja nie musi być webowa to tak powinno zostać. Pchać wszystko w przeglądarkę to wg mnie głupota.
Wibowit napisał(a):
Juhas napisał(a):
Internetowe apki nigdy nie będą tak szybkie i wydajne, jak desktopowe. Głównym problemem jest nie tylko pośrednik (czyli sieć), ale też bezstanowość protokołu HTTP. Tak mi się wydaje.
Jaka bezstanowość? Stan można spokojnie przechowywać:
- sesje są do przechowywania stanu po stronie serwera,
- po stronie klienta mamy local storage,
Aplikacje w JS mogą być spokojnie offline i mieć kupę stanu.
HTTP jest protokołem BEZSTANOWYM. I kropka. Żeby z tym walczyć robi się sesje. Zgadza się. I o tym mówię, to jest dodatkowy krok, który trzeba wykonać przy każdej zmianie (po stronie serwera). To są dodatkowe np. zapytania do bazy danych, których nie ma w aplikacjach desktopowych. W związku z czym apka internetowa nie będzie tak szybka i wydajna. I o tym mówię.
Jeśli czyste HTTP ci nie wystarcza, to WebSocket daje ci trwałe połączenie.
Wibowit napisał(a):
Jeśli czyste HTTP ci nie wystarcza, to WebSocket daje ci trwałe połączenie.
Ale tu nie chodzi o połączenie. Tylko o STAN aplikacji. Dajmy na to masz koszyk w sklepie. Zmieniasz stronę. I co się dzieje teraz? Koszyk musi zostać zapisany (do pliku albo do bazy danych), następnie podczas ładowania nowej strony odczytany.
W aplikacji desktopowej koszyk po prostu jest w pamięci. Siedzi tam cały czas. Oczywiście desktop nie nadaje się do sklepu internetowego, ale to taki pierwszy, lepszy przykład.
@Juhas Ok, masz rację. Ale jeden get który będzie pobierał dane z pliku, bazy czy pamięci jakoś bardziej chce mi się pisać niż aplikację od nowa jeśli zapadnie decyzja o przeniesieniu jej na np. maka.
Juhas napisał(a):
Koszyk musi zostać zapisany (do pliku albo do bazy danych), następnie podczas ładowania nowej strony odczytany.
Nie musi, równie dobrze cały czas może siedzieć w RAMie.
Można pisać równie fajne apki w stacku webowym, de facto atom jest najlepszym przykładem aplikacji deskopowej ( został stworzony z pomocą electrona ) korzystającej pod spodem z przeglądarki. I to się coraz bardziej rozwija, coraz więcej powstaje takich apek, dzisiaj widziałem na githubie coś takiego https://github.com/pubkey/rxdb . Baza danych która jest przewidzana pod apki które mają być offline
NickOver napisał(a):
@Juhas Ok, masz rację. Ale jeden get który będzie pobierał dane z pliku, bazy czy pamięci jakoś bardziej chce mi się pisać niż aplikację od nowa jeśli zapadnie decyzja o przeniesieniu jej na np. maka.
OK, jest to rozsądne, jeśli nie zależy Ci na szybkości/wydajności. Ale, co jeśli:
- klient będzie miał awarię sieci? - aplikację desktopową odpali, internetowej już nie
- będzie trzeba zrobić coś na jakiś urządzeniach? Owszem, jakoś da się to webowo zrobić. Ale pewnie nie zawsze i nie wszystko. W tej kwestii się nie wypowiadam, bo nie wiem jak to jest do końca. Wiem, że np. taka aplikacja nie skorzysta już z większości czujników w telefonach.
Dziękuję Wam za sporo wiedzy co i jak można zrobić.
Jestem fanem gier planszowych z naciskiem na bitewno-wojenne czy empire-building. Z kolegą mam zamiar zagrać w StarFire, który on zdefiniował jako 'sztabówka z potężnym excelem'. Więc pierwsza moja myśl - Qt GUI. Ale może da się lepiej. Może da się też na wiele platform. A teraz jeszcze dajecie wskazówki na JS i Web.
Hmm, przyjmując jakieś wspólne i bezpieczne miejsce do przechowywania stanu gry (np. github czy bitbucket :) można by z tego wykroić ciekawy projekt.
Juhas napisał(a):
- klient będzie miał awarię sieci? - aplikację desktopową odpali, internetowej już nie
Jak będzie miał awarię sieci, to generalnie mało kto popracuje.
Wiem, że np. taka aplikacja nie skorzysta już z większości czujników w telefonach.
Z drugiej strony, aplikacje pisane w HTML/JS w Apache Cordova bez problemu korzystają z czujników w telefonach.
Żeby nie było - tylko prostuję nieścisłości, nie jestem jakimś zwolennikiem przenoszenia wszystkiego do weba, niektóre rzeczy jako webowe nie mają sensu.