Posts tagged ‘GUI’

System GUI #7 – Pole tekstowe

2007-09-16 21:16

Wśród standardowych kontrolek spotykanych w każdym systemie graficznego interfejsu jest jedna, która zdecydowanie wyróżnia się stopniem skomplikowania. Z wierzchu to tylko mały, podłużny prostokąt z wpisanym ciągiem znaków, który można modyfikować. Jednak mechanizmy sprawiające, że jest to możliwe, nie są wcale takie proste.
Mówię tu oczywiście polu tekstowym, znanym też jako textbox, editbox lub po prostu edit.

Powodów, dla których właśnie ta kontrolka wyróżnia się złożonością, jest przynajmniej kilka. Są to chociażby:

  • Kontrolowanie, jaki fragment tekstu jest w aktualnie widoczny w ramach kontrolki. Jak wiemy, pole tekstowe powinno oferować możliwość wpisywania tekstu dłuższego (pikselowo) niż jego rozmiary, dlatego często część jego zawartości będzie niewidoczna. Należy jednak zapewnić możliwość przewijania (klawiszami strzałek wraz z Ctrl oraz Home i End), aby możliwe było ukazanie innego fragmentu tekstu.
  • Przycinanie w polu tekstowym

  • Obsługa kursora tekstowego, czyli tzw. karetki. Oprócz przesuwania za pomocą klawiatury użytkownik bardzo słusznie będzie oczekiwał, że jest to możliwe także poprzez kliknięcie myszą. Wymaga to więc istnienia sposobu na określenie, w jaki znak użytkownik trafił. A poza tym karetka musi jeszcze mrugać odpowiednio zachęcająco – w końcu dawniej nazywała się ona znakiem zachęty :)
  • Pole tekstowe z kursorem (karetką)

  • Możliwość zaznaczania tekstu. Tradycyjnie jest to możliwe poprzez przeciąganie, jak również z klawiatury (z użyciem klawisza Shift). Kontrola stanu zaznaczenia to generalnie niezbyt złożona, ale też nie tak trywialna maszyna stanów
  • Zaznaczenie w polu tekstowym

Tak naprawdę choćby w systemie Windows pola tekstowe umożliwiają nieco więcej, jak na przykład możliwość cofnięcia ostatniej operacji, obsługa Schowka czy nawet menu kontekstowe. Takie cuda nie są chyba jednak potrzebne do szczęścia :)
Zauważmy też, że kontrolka umożliwiająca edycję dłuższego tekstu dzielonego wiersza to coś zupełnie innego niż zwykły textbox i jej możliwości są nieporównywalnie większe. Dochodzą tam bowiem paski przewijania, zaznaczanie rozciągnięte na kilka wierszy, i tak dalej.

Implementując proste pole tekstowe zauważyłem, że bardzo pomaga przy tym odpowiednia konstrukcja pewnych podstawowych mechanizmów GUI – jak mouse capture czy fokus klawiatury, modelu propagacji zdarzeń oraz modułu odpowiedzialnego za wypisywanie tekstu. Łącznie jednak wychodzi z tego i tak nadspodziewanie duża ilość kodu ze sporą liczbą zagmatwanych ifów :]

Tags: ,
Author: Xion, posted under Programming » 1 comment

System GUI #6 – Pole wyboru i przycisk opcji

2007-09-06 20:09

Zwykłe przyciski (buttons) można tylko wciskać jak guziki na monitorze lub klawisze na klawiaturze. Wydawałoby się, że nie mają one wiele wspólnego z bardziej zaawansowanymi elementami interfejsu: polami wyboru (checkboxes) czy przyciskami opcji (radio buttons).
Te pierwsze to proste przełączniki: mogą być zaznaczone lub nie, swój stan zmieniają po kliknięciu i zazwyczaj odwzorowane są na jakieś funkcje programu, które mogą być włączane i wyłączane. Te drugie oferują z kolei wybór z większej liczby wariantów, z których tylko jeden może być aktywny w danej chwili. Z punktu widzenia użytkownika największa różnica polega jednak na tym, że pola wyboru mają obok etykiet tekstowych kwadraciki, zaś przyciski opcji – kółka :)

