millennium-dev team mailing list archive

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

Okej, dokończyłem sprzątanie i detale; z mojej strony uważam zarówno
libMillennium jak i MillenniumDuel jako gotowe do wydania 0.1.
Staram się jak mogę by nie kodzić dużo gdy Was nie ma, ale kiepsko mi to
szło.
Na szczęście w sobotę wyjeżdżam na równo tydzień, więc co po niektórych
bardzo ucieszy że nie będę dowalał nowych commitów.
Ale spodziewajcie się, że po powrocie zacznę robotę od wydania w końcu tego
0.1. No chyba że w międzyczasie coś ze sobą ustalicie, albo ktoś
zaprotestuje.


W dniu 8 sierpnia 2013 23:19 użytkownik Rafał Cieślak <
rafalcieslak256@xxxxxxxxxx> napisał:

> 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
>