DockPanel Suite

Kto używał któregokolwiek IDE z pakietu Visual Studio, ten wie, jak łatwo, szybko i wygodnie można tam zmienić konfigurację okienek, pasków i innych żyjątek. Nic dziwnego zatem, że we własnym edytorze chciałoby się mieć podobne możliwości – w końcu to użytkownik aplikacji będzie wiedział, jaki układ będzie mu pasować najbardziej.

Niedawno dowiedziałem się o istnieniu biblioteki, która pozwala łatwo, szybko i wygodnie umożliwić użytkownikowi właśnie taką łatwą, szybką i wygodną zmianę konfiguracji okienek we własnym oprogramowaniu. Biblioteka nazywa się DockPanel Suite i można ją ściągnąć z SourceForge (zarówno binarki, jak i źródła czy dokumentację). Wystarczy parę minut, i już mamy w edytorze możliwość przemieszczania, dokowania i zwijania okienek. I zapis layoutu do pliku XML gratis

Kółko i krzyżyk jako moduł jądra Linuksa

Linuksa raczej nie używam i używać raczej nie będę, dlatego kwestia pisania własnych modułów do linuksowego kernela niezbyt mnie interesowała. Niedawno jednak natrafiłem na krótki artykuł pokazujący jak stworzyć prosty moduł – a, że wydawało się to bardzo proste (i w rzeczywistości było, ale o tym dalej), postanowiłem napisać jakąś mini grę działającą jako moduł kernela – wybór padł na kółko i krzyżyk.

Po zdobyciu się na uruchomienie Linuksa przywitał mnie czarny ekran konsoli (jak już pisać moduł, to pr0, nie w okienkach ). Uruchomiłem vima (o dziwo pamiętałem jeszcze, jak się zapisuje plik i wychodzi ) i przypominając sobie C napisałem najpierw Zgadnij liczbę. Działało – napisałem więc kółko i krzyżyk, skompilowałem, załadowałem moduł – i chwilę pograłem. Powiem tyle – C to paskudny język

Screena nie będzie, bo nie umiałem zrobić

Githyanki i serializacja

Pierwszy akt Neverwinter Nights 2 za mną (git Janki sobie poszły), więc pora zająć się znowu czymś pożyteczniejszym W międzyczasie przymusiłem Bulleta do bliższej współpracy z Shadow Clones (słowo daję, dokumentacja Newtona w porównaniu do tego “czegoś”, co jest dostępne z Bulletem to cudo – nieokomentowany kod potraktowany doxygenem, eh…) i dopisałem kolejne partie kodu do mojego frameworka – obsługę serializacji. Głównym założeniem było to, by (de)serializowany obiekt nie miał pojęcia, skąd się biorą wczytywane dane i mógł jedynie określić ich kolejność. Przygotowałem sobie do tego 2 typy archiwów – XML i binarne i od razu przeprowadziłem test na różnicę w prędkości serializacji i deserializacji – oczywiście, archiwum binarne było szybsze. Wiele, wiele razy Przykładowy kod:

class Bar
{
public:
	void load(serialization::Deserializer* arch)
	{
		arch->read(mFoo);
	}

	void save(serialization::Serializer* arch) const
	{
		arch->write(mFoo);
	}

private:
	std::string mFoo;
};

class Foo
{
public:
	void load(serialization::Deserializer* arch)
	{
		arch->read(mBar1);
		arch->read(mBar2);
		arch->read(mBar3); // mBar3.load(arch)
		arch->read(mBar4);
		arch->read(mBar5);
	}

	void save(serialization::Serializer* arch) const
	{
		arch->write(mBar1);
		arch->write(mBar2);
		arch->write(mBar3); // mBar3.save(arch)
		arch->write(mBar4);
		arch->write(mBar5);
	}

private:
	std::string mBar1;
	int64 mBar2;
	Bar mBar3;
	uint32 mBar4;
	float mBar5;
};

void test()
{
	Foo foo;

	serialization::Deserializer* des = new serialization::BinarySequenceArchive("tralala", serialization::LOAD);
	foo.load(des);
	delete des;

	serialization::Serializer* ser = new serialization::XMLArchive("bambi.xml", serialization::SAVE);
	foo.save(ser);
	delete ser;
}

Niezwykle przydatna przy pisaniu testów okazała się konsolka połączona z systemem skryptów – możliwość pisania testów w zależności od wyników poprzednich w czasie działania programu było chyba najfajniejsze