millennium-dev team mailing list archive

[Rafał Cieślak <rafalcieslak256@xxxxxxxxxx>]

tl;dr: dużo się ostatnio działo, pora na większą naradę i wydanie 0.1.

Witam!

Dużo się ostatnio zadziało, jakoś mam więcej weny i sprawniej mi idzie
pisanie nowych rzeczy.
Piszę tego maila głównie po to by streścić co takiego się pozmieniało, a
także by przedstawić kolejne plany na najbliższy czas.

O makefilach pisałem w poprzednim mailu. Dodam jeszcze, że libmillennium od
niedawna buduje się do pełnoprawnej biblioteki, dokładniej: do
libmillennium.so.0.1
I to właśnie do tego pliku będziemy w przyszłości linkować MillenniumDuel.
Mam też plan kody demonstrujące libMillennium (tj serwer, klient) wydzielić
z kodu samej biblioteki, i budować je całkowicie osobno, linkując tylko do
biblioteki. Czyli dokładnie tak jak powinna być używana biblioteka.

Usprawniłem też zarządzanie klasami kart w libmillennium. Kto widział jak
wyglądały te klasy, wie, że była to 90% sól syntaktyczna. Plik .hpp (po
jednym na kartę) zawierał chyba z 10 linii, z czego tylko jedna cokolwiek
wnosiła. Powiązany plik .cpp był niewiele ciekawszy. To utrudnia i
zarządzanie takimi klasami, i dopisywanie nowych kart.
Teraz spraw wygląda istotnie inaczej. Pliki z implementacją klas w ogóle
nas nie interesują. Interesują nas natomiast pliki SDY.cards [1] i
SDK.cards [2]. Jak widać, zawierają przejrzysty, zwięzły opis listy kart z
danego zestawu.
Do kompletu potrzebny jest jeszcze skrypt generate.py [3]. Użyty np tak:
   ./generate.py SDY.cards
generuje pliki SDY.hpp oraz SDY.cpp z implementacją klas-kart opisanych w
SDY.cards. W ten sposób nie piszemy tych wszystkich śmieci syntaktycznych,
tylko skupiamy się na samej treści w .cards, a kod generuje się sam. Co
więcej, nie trzeba pamietać by go generować, make jest nauczony (poprzez
Makefile) by uruchamiał ./generate.py gdy tylko jest to potrzebne do
kompilacji, lub gdy zmieni się treść jakiegoś .cards.
[ Uwaga na marginesie: ten skrypt .py wypadałoby napisać formalniej,
najlepiej przy użyciu pythonowego parsera gramatyk. Jakby się znaleźli
jacyś pythoniści zainteresowani tematem (Balicki, czytasz te maile?), to
fajnie by było mieć ten skrypt zrobiony mega-porządnie. ]

W obu projektach pooznaczałem wszystkie pliki tekstem licencyjnym. Tak
wiem, że to przykre, że to zajmuje kilkanaście linijek, ale niestety tak
musi już być i nic nie poradzicie. Jak macie wątpliwości, zajrzyjcie w
źródła jakiegokolwiek wolnego oprogramowania. Wszędzie tak jest.

A teraz trochę o newsach ze świata klienta. Dopisałem trochę widgetów,
dodałem system eventów i zrobiłem mockup prawdziwego interfejsu. Polecam na
start odpalić program, zobaczyć jak to wygląda w praktyce, a potem obczaić
kod.
A tak na sam początek, to przeniosłem kod wszystkich widgetów do
podkatalogu ./src/widgets. Sensownie jest mieć je wszyskie razem, a
prawdziwy kod programu będzie w ./src.
Jedna bardzo istotna nowa klasa to CEvent. CEvent działa tak, że ma przede
wszystkim 2 metody: Happen, i Subscrbe. Happen używane jest wtedy, gdy
zachodzi zdarzenie reprezentowane przez CEvent (np. kliknięcie), wywołanie
Happen powoduje aktywowanie wszystkich funkcji, które wcześniej były podane
poprzez Subscribe. Tak, argumentem do Subscribe jest funkcja, funkcja,
która ma być wywołana gdy zajdzie to zdarzenie. W ten sposób można reagować
na kliknięcia dowolnego widgetu, a także na inne sytuacje.
Ten mechanizm zastępuje nadpisywanie wirtualnych funkcji OnCośtam
(OnCliked, OnMouseIn itd [czy wspomniałem, że dodałem reakcje interfejsu na
najechanie widgetu myszą?]). Jest lepszy z 3 powodów: pozwala dopiąć wiele
"słuchaczy" do jednego zdarzenia, nie nadpisuje metody rodzica (czyli może
być tak, że klasa po której dziedziczymy chce coś zrobić na kliknięcie, i
my też chcemy) a do tego pozwala reagować na nietypowe zdarzenia (tj możemy
się podpiąć do event_clicked WImage, chociaż naturalnie on temu nie służy,
i nie trzeba w tym celu nic dodawać do WImage.)
Jeszcze jedno sprostowanie: CEvent<...> jest tak naprawdę szablonem klasy.
Argument szablonowy specyfikuje typ jaki jest przekazywany do funkcji
nasłuchujących... dla przykładu, event_clicked jest typu SCoordinates, więc
mogą go nasłuchiwać metody typu void(SCoordinates), a przy Happen(...)
trzeba podać wartość tego SCoordinates jako argument.

