Dynamiczne dostosowywanie rozdzielczości, w reakcji na przeciąganie za krawędź ramki okna, okazało się większym wyzwaniem niż przypuszczałem. Po kilku przeprowadzonych testach doszedłem do wniosku, że zastosowanie metody ".config" na poszczególnych elementach stanowczo odpada. Jest to oczywiście wykonalne, jednak wraz ze zrostem ilości elementów, ilość kodu wymaganego do przeprowadzania konfiguracji również rośnie i nie wygląda to ani ładnie, ani czysto. Natomiast testy z zastosowaniem relacji "parent-children" okazały się niepowodzeniem. Nie znalazłem podobnego rozwiązania w internecie, które mogło by mi pomóc w zrozumieniu na czym polega błąd mojej implementacji, mimo że znalazłem kilka zastosowań metody ".winfo_children".
Kolejną sprawą jest również to, że przeliczanie pozycji i ewentualnie wielkości elementów, musiało by się również odbywać dla nieutworzonych elementów okna. Nie byłoby to problemem, jeśli elementy te byłyby tworzone, ale nie umieszczane na formularzu. Jednak jakiekolwiek użycie metody ".destroy" mogłoby powodować błędy, jeśli przy kolejnym przeliczeniu wielkości i pozycji, program próbowałby odwołać się do nieistniejącego elementu. Przez to zastosowanie interfejsu posiadającego tylko jedno okno, byłoby bardzo trudne, o ile w ogóle niemożliwe do wykonania.
Zamiast tego rozwiązania, dałem użytkownikowi do wyboru kilka rozdzielczości, wielkości okna aplikacji, a dla łatwiejszej implementacji i zmniejszenia ilości zbędnego kodu, zmiany są wprowadzane po resecie programu. Przy czym wymaga to ingerencji użytkownika i musi być wykonane ręcznie. Wybrana rozdzielczość ekranu przechowywana jest w pliku "settings" wraz z innymi ustawieniami.
Zacząłem też budować elementy z zakładki "markers". Jak na razie przewiduję możliwość zliczana 8 próbek oraz możliwość nadania 4 odrębnych klasyfikatorów, ale będących wspólnymi dla wszystkich próbek. Wywodzi się to z prostego sposobu rozumowania. Zakładając przypadkowo, że jeśli ornitolog będzie chciał zliczyć ptaki z wczytanej fotografii, to określonymi próbkami będą dane gatunki ptaków, czyli przypuśćmy dla zobrazowania - "Sikora Bogatka", "Sikora Modra" i "Zięba". Natomiast obranymi przez owego ornitologa klasyfikatorami będą mogły być - "Samiec", "Samica", "Osobnik młodociany" i "Nie można określić", które są wspólne dla wszystkich próbek. Dzięki temu podziałowi przeliczanie statystyk oraz eksportowanie pliku z wynikami będzie proste.
Wyzwaniem będzie skonfigurowanie przycisku wyboru klasyfikatora, jako przełącznika, to znaczy tak aby po naciśnięciu pozostał on widoczny jako wciśnięty. Można tego dokonać poprzez zastosowanie metody ".state". Aczkolwiek zmiana ta tyczy się tylko wyglądu. Przycisk, któremu nadano status "disabled" pozostaje nadal aktywnym, a kliknięcie na niego spowoduje wywołanie przypisanej metody. W tym przypadku nie jest to problem, ponieważ ponowne naciśnięcie danego przycisku spowoduje jedynie ponowną aktywację wybranego już markera. Jednak jeżeli chciałbym zastosować tą metodę, do przycisku, który powiększa marker, a wielkość markera miałaby pewne ograniczenie w wielkości, to napotkam już pewien problem. Można to w prosty sposób obejść, ale owe obejście nie jest sposobem eleganckim, jest w założeniu proste dla jednego przycisku. Jednak w momencie wzrostu ilości takich przycisków i chęci sekwencyjnego ich aktywowania, kiedy np. Przycisk 2 staje się aktywny po naciśnięciu Przycisku 1, złożoność programu rośnie i trudniej określić, które przyciski w danym momencie mają pozostać aktywne. Być może uda mi się znaleźć rozwiązanie, które będzie bezpośrednio blokowało event przycisku, utworzenie nowej klasy z wykorzystaniem dziedziczenia i dodanie nowego atrybutu wydaje się być równie dobrym pomysłem.
Brak komentarzy:
Prześlij komentarz