RPI LCD Dev log – Chaining (łańcuchowanie?) metod

Ten tydzień należał do ulepszeń elementów funkcyjnych menu (które to wreszcie pozwalają na sensowne wyjście z submenu do menu wyższego). Nie byłoby to tak łatwo możliwe, gdyby nie chaining metod. Okazał się on prostym rozwiązaniem, które uwalnia programistę od piekła zależności uprzykrzających korzystanie z wielopoziomowego menu. Jak to działa? Już tłumaczę.

Czytaj więcej

RPI LCD Dev log – porozmawiajmy o obiektowości Pythona

W ostatniej aktualizacji dodałem wersję pre-alpha możliwości tworzenia wielopoziomowego menu. Brakuje kilku tweaków tu i tam ale całość ogólnie działa. Aby zminimalizować ilość kodu potrzebną do tej funkcjonalności zdecydowałem się na oddzielenie funkcjonalności dotyczących samego menu od funkcji związanych konkretnie z wyświetlaczem LCD 16×2. Dzięki temu obiekt RpiLCDSubMenu może dziedziczyć po RpiLCDMenu, które to dziedziczy funkcjonalności bazowego obiektu BasicMenu.

Okazuje się że Python umożliwia inicjalizowanie wybranych „przodków” z pominięciem tych pośrednich. Dzięki temu zamiast tworzyć wciąż i wciąż nowe menu główne (i przypisywać jako menu podrzędne) mogę tworzyć SubMenu na podstawie menu głównego, bez potrzeby ponownej reinicjalizacji modułu wyświetlacza:

Fajna sprawa i bardzo przydatna. Zauważmy, że self.__class__.__bases__ zawraca nam tablicę, gdyż klasa może dziedziczyć po więcej niż jednej klasie nadrzędnej.

 

 

Świąteczny log postępów

W tym tygodniu zrobiłem wskaźnik wybranego aktualnie menu. Niby mało, ale cieszy 🙂 Brakowało też sensownego zdjęcia, jak wygląda przykładowe menu. Od teraz, można takowe podziwiać w banerze tego posta, powyżej. W przyszłym tygodniu mam zamiar zabrać się za menu wielopoziomowe.

Wszystkim czytelnikom życzę wesołych i radosnych świąt i dużo odpoczynku!

RPI LCD Menu zaczyna zachowywać się jak menu

Tydzień minął jak z bicza strzelił, spieszę więc z update’m co ciekawego zdarzyło się w projekcie. Otóż…

Dobre przemyślenie struktury aplikacji to klucz do sukcesu.

Od początku planowałem pisać całość obiektowo. Porobiłem puste pliki na klasy, które chciałem stworzyć, aby rozdzielić poszczególne funkcjonalności. Pisząc kod często robiłem placeholdery (puste funkcje/zmienne) do późniejszego uzupełnienia. Dzięki temu miałem przemyślany zarys aplikacji i wszystko, co muszę robić, to implementacja poszczególnych funkcjonalności. Na początku poświęciłem sporo czasu, żeby to przygotować, bez szczególnych, widocznych na pierwszy rzut oka rezultatów. W tym tygodniu wystarczyło dopisać kilkadziesiąt linijek i z prostej listy, do której można było dodawać nic nie robiące obiekty z jednym stringiem, zrobić działające i nawigowalne menu.

Dobrze przygotuj IDE na początku, albo będziesz żałować później.

Niestety, przekonałem się o tym na własnej skórze. Jak można przeczytać w postach wcześniejszych, do rozwijania tego (i kilku innych) projektów używam Atoma. Początkowo zacząłem zabawy z nim właśnie od Pythona, stąd używałem tabulacji jako tabów. Potem musiałem napisać spory kawałek kodu w javascriptcie (node.js). Przestawiłem zatem znaki tabulacji na automatyczne 2 spacje (tak, aby było zgodnie ze standardem). Gdy wróciłem do projektu biblioteki, zaczęły się moje problemy. Ostatecznie dla projektu w Pythonie stosuje 4 spacje. Wtedy kod wydaje mi się najbardziej przejrzysty. Być może w przyszłości zmienię liczbę spacji, kiedy wybiorę już dogodny standard, który kod powinien utrzymywać. W tym momencie skupiam się bardziej na funkcjonalności 🙂 Warto mieć jednolite ustawienia we wszystkich projektach, lub poprawnie oddzielone w zależności od języka. Oszczędzi to wiele problemów na przyszłość.

Czyli co teraz jest zrobione?

Na dzień dzisiejszy biblioteka pozwala na wykonywanie jednopoziomowych, nawigowalnych i klikalnych menu. Po kliknięciu w wybrany element wykonuje się funkcja do niego przypisana. Przykład można zobaczyć tutaj, a efekt wygląda następująco:

Co się dzieje z RPI LCD Menu?

Mija tydzień za tygodniem a moja biblioteka wciąż funkcjonalnie kuleje. Rozpocząłem pracę nad wyświetlaniem głównego menu. Implementację poszczególnych menu itemów zacząłem od function_item’a, który będzie odpowiadał za wykonywanie przypisanej funkcji po wywołaniu danego eventu. Liczę że w tym tygodniu uda mi się tę funkcjonalność skończyć.

W międzyczasie rozważam wydzielenie z głównego pliku biblioteki, obsługi wyświetlacza LCD, który zaczyna dość mocno puchnąć. Podczas pracy natknąłem się również na problem tabulacji w Atomie. Spacje o tej samej długości co Taby traktuje jako Taby i nie sposób tego rozróżnić. Bywa że przeklejenie kawałka kodu z internetu wymaga ręcznego poprawiania odstępów. Być może jest jakieś jakieś narzędzie załatwiające ten problem, jednak nie chciało mi się specjalnie szukać. Problem zamierzam załatwić linterem, po włączeniu którego mój kod świeci kolorowo, niczym choinka na święta. Przeważające warningi dotyczą użycia tabów zamiast spacji. Prawdopodobnie i tak będę musiał dostosować kod do standardów obowiązujących w Pythonie, czy tego chce czy nie, jednak na ten moment skupiam się na funkcjonalności.