w jakiej technologi "strona wbudowana" do aplikacji c++

Aplikacja w Qt działa na ekranie , czasami jednak trzeba uruchomić tryb serwisowy dla wtajemniczonych.
Jak wyświetlę okno serwisowe na ekranie to zasłonię aplikację wiec pomysł aby zrobić to przez przeglądarkę.
Czyli dodać do aplikacji Qt serwer HTTP aby za pomoca przeglądarki można zajrzeć co się dzieje w aplikacji

Potrzebuję generalnie w zakładkach wyświetlać struktury albo std::vector<jakias_struktura> i mieć możliwość edycji danych

W czym to zrobić aby wyglądało ładnie ?

• struktury umiem zamienić na JSON
• chciałem użyć tego serwer-a https://github.com/yhirose/cpp-httplib

Nie mam jednak zielonego pojęcia w czym stworzyć stronę bo jak ostatnio robiłem pierwsza i ostatnia stronę w życiu to było PHP 3 :D Nie znam żadnego framework-a , obejrzałem sobie yotube o Flutter-Web i Gatsby .

Przecież nie potrzebujesz jakieś mega strony w stylu https://www.wolfram.com/mathematica/
Potrzebujesz co najwyżej drzewko z wartościami oraz wyświetlenie tej wartości.
Sam sobie zrobisz framework szybciej niż jakiegoś się nauczysz, jak na takie minimalistyczne wymagania oczywiście.

kiedyś robiłem w projekcie co chyba z tego korzystaliśmy?|(sam już nie pamiętam)
https://doc.qt.io/qt-6/qtwebchannel-index.html
pamiętam że była możliwośc bezpośredniej komunikacji appka qt a strona wyświetlana przez engine.
qtwebassembly ewentualnie?

@Adamek Adam:

Jesli cię martwi istnienie okienka aplikacji - konfliktujacego z serwisowym - to znaczy że oczekujesz czegoś znacznie więcej, niż koledzy zgadują (np ustawień "w rejestrze apliakcyjnym" które zaskutkują przy kolejnym starcie okien).
Poziom trudności po cichu baaaardzo idzie w górę

Jest NIECO lepiej, gdy GUI masz mocno oddzielone od modelu mdanych, ale wbicie się w dynamiczną chwilową strukturę modelu, też jest ciezkie z main()'a'

EDIT2: łatwą (w miarę, tzn do wykonania, ale nie w tydzień, i stabilnej eksploatacji) koegzystencję GUI i web-serwera spodziewam się tylko dla bardzo dobrze zaprojektowanego backendu aplikacji (serwisy, repozytoria, obiekty biznesowe) ... szczerze rzadko mi się to łączy z myśleniem C++ GUI

EDIT3: mam na myśli, z perspektwy main(), a tak by był hipotetyczny webserwer (???) programowo "nie widac" otwartych okienek. Wiec w każdym okienku handler http ? W języku bez refleksji, ileż to dodatkowego kodu ...

Ideałem to byłby webowy "Object Inspector" do zarejestrowanych w serwerze WWW obiektów.

Albo pojsc drogą podobna jak w firefox wyglada "about:config"
czyli lista wszystkich zarejestrowanych właściwości

Ale było by z tym sporo zabawy !

wartości obiektu nie sa problemem , ale zbudowanie Json dla klienta webowego który opisywał by budowę obiektu to już proste nie jest , trzeba by to albo opisać "z palca" albo używać magicznych sztuczek à la moc.exe

Mignął w powiadomieniach post "podłącz debuger", i to jest właściwa odpowiedź.

Nie należy mnożyć bytów ponad potrzebę. Diagnostyka problemów (wprawdzie eksploatacyjno-wdrozeniowych) w języku mało wydajnym linii / zagadnienie, jakim jest C++,
Podwojenie ilości kodu konwerterami do JSON i ich utrzymanie w aktualności nie polepszy niezawodności programu/produktu wynikowego

Adamek Adam napisał(a):

Ideałem to byłby webowy "Object Inspector" do zarejestrowanych w serwerze WWW obiektów.

Tyle że isnpektor Delphi pracuje wobec specjalnie ku temu przygotowanych obiektów (komponentów). Stać Cie na to, żeby zaorać strukturę danych jaką masz, i robić od nowa? A zrobienie częsciowo, to i webowy akces będzie częściowo użyteczny (czytaj: będzie wkurzał a nie pomagał)

Podobnie Firefosa ekrany serwisowe pracują wobec dobrze przygotowanego "rejestru" aplikacji (skądinąd: nie danych przeglądanych, a ilez błędów tam siedzi). Webowy dostęp do "rejestru apliakcji", cokolwiek by słowo rejestr znaczyło, jest jedynym na co widzę szanse bez wysadzenia projektu w powietrze. A dla typowej apki, gdzie osią "rejestru" jest baza SQL, wystarczy dostęp z innego stanowiska.

Zadanie domowe: chcesz grzebać w danych (mocno dynamicznych) czy "rejestrze" (o wiele bardziej statycznym), a mzoe jeszcze ustawiać "breakpointy" w przetwarzaniu danych (kosmos)

Nie che aby cała wewnętrzna logika aplikacji była zarządzana przez przeglądarkę raczej wybrane pojedyncze struktury/zmienne
Nie che tez przeglądarka debugować , gdb mi wystarczy

Adamek Adam napisał(a):

Nie che aby cała wewnętrzna logika aplikacji była zarządzana przez przeglądarkę raczej wybrane pojedyncze struktury/zmienne
Nie che tez przeglądarka debugować , gdb mi wystarczy

W normalnym programie okienkowym przeważająca ilość zmiennych nie jest globalna, a związana z oknami (jakie zmienne 'auto' na frame, czy alokowane z referencją lokalną dla okna. Dla mnie to ogromny wzrost komplikacji, jeśli kontekstem dla głównego serwera jest main(). Po pierwsze trzeba te okna centralnie odnaleźć, po drugie - a mamy język bez refleksji - wykryć / zaewidencjonować.
Jeszcze gorsze są zmienne na czas algorytmów, lokalne dla metod/funkcji.

jeśli kazde okno jest samo sobie serwerem (niby jak, IP i port zajęty) ... też wyskoczy komplikacja, ale w innym miejscu

Czujesz bluesa ?

Zmienne "globalne" na poziomie naszej dyskusji poprzednio dla orientacji sklasyfikowałem jako globalny "rejestr"

edit. można gdybać, np nie mieć zmiennych double ale każdą zamienić na MyVariable<double> ... a klasa zgłasza ją do jakiegoś kernela. Czyli pracowicie nadrabiamy coś, co C# / Java ma in the box.
LUB: algorytmy biznesowe w 100% masz w silniku skryptowym (z innych względów - EWENTUALNIE może być jakaś wartością) Lua / Python, a ich zmienne jest jak poznać / aktualizować ...
LUB: wpiac się w mechanizm (nie mam pojecia czy i jaki) jak apka Qt robi zrzut do debugera w razie wylecenie w powietzre ...

Jak mówił Kuraś, jak się nie ruszać, d... z tyłu