Zapisywanie ustawień aplikacji – QSettings w QT
Kontynuując tradycję rzadkich wpisów o ciekawych rzeczach które warto poznać/wykorzystać chciałbym wam przybliżyć trochę klasę QSettings. Do tej pory większość moich aplikacji nie potrafiło sensownie obsługiwać pamiętania różnych drobiazgów między uruchomieniami. Często najważniejsze rzeczy zapisywano w jakimś "własnym" typie plików, podczas gdy cała reszta była resetowana po każdym uruchomieniu.
Klasa QSettings rozwiązywała część tych problemów - pozwalając skierować grupę ustawień do pliku/rejestru. Niestety, pierwszy wymyślony sposób ich użycia stał się bardzo szybko uciążliwy - zapisywanie setek ustawień w jednym miejscu, pilnowanie aby odczyt zgadzał się z zapisem - jak łatwo się domyślić szybko stało się to nie do opanowania.
Niedawno czytając dokumentację, i stając przed podobnym problemem znalazłem sensowniejsze podejście - wraz z dostarczonymi metodami pozwalające zminimalizować nakład pracy.
Zacznijmy od samego początku naszego programu, dostarczając parę istotnych informacji:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QApplication::setOrganizationName("RainLabs");
QApplication::setOrganizationDomain("rainlabs.pl");
QApplication::setApplicationName("Orbi Eye");
QApplication::setApplicationVersion("0.2 alpha");
AutoPhotoAdvanced b;
b.setWindowTitle(QApplication::applicationName()+" v"+QApplication::applicationVersion());
b.show();
return a.exec();
}
Po takim wywołaniu każda klasa potrzebująca skorzystać z ustawień może to zrobić niezwykle szybko i wygodnie - np. w konstruktorze/destruktorze, za pomocą:
QSettings settings;
settings.setValue(....) / settings.value(...)
dzięki takiemu podziałowi każde ustawienia są niezależne, zaś dokonane na początku ustawienia aplikacji pozwalają korzystać z domyślnego konstruktora, co ułatwia ich używanie w całym programie, nie uciekając się do kopiowania kawałka kodu tam i z powrotem lub co gorsza pamiętania jakie argumenty przekazać za każdym razem konstruktorowi.
Darmowe mapy do użytku komercyjnego?
Wielokrotnie przygotowując projekt uwzględniając jakiekolwiek zależności geograficzne potrzebowałem mapy. Często dowolnej, przykładowej. Pomijając już użycie jako programista - ile razy potrzebowałeś mapy do potrzeb projektu graficznego?
Większość z nas nie zastanawia się kto jest właścicielem map które "za darmo" ogląda się w sieci. Zarówno w przypadku GoogleMaps, portalu zumi.pl czy innych serwisów związanych z mapami, nawigacją sytuacja jest niestety trudna. Właścicielem map są najczęściej duże firmy kartograficzne, czerpiące zyski z tytułu posiadania praw majątkowych do tych map. Nawet zrobienie PrintScreena takiej mapy może zakończyć się wycieczką na salę sądową - oczywiście im większą "korzyść" my z tego tytułu odniesiemy (lub im większa mogą odnieść wygrywając z nami) tym bardziej jest to prawdopodobne.
Kończąc to czarnowidztwo chciałbym polecić wam idealne rozwiązanie takich problemów - serwis http://www.openstreetmap.org/. Zawiera on dokładne mapy większości miejsc na ziemi, i umożliwia ich eksport w olbrzymiej ilości formatów. Najważniejsza jest jednak licencja - Creative Commons, BY-SA. dopuszcza ona także użytek komercyjny (a takim jest chociażby mapka dla uczestników dowolnego eventu), oraz tworzenie dziel pochodnych (czyli np. wplatanie ich w inne publikacje). Linkuję jeszcze link do FAQ na temat kwestii prawnych: http://wiki.openstreetmap.org/wiki/Legal_FAQ.
Mam nadzieję, że dzięki tej wiedzy unikniecie zbędnych wątpliwości/kłopotów, promując przy okazji kolejną świetną inicjatywę.
Integracja Eclipse CDT z CodeSourcery dla ARM Cortex-M3
Na blogu znajomego zamieściłem wpis na temat związany z nowoczesnymi mikrokontrolerami z którymi ostatnio miałem doczynienia - zapraszam do lektury.
Link: Integracja Eclipse CDT z CodeSourcery dla ARM Cortex-M3
System sprzedaży biletów na Bal Elektryka 2010
W okresie grudnia uczyłem się trochę Symfony (akurat było to 1.4.1 i Doctrine). Wynikiem i powodem zabawy był system sprzedaży biletów na tegoroczny Bal Elektryka.
Główną inspiracją był system Balsit, stworzony przez Rafała Bednarza na Bal w roku 2009. W przypływie nadmiernej chęci do pacy stwierdziłem, że można go napisać od nowa, rozbudowując niektóre możliwości/zmieniając funkcjonalność.
System składa się z front-endu do rejestracji gości - każdy chcący kupić bilet rejestrował się na komputerze, członek naszego samorządu sprawdzał poprawność wpisanych danych. Użytkownik otrzymywał unikalny numer, potrzebny zaraz przy następnym stanowisku.
Sprzedawca obsługiwał system sprzedaży - kupujący wybierał miejsce, wpłacał należność i otrzymywał wypisany bilet. Relacje tworzone były automatycznie, system ułatwiał sprzedaż biletu parom.
Całościowo umożliwił osiągnięcie tempa powyżej 2 biletów na minutę 
Sam system nie wykorzystywał innowacyjnych pomysłów - po prostu wykorzystywał wielkie możliwości frameworka
Załączam skompresowane źródła, włącznie z użytym Symfony 1.4.1: balsit 0.8.
Modelowanie urządzenia hamującego lądujący samolot
Sprawozdanie dotyczące modelowania urządzenia hamującego samolot. Skupiono się w nim na aspektach takich jak modelowanie fizyki pomiędzy oddziaływającymi elementami, oraz ewentualne modyfikacje mające wpływ na działanie całego systemu.
Jest również jedyne moje sprawozdanie z zadań 5,6,7,8, gdyż pozostałe mogły być dostarczone bez opisu - jako działające modele.
Sprawozdanie 5 - Modelowanie urządzenia hamującego lądujący samolot (1/2)
Prototypowanie sterownika dla robota APR-20
Kolejne, jeszcze krótsze sprawozdanie. Tym razem sterownik pozwala niezależnie sterować wszystkimi 5 serwomechanizmami w robocie. Sterownik jest o tyle prymitywny, że nie umożliwia zadawania żadnych trajektorii. Z informacji przez nas uzyskanych wynika, że taki prawdziwy sterownik stworzymy w bliżej nieokreślonej przyszłości
Sprawozdanie 7 - Prototypowanie sterownika dla robota APR-20