Przykład pól wyboru (checkbox) Przykład przycisków opcji (radio button)

Podobieństwo tych dwóch kontrolek do zwykłych przycisków polega na tym, że w identyczny sposób reagują na zdarzenia od myszy – czyli przede wszystkim kliknięcia. Podobieństwo okazało się na tyle duże, że sensowne okazało się połączenie wszystkich tych trzech rodzajów kontrolek wspólną klasą bazową. Nie lubię nadużywania dziedziczenia, ale akurat tutaj rozciągnięcie hierarchii klas wydaje się rozsądne.

Hierarchia klas kontrolek przyciskopodobnych

Z tych trzech typów kontrolek prawdopodobnie najbardziej interesujący jest przycisk opcji, czyli ten z kółeczkiem :) Trzeba bowiem zastanowić się, w jaki sposób zrealizować grupowanie tych obiektów w zestawy, w ramach których tylko jeden radio button może być zaznaczony. Spotkałem tutaj dwa rozwiązania:

  • Wprowadzenie specjalnej kontrolki-kontenera nazywanej zwykle RadioGroup. Kontener ten może zawierać tylko przyciski opcji, które wówczas nawet nie muszą być samodzielnymi kontrolkami (ale cały czas powinny oczywiście sprawiać takie wrażenie). Taka ‘grupa radiowa’ jako pojemnik może, ale nie musi być widoczna na ekranie. Przy takim rozwiązaniu spełniony jest zawsze warunek, że spośród wszystkich przycisków opcji będących bezpośrednio zawartych w jakimkolwiek kontenerze (RadioGroup lub innym) zaznaczony jest tylko jeden.
    Ten wariant występuje na przykład w bibliotece VCL (Delphi).
  • Dodanie do radio buttona właściwości określającej grupę przycisków, jak choćby jej nazwa (napis) lub indeks (liczba). Wtedy należy zapewnić, że zaznaczenie będzie unikalne w ramach przycisków z tego samego kontenera oraz z tej samej grupy.
    To rozwiązanie występuje w Windows Forms.

Ostatecznie zdecydowałem się na wariant drugi. Z punktu widzenia implementacji najważniejszego elementu – czyli dbania o to, by tylko jedna opcja była zaznaczona – oba rozwiązania są bardzo podobne. Tak czy owak trzeba zawsze najpierw odznaczyć wszystkie przyciski, a potem zaznaczyć ten kliknięty. Jest to przy tym jedna z tych sytuacji, w których bardzo ułatwia życie przeklinany operator rzutowania dynamic_cast :]

Tags: , , ,
Author: Xion, posted under Programming » Comments Off on System GUI #6 – Pole wyboru i przycisk opcji

System GUI #5 – Okno

2007-08-28 17:43

Dawno temu w firmie Xerox wymyślono, że interfejs użytkownika można zapakować w zestaw prostokątnych, nakładających się na siebie okien. Pomysł okazał się niezwykle trafiony i zaowocował nawet wielce kreatywną nazwą pewnego systemu operacyjnego ;) Od tamtej pory trudno sobie wyobrazić zaawansowane UI posługujące się czymś innym niż właśnie zestawem okien.

Nie jest trudno otrzymać na ekranie puste okno. W środowiskach RAD – w rodzaju Visual C# czy Delphi – mamy je najczęściej dane automatycznie, gdy tworzymy nowy projekt. W przypadku programowania niewizualnego (jak np. z użyciem czystego Windows API) sprawa jest nieco bardziej skomplikowana, ale i tak zamyka się w nie więcej niż kilkudziesięciu linijkach.
Takie puste okno wydawać się może mało interesujące czy wręcz zbyt oczywiste, aby zwracać na nie uwagę. Rzadko zwracamy uwagę na to, że ten pozornie trywialny prostokąt sam w sobie potrafi bardzo wiele. Wśród typowych możliwości mamy chociażby:

  • przesuwanie za pomocą przeciągania za pasek tytułu
  • zmianę jednego z wymiarów poprzez przeciąganie brzegów
  • zmianę obu wymiarów poprzez przeciąganie rogów okna
  • Przeciąganie za pasek tytułu okna Zmiana jednego z wymiarów okna Zmiana obu wymiarów okna Przyciski sterujące oknem

  • minimalizacja, maksymalizacja i zamykanie okna przyciskami na pasku tytułu

Uzyskanie podobnej funkcjonalności, zaczynając od zera, jest bardziej pracochłonne niż może się wydawać. W moim przypadku otrzymanie czegoś, co przypomina w pełni funkcjonalne i interaktywne okno, zamknęło się w ok. dwóch tysiącach linijek kodu – nie licząc oczywiście modułu grafiki 2D, potrzebnego do rysowania okien.
To całkiem sporo. Skutkiem ubocznym tej pisaniny jest też to, że obecnie patrzę na stare poczciwe okna systemu Windows z nieco większym respektem :)

Tags: , ,
Author: Xion, posted under Programming » Comments Off on System GUI #5 – Okno

System GUI #4 – Przycisk

2007-08-21 14:48

Co można powiedzieć o czymś tak prozaicznym, jak zwykły przycisk? Ano to, że przycisk jest po to, aby go wciskać :) Od strony użytkownika wygląda to więc bardzo prosto – może nawet zbyt prosto, co czasami kończy się źle, jeśli nie czytamy komunikatów przed pochopnym wciśnięciem OK.
Kwestia oprogramowania takiego tworu jak przycisk, aby zachowywał się zgodnie z oczekiwaniami, jest już jednak trochę trudniejsza.

Przy okazji przycisku wychodzi bowiem kwestia tak zwanego mouse capture, które to pojęcie nie ma dobrego tłumaczenia na język polski. Pozwala ono użytkownikowi rozmyślić się i nie dokonać kliknięcia nawet wtedy, gdy zdążył już wcisnąć przycisk myszki. Wystarczy, że – nie puszczając go – odjedzie kursorem poza obszar kontrolki i tam puści przycisk myszy. Wówczas zarówno zdarzenie wciśnięcia, jak i puszczenia przycisku myszy będzie zarejestrowane, lecz to najważniejsze – kliknięcia – już nie.
Ten dość abstrakcyjny byt mouse capture może być przez kontrolkę posiadany lub nie. Jeżeli kontrolka go posiada, wtedy otrzyma ona informacje o zdarzeniach myszy nawet gdy kursor znajduje się poza jej obszarem. Dzięki temu kontrolka przycisku może być poinformowana o tym, że użytkownik zrezygnował z jej wciśnięcia.

Wciśnięcie przycisku i odjechanie kursorem

Pozostaje jeszcze drobna kwestia graficzna. Otóż w Windows kontrolka przycisku “wyciska się”, jeżeli odjedziemy kursorem poza jej obszar (oczywiście cały czas trzymając wciśnięty przycisk myszki). Kiedy znów wrócimy, wciśnie się ponownie, i tak dalej (ciekawym zalecam własnoręczne eksperymenty ;]). Osobiście nie sądzę, żeby takie zachowanie było bardzo intuicyjne, bo chyba bardziej by mi odpowiadało, gdyby kontrolka pozostała cały czas wciśnięta.
Niestety, nie ja ustanawiam standardy interfejsu, więc postanowiłem się dostosować i zaimplementować windowsowe rozwiązanie :)

Tags: , ,
Author: Xion, posted under Programming » 4 comments

System GUI #3 – Zdarzenia

2007-08-14 11:42

Graficzny interfejs może (i powinien) ładnie wyglądać, ale jego najważniejszą cechą jest oczywiście interaktywność. GUI musi przede wszystkim umożliwiać reakcję na poczynania użytkownika, a to jest możliwe przez odpowiednią obsługę zdarzeń.

Informację o tym, że kliknięto gdzieś myszką lub wciśnięto klawisz, pozyskać jest oczywiście bardzo łatwo. W Windows wystarczy w tym celu obsługiwać komunikaty systemowe przychodzące do okna. O wiele większym wyzwaniem jest przetłumaczenie informacji “kliknięto w punkt (458,89) obszaru klienta” na “kliknięto w obrębie kontrolki TextBox o nazwie Text1“. Komunikat należy bowiem przekazać do odpowiedniej kontrolki (-ek) – tej, której on dotyczy.

Jest pewnie wiele sposób na zrealizowanie takiego przekazywania, jednak najbardziej sensowne wydają mi się dwa. Pierwszym z nich jest propagacja zdarzenia na kolejne poziomy drzewa systemu GUI. Kliknięcie jest więc przekazywane do okna i od tej pory cała odpowiedzialność za jego obsłużenie spada na to właśnie okno. Ono sprawdza, czy myszka trafiła w którąś z kontrolek potomnych; jeśli tak, to znów zdarzenie jest przekazywane właśnie do tej kontrolki i okno się już nim nie zajmuje. Proces ten przebiega aż dojdziemy do najniższego możliwego poziomu, czyli kontrolki nie zawierającej już żadnych innych. Tam następuje właściwa obsługa zdarzenia.

Przepływ zdarzeń w systemie GUI - wariant pierwszy

Drugi sposób zakłada, że zdarzenie nie będzie “rozłazić” się po całym drzewie, tylko od razu trafiać do tej właściwej, docelowej kontrolki. Naturalnie nie zawsze da się tak zrobić. W przypadku wciśnięć klawiszy możemy pamiętać, która kontrolka ma tzw. fokus i do niej kierować komunikaty. Natomiast obsługa myszki wymaga wysłania swego rodzaju sondy wgłąb drzewa kontrolek w celu znalezienie tej najmniejszej, w którą trafił kursor (operacja ta jest znana jako hit test).

Przepływ zdarzeń w systemie GUI - wariant drugi

Generalnie zdarzenia z punktu widzenia ich obsługi można podzielić na dwie grupy: na zdarzenia myszki i na… wszystkie inne :) To właśnie te pierwsze przysparzają najwięcej kłopotów. Nie tylko wymagają rekurencyjnego przeszukiwania drzewa kontrolek, ale też mogą mieć globalne konsekwencje, jak np. zmiana fokusu. Zajmowanie się tymi konsekwencjami jest łatwiejsze, gdy wszystko odbywa się “na górze” – na poziomie głównych klas systemu GUI, a nie pojedynczych kontrolek. Jest to jeden z powodów przemawiających za wyborem drugiego sposobu przekazywania informacji o zdarzeniach.

Tags: , , ,
Author: Xion, posted under Programming » 1 comment

System GUI #2 – Model klas

2007-08-06 11:40

Po kilku dniach niezbyt intensywnego zastanawiania się nad strukturą systemu GUI zdołałem wysmażyć coś, co można nazwać schematycznym modelem klas. Jest on wybitnie poglądowy i przedstawia się następująco:

Schemat modelu klas systemu GUI

Na pierwszy rzut oka może wydawać się nieco pokręcony, ale z odrobiną wysiłku można go odcyfrować :] To co jest w nim chyba najważniejsze, to dość wyraźny podział na część rysującą (lewa strona) i tę zawierającą kontrolki. Łączy je “most” złożony z głównej klasy systemu, nazwanej bardzo oryginalnie: System :) Taki podział zapewni między innymi prostsze rysowanie samych kontrolek, które będą renderowane przy pomocy takich poleceń jak: narysuj ramkę, narysuj wciśnięty przycisk, itp. To rozwiązanie zaczerpnąłem z Windows.Forms, gdzie jest zresztą ono posunięte o wiele dalej.
Lista kontrolek jest, jak widać, skromna i odpowiada tej, którą wcześniej ustaliłem jako minimalną. Oprócz abstrakcyjnej klasy dla wszystkich kontrolek wprowadziłem też osobną dla takich, które mogą zawierać i grupować inne kontrolki. Póki co jedynym obiektem tego rodzaju jest okno, ale GUI zna ich więcej: jak np. panel czy pole grupy (groupbox).

Tags: , ,
Author: Xion, posted under Programming » 1 comment

System GUI #1 – Założenia

2007-08-02 14:21

Skoro posiadam już w miarę sprawnie działający moduł odpowiedzialny za grafikę 2D, pora zająć się jednym z jego najważniejszych zastosowań. Bo oprócz menu czy ekranu powitalnego, najważniejszymi dwuwymiarowymi elementami w każdej grze są składowe jej interfejsu użytkownika.

Po co jednak pisać własny system GUI?… Cóż, oprócz uniwersalnej odpowiedzi (“bo tak”) można odrzec, że to po prostu fajne :) W bardziej rozwiniętej wersji uzasadnienie brzmi tak, iż struktura wewnętrzna dobrze napisanego systemu UI to jeden z najelegantszych przykładów zastosowania programowania obiektowego w praktyce. Jest w niej aż gęsto od przeróżnych wzorców projektowych i całość aż kipi od kipi od tego, co nazywam estetyką projektowania.
Tej estetyki niestety będzie mi prawdopodobnie brakować, kiedy później zajmę się już całkiem “trójwymiarowymi” aspektami silnika, jak modelami, organizacją sceny, materiałami, oświetleniem, itd. Zbalansowanie wydajności z przejrzystością interfejsu (i kodu) na pewno będzie wymagało wielu nieprzyjemnych wysiłków…

System UI z D3DX

A zatem z pewną przesadą można powiedzieć, że system GUI będę pisał dla… relaksu :) Wobec takiego postawienia sprawy nie ma rzecz jasna potrzeby odpierania argumentów w stylu: “Przecież to nie jest potrzebne!”, “W D3DX jest już system GUI (screen powyżej)”, “Dublujesz kontrolki systemowe”, itd. Dla porządku dam aczkolwiek jedno logiczne uzasadnienie: te gatunki gier, które najbardziej lubię – a więc RPGi, strategie czy gry ekonomiczne – wykorzystują UI w dużych i różnorodnych ilościach. Więc jeśli kiedyś… no ale do tego chyba przejdziemy znacznie później :]

GUI jest jedną z tych rzeczy, które można rozbudowywać właściwie w nieskończoność. Dlatego przydałoby się od razu ustalić założenia, jakie chciałbym spełnić. Przede wszystkim nie chcę mnożyć kontrolek ponad potrzebę, gdyż sądzę, że w dużej części przypadków do szczęścia wystarczą poniższe cztery:

  • etykieta (label) – czyli kontrolka ze statycznym tekstem
  • przycisk (button)
  • pole tekstowe (edit, textbox)
  • pole wyboru (checkbox) – kontrolka umożliwiająca włączanie/wyłączanie opcji

Faktycznie przydałaby się jeszcze jakaś kontrolka listowa, ale na razie dla prostoty chcę ją pominąć.
Oprócz samych kontrolek ważne jest też odpowiednie ich zachowanie się. Przede wszystkim chodzi tu o kwestię fokusu klawiatury czy capture myszki, a także funkcjonalności klawisza Tab. Krótko mówiąc, chciałbym żeby mój system przypominał UI, które na co dzień można spotkać w Windows.

Tyle że moje UI nie musi być wcale takie “piękne” jak Aero z Windows Vista ;P

Tags: ,
Author: Xion, posted under Programming » 1 comment
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.