Parę nowych widgetów:
  1. WEntry: do wpisywania tekstu. Na razie prosta wersja, nie przestawia
się kursora, ale można kasować i dodawać literki.
  2. WMultilineText: Działa tak jak kilka WLabel jedna pod drugą. Wrzuca
się stringa z wieloma \n, a wyświetli się w nowych linijkach. Nie umie
zawijać tekstu, nie umie innych porządnych sztuczek, ale wystarcza by
wyświetlić ciut więcej tekstu.
  3. WProportional: Konterner na tylko jedno dziecko, rozmieszcza je
zgodnie z ustalonymi proporcjami by wyglądało możliwie podobnie niezależnie
od rozmiaru obszaru jaki zajmuje. Szczegóły w pliku nagłówkowym.
Nie mogę sobie przypomnieć, czy coś jeszcze było, a jestem nazbyt leniwy by
sprawdzić.
  (4). Do tego sporo widgetów ma pewne usprawnienia, np WLabel/WButton mają
możliwość ustawienia koloru tekstu, WLayeredView ma też przydatną metodę
HideLayer (analogiczną do Show) i cośtam jeszcze..

Sam schemat prawdziwego interfejsu zorganizowany jest tak, że stworzyłem
kilka klas konkretyzujących widgety i składających je poprzez kompozycję.
Na chwilę pisania tego maila mamy CMainMenu, COptions i CAbout. Każde z
nich reprezentuje kawałek interfejsu złożony z paru widgetów. Całość jest
raczej prosta w implementacji.
Oczywiście to jakim widać interfejs jest na razie tylko propozycją i
schematem, z pewnością to jeszcze wiele razy całkiem przerobimy.

Co do mojego pięknego tła pod menu głównym, to dostałem info od naszego
grafika że za kilka dni dostaniemy zestaw szkiców do obejrzenia,
poprzeglądania, i wybrania jaki motyw nam się podoba. Ponoć od naszej
decyzji do gotowego obrazka w wysokiej jakości potrzeba 1-2 tygodnie, więc
moja śliczna grafika za długo nie pożyje :P

A teraz parę spraw organizacyjnych.

libMillennium urosło do takiego etapu, gdzie da się jakośtam pograć przez
sieć. Millennium Duel dostarcza już liczne środki do tworzenia interfejsu i
zarządzania wyświetlaną treścią.
To jest pora, by zacząć łączyć oba programy ze sobą. A to, zgodnie ze
wstępną umową, reprezentuje koniec pracy nad 0.1.
Niby zostało parę bugów przeznaczonych do zamknięcia w 0.1, ale spokojnie
możemy je odłożyć do 0.2.

A tymczasem ja daję zielone światło do wydania wersji 0.1. Czekam na Waszą
opinię, i jak dojdziemy do wniosku że pora się skupić na kolejnym wydaniu,
to oficjalnie zamkniemy ten rozdział, i zaczniemy porządniejszą zabawę.

No ale właśnie. Co dalej?

Dalej będzie tylko jeszcze ciekawiej. Ale ponieważ jak na razie w ogóle nie
gawędziliśmy o tym co się będzie teraz działo, to czeka nas zdecydowanie
większa narada. Trzeba poomawiać:
  - Mechamizm linkowania MillenniumDuel do libMillennium
  - Kolejne kroki formalizowania zasad rozgrywki w libMillennium
  - Projekt interfejsu w MillenniumDuel
  - Zarządzanie stanem gry w MillenniumDuel
oraz raczej sporo tematów pobocznych i innych.
Taką naradę można w sumie przeprowadzić na dwa sposoby. Możemy się
zobaczyć/spotkać przy tablicy (tablica jest dobra do dyskutowanie projektu
interfejsu), albo, jak byłby kłopot ze zgarnięciem ekipy we Wro, to możemy
się zmówić na naradę przez IRCa.
Mi osobiście obie opcje pasują, aczkolwiek zdecydowanie preferuję
spotkanie, ze względu na znacznie zwiększoną wydajność bezpośrednich
konwersacji oraz tablicę do rysowania.
Będę wdzięczy jakby zainteresowani taką naradą wypowiedzieli się w kwestii
pasujących im terminów (tak, pamiętam, żeście wszyscy powyjeżdżali :] ),
oraz możliwości spotkania "na miejscu".
Dodatkowo takie spotkanie może być okazją dla takich, co gdzieś sie
zagubili lub chcą jakiś rzetelnych wyjaśnień co do jakiś mechanizmów w
kodzie.
No i oczywiście jak macie jakieś własne tematy do przedyskutowania, to są
bardzo bardzo welcome, ale coś czuję że trudno będzie o takie.

No i oczywiście jak się nie znajdą chętni do narady, to też nie ma
problemu, mogę kodzić sam :P
Ale jednak spodziewam się jakiś reakcji po tym mailu :)

Z całą pewnością zapomniałem napisać o masie bardzo ważnych rzeczy.
Spodziewajcie się maila uzupełniającego ;/

cielak

 [1]:
http://bazaar.launchpad.net/~millennium-dev/libmillennium/trunk/view/head:/src/Cards/SDY.cards
 [2]:
http://bazaar.launchpad.net/~millennium-dev/libmillennium/trunk/view/head:/src/Cards/SDK.cards
 [3]:
http://bazaar.launchpad.net/~millennium-dev/libmillennium/trunk/view/head:/src/Cards/generate.py