Jak dobrać odpowiedni frontend do aplikacji w QT?

Cześć, dzień dobry, dobry wieczór.

Jak wiadomo, na upartego można na GNU/Linux uruchomić maszynę wirtualną na której będzie stał Windows i w ten sposób można uruchomić chociażby pakiet Microsoft Office by korzystać z niego w miarę normalny sposób. Jeden z użytkowników Linuxa poszedł o krok dalej i za pomocą różnych technik udało mu się stworzyć aplikacje konsolową która większą część tego procesu automatyzuje a dzięki dostępnej na systemach operacyjnych z rodziny Windows technologi Pulpitu Zdalnego udało mu się doprowadzić do uruchomienia instancji pakietu Office na Linuxie w zwykłym oknie (z punktu widzenia użytkownika, instancja maszyny wirtualnej z Windowsem jest ukryta).

Uznałem ze jako ze aplikacja już jest warto by stworzyć do niej GUI, z raci że najlepiej znam C++ zacząłem coś dłubać.

Wyzwanie dla mnie stanowi jak w C++ i Qt zaprogramować wygląd. Obecnie pracuje badawczo rozwojowo nad aplikacją która byłaby dialogiem konfiguracyjnym.
Z racji że ten dialog byłby podzielony na kilka etapów gdyż trzeba by podać np plik ISO z Wndowsem oraz plik ISO z Officem mam problem jak prawidłowo i elegancko opisać która kontrolka znajduje się gdzie.

• Np w etapie1 tworzymy 2 buttony, pole tekstowe i kilka pól do wyświetlania informacji na ekranie.
• Przy etapie 2 powstaje tez pewna ilość kontrolek im więcej etapów tym gorzej.

Dodatkowo użytkownik może wracać do poprzedniego etapu. Ilość kodu który obsługuje tworzenie, ustawianie, niszczenie nadmiarowych i tworzenie dodatkowych kontrolek jest przytłaczająca i jest to prosta droga do osiągnięcia efektu spaghetti...

i teraz pytanie
Czy użycie C++ wraz QT/QtWidget to dobry pomysł? Dowiedziałem że można dołączyć C++ i Qt wraz z QML, narzekam jednak na brak przykładów i dobrych tutoriali
Może istnieje lepszy stack technologiczny do tego zadania. Aplikacja zarządzająca pisana w C++ Windows Subsystem for Linux że tak powiem :) i wystawia jakiegoś rodzaju API a aplikacje GUI (a byłoby kilka, co najmniej 2 na ten moment) pisane w innym języku (Python, TypeScript ..) wraz z odpowiednim Frameworkiem.

Na pewno trzeba podzielić aplikacje na Backend i Frontend. Backend chciałbym aby był w C++ tylko jak mądrze napisać Frontend. Proszę o doradzenie Frameworku i języka dla Frontu aby można było to mądrze złączyć - co do zasady operuje C++, Pythonem, TypeScrptem i JS ale nauka chociażby Rust czy QML nie stanowi problemu.

Szymon Paczos napisał(a):

co do zasady operuje C++, Pythonem, TypeScrptem i JS ale nauka chociażby Rust czy QML nie stanowi problemu.

Pytanie, w jaki sposób się chcesz komunikować z frontendem. Jeśli chcesz zrobić webowy frontend oparty o HTML/CSS/JS, to zapewne będziesz potrzebował oddzielić backend i frontend w 100% i komunikować się przez HTTP (a więc serializować dane i deserializować - a przecież nie wszystkie dane da się bezpośrednio zserializować). Ew. w jakiś inny sposób się komunikować z frontendem (np. osadzić widżet przeglądarki w jakiś sposób). W zależności od tego, jak jest zrobiony projekt, może to być łatwiejsze lub trudniejsze (pytanie, jak to już działa - czy ten backend i frontend dałoby się łatwo oddzielić pod kątem architektury).

Zrobienie GUI zaś w tym samym języku, jako integralnej części aplikacji, dawałoby możliwość np. dzielenia pamięci z resztą projektu i bezpośrednie wyświetlanie tego, co ma być wyświetlone, bez potrzeby serializacji i przesyłania danych po sieci czy w inny sposób. Ale jednak wtedy masz większy coupling i potencjalnie mniej elastyczną architekturę. Choose your poison.

Ilość kodu który obsługuje tworzenie, ustawianie, niszczenie nadmiarowych i tworzenie dodatkowych kontrolek jest przytłaczająca i jest to prosta droga do osiągnięcia efektu spaghetti...

Tutaj może przydać się podejście popularne w rozwiązaniach JavaScript (np. React), gdzie masz deklaratywność.

Jesli miałbym strzelać to OP raczej nie chce robić frontendu przeglądarkowego, tylko używa tego określenia w szerszym kontekście, z czasów zanim javascriptowcy przywłaszczyli sobie to słowo.

Jak ktoś całe życie nie widział nic więcej niż apka webowa to i potem w głowie się nie mieści ze frontend to może być coś innego :D

Obejrzyj przykłady do Qt w QtCreator ! Może coś Cie zainspiruje

@Szymon Paczos:

Na pewno trzeba podzielić aplikacje na Backend i Frontend.

Zaraz, zaraz... czegoś nie rozumiem. Mowa o czymś w rodzaju super-instalera, czy wizarda do instalatorów, i webowo ?
Skąd wiadomo, ze "na pewno trzeba" ? Bo wszyscy plują na ulicy to norma ?

Patologiczny pomysł z wielu powodów, czuły jak cholera na nieprzygotowanie czegoś na systemie docelowym (firewalle, te sprawy), brak możliwości niuanów kooperacji z systemem/ami operacyjnymi, choćby wykonanie części na innych prawach. Po trzecie C++ (nawet na sterydach od Qt) jest bardzo złym językiem na RESTy

ZrobieDobrze napisał(a):

@Szymon Paczos:

Na pewno trzeba podzielić aplikacje na Backend i Frontend.

Zaraz, zaraz... czegoś nie rozumiem. Mowa o czymś w rodzaju super-instalera, czy wizarda do instalatorów, i webowo ?
Skąd wiadomo, ze "na pewno trzeba" ? Bo wszyscy plują na ulicy to norma ?

Patologiczny pomysł z wielu powodów, czuły jak cholera na nieprzygotowanie czegoś na systemie docelowym (firewalle, te sprawy), brak możliwości niuanów kooperacji z systemem/ami operacyjnymi, choćby wykonanie części na innych prawach. Po trzecie C++ (nawet na sterydach od Qt) jest bardzo złym językiem na RESTy

Że zacytuje sam siebie Jesli miałbym strzelać to OP raczej nie chce robić frontendu przeglądarkowego, tylko używa tego określenia w szerszym kontekście, z czasów zanim javascriptowcy przywłaszczyli sobie to słowo

Wyczytujesz jakieś dialogi w stylu GUI - service bez GUI ? Ja tego nie wyczytałem. OP wybitnie pije to popuranych narzedzi webowych

Jakiego byś nie wybrał - to i tak dobrą praktyką byłoby je zrobić niezależne od siebie, więc wybór tak na prawdę nie ma większego znaczenia.

ZrobieDobrze napisał(a):

Wyczytujesz jakieś dialogi w stylu GUI - service bez GUI ? Ja tego nie wyczytałem. OP wybitnie pije to popuranych narzedzi webowych

Zgadzam się z @KamilAdam, że OP chodzi o desktopowy front.

LukeJL napisał(a):

Zrobienie GUI zaś w tym samym języku, jako integralnej części aplikacji, dawałoby możliwość np. dzielenia pamięci z resztą projektu i bezpośrednie wyświetlanie tego, co ma być wyświetlone, bez potrzeby serializacji i przesyłania danych po sieci czy w inny sposób. Ale jednak wtedy masz większy coupling i potencjalnie mniej elastyczną architekturę. Choose your poison.

Ilość kodu który obsługuje tworzenie, ustawianie, niszczenie nadmiarowych i tworzenie dodatkowych kontrolek jest przytłaczająca i jest to prosta droga do osiągnięcia efektu spaghetti...

Podobnie jak ilosc kodu *) w dwóch projektach po każdym rozwoju protokołu komunikacyjnego (=funkcjonalności) o czynność / pole /walidację.
Skąd wasza wiara, ze rozdzielnie tego na warstwy W PRZYPADKU JAK TU zmniejsza coupling ???
Mówiąc pojęciami mikroserwisów, to tylko rozproszony monolit (w najgorszym gatunku). Przymus konserwacji DWÓCH ścisłe zcouplowanych projektów, w niezależnych językach, bez żadnego wsparcia z kompilatorów ...

*) a zwłaszcza kodu C/C++

@Riddle:

No i docieramy do tego, że moda / przymus / CV-driven development na warstwy jest kwestią wiary.

ZrobieDobrze napisał(a):

@Riddle:

No i docieramy do tego, że moda / przymus / CV-driven development na warstwy jest kwestią wiary.

To że Ty nie umiesz dobrze zbudować warstw w aplikacji, nie znaczy że inni nie umieją.

Flutter + Dart jest bardzo przyjemny do tworzenia aplikacji frontowych.

Może chcesz zrobić Wirtualną Maszynę przez przeglądarkę, to byłby hit ;)
A co to Qt wiem ze jest coś takiego jak QTWebkit może to jest to czego szukasz

pvalue33 napisał(a):

A co to Qt wiem ze jest coś takiego jak QTWebkit może to jest to czego szukasz

To jest coś wręcz odwrotnego, ale już nikt nie wie o co tu chodzi