Pracowałem nad tworzeniem aplikacji z wieloma „zachowanymi” systemami GUI (poniżej więcej o tym, co mam na myśli), takimi jak MFC, QT, Forms, SWING i kilka frameworków web-GUI kilka lat temu. Zawsze uważałem koncepcje większości systemów GUI za zbyt skomplikowane i niezdarne. Ilość zdarzeń oddzwaniania, detektorów, kopii danych, czegoś do czegoś ciągnąć - konwersje (i tak dalej) zawsze były źródłem błędów i problemów w porównaniu z innymi częściami aplikacji. (Nawet przy „właściwym” wykorzystaniu powiązań / modeli danych).
Teraz piszę gry komputerowe :). Do tej pory pracowałem z jednym GUI: Miyagi (mało znany, ale w zasadzie ten sam Idea, co wszystkie inne systemy).
To było okropne.
W przypadku środowisk renderowania w czasie rzeczywistym, takich jak Gry, mam wrażenie, że „zachowane” systemy GUI są jeszcze bardziej przestarzałe. Interfejsy użytkownika zwykle nie muszą być automatycznie układane ani mieć okien w trakcie pracy, których rozmiar można zmieniać. Zamiast tego muszą bardzo efektywnie współdziałać z ciągle zmieniającymi się danymi (takimi jak pozycje modeli na świecie w 3D)
Kilka lat temu natknąłem się na „IMGUI”, który jest w zasadzie jak tryb Natychmiastowej grafiki, ale dla interfejsów użytkownika. Nie poświęciłem zbyt wiele uwagi, ponieważ wciąż byłem w fazie rozwoju aplikacji, a sama scena IMGUI wydawała się niezbyt szeroka ani udana. Jednak podejście, które przyjęli, wydaje się być tak seksowne i eleganckie, że sprawiło, że chciałem napisać coś do następnego projektu przy użyciu tego interfejsu użytkownika (nie przekonałem nikogo w pracy: (...)
pozwól, że streszczę, co rozumiem przez „zachowane” i „natychmiastowe”:
Zachowane GUI: W osobnej fazie inicjalizacji tworzysz „kontrolki GUI”, takie jak Etykiety, Przyciski, TextBoxy itp., I używasz opisowego (lub programowego) sposobu umieszczania ich na ekranie - wszystko przed renderowaniem czegokolwiek. Elementy sterujące przechowują większość własnego stanu w pamięci, na przykład lokalizację X, Y, rozmiar, obramowania, elementy podrzędne, tekst etykiety, obrazy i tak dalej. Możesz dodać wywołania zwrotne i detektory, aby uzyskać informacje o zdarzeniach i zaktualizować dane w kontrolce GUI.
Natychmiastowe GUI: Biblioteka GUI składa się z jednorazowych funkcji „RenderButton”, „RenderLabel”, „RenderTextBox” ... (edycja: nie daj się pomylić przez Renderujprefiks. Funkcje te wykonują również logikę za elementami sterującymi, takimi jak odpytywanie danych wejściowych użytkownika, wstawianie znaków, obsługa powtarzania znaków, gdy użytkownik przytrzymuje klawisz i tak dalej ...), które można wywołać w celu „natychmiastowego” renderowania formantu (nie t musi być natychmiast zapisany na GPU. Zwykle jest on zapamiętywany dla bieżącej ramki i sortowany na odpowiednie partie później). Biblioteka nie przechowuje dla nich żadnego „stanu”. Jeśli chcesz ukryć przycisk ... po prostu nie wywoływaj funkcji RenderButton. Wszystkie funkcje RenderXXX, które mają interakcję użytkownika, takie jak przyciski lub pole wyboru, mają zwracane wartości wskazujące, czy np. Użytkownik kliknął przycisk. Więc twój „RenderGUI” funkcja wygląda jak duża funkcja if / else, w której wywołujesz lub nie wywołujesz funkcji RenderXXX, w zależności od stanu gry, a cała logika aktualizacji danych (po naciśnięciu przycisku) zostaje wplątana w przepływ. Całe przechowywanie danych odbywa się „poza” interfejsem GUI i przekazywane na żądanie do funkcji renderowania. (Oczywiście podzieliłbyś duże funkcje na kilka funkcji lub używałbyś abstrakcyjnych klas do grupowania części gui. Nie piszemy już kodu jak w 1980 roku, prawda?))
Teraz odkryłem, że Unity3D faktycznie stosuje to samo podstawowe podejście do swoich wbudowanych systemów GUI. Prawdopodobnie jest też kilka GUI z takim podejściem?
Nadal… kiedy się rozglądasz, wydaje się, że silna tendencja do zachowywania systemów GUI? Przynajmniej nie znalazłem takiego podejścia, z wyjątkiem Unity3D, a oryginalna społeczność IMGUI wydaje się raczej .... cicha.
Czy ktoś pracował z obiema pomysłami i miał jakieś mocne zdanie?
Edycja: Najbardziej interesują mnie opinie wynikające z rzeczywistych doświadczeń. Myślę, że na forum IMGUI toczy się wiele gorących dyskusji na temat wszelkich „teoretycznych słabości” bezpośredniego podejścia do GUI, ale zawsze uważam, że lepiej jest wiedzieć o słabościach w świecie rzeczywistym .