gtaskm: tworzymy aktywatory na stany zadań

Najpierw zacznę od niefortunnego sformułowania w tytule. Otóż zbiór prezentowanych tutaj programów nie powstał tylko do śledzenia procesów ale także do śledzenia ich wewnętrznych stanów, jeśli autor programu wyrazi taką wolę. W zamierzeniu możemy nie tylko utworzyć zdarzenie w odpowiedzi na zakończenie lub uruchomienie procesu, ale np. na zdarzenie zakończenia pobierania/kopiowania pliku, co również możemy nazywać zadaniami, choć w słowniku informatyka zadanie to raczej proces.

Prezentuję tutaj zbiór programów, a głównie monitor do śledzenia stanów procesów, bo o reszcie programów i jednej biblioteki istnienia użytkownik może nawet nie wiedzieć. Biblioteka i daemon pozwalają procesowi się rejestrować w monitorze, zgłaszać wykonywane czynności, podczynności, a także zgłaszać procent ukończenia i stan każdej z czynności.

Wyobraźmy sobie, że korzystamy z menadżera plików, któremu nakazaliśmy skopiowanie katalogu. Menadżer plików rejestruje zadanie kopiowania,, któremu początkowo ustawia procent ukończenia na zero, a stan na tworzenie struktury podkatalogów. Następnie zmienia stan na kopiowanie plików, a dla każdego podkatalogu tworzy podzadanie, które dotyczą kopiowania pojedyńczych plików. Co zyskujemy? Możemy ustawić, że jeżeli zakończy kopiowanie wszystkich plików, to odegra nam się melodyjka. Niby nic fantastycznego, bo niejeden zwykły zjadacz chleba potrafi takie coś napisać w bashu, ale jest to rozwiązanie dla mniej kumatych i dla tych, co wolą klikać, jak również dla tych, którzy wolą mieć więcej władzy, np. odegranie muzyki mogą anulować w przyjemny sposób (a przynajmniej tak powinno to wyglądać po zakończeniu tworzenia, bo obecnie użytkownik może jedynie definiować nowe zdarzenia; czekam na chętne ręce do pomocy).

Innym przykładem jest uruchomienie zintegrowanego polecenia sleep, jako zliczajki sekund. Następnie użytkownik może utworzyć zdarzenie powiadomienia użytkownika o konieczności wyłączenia komputera po 90% wykonania, a automatycznym wyłączeniu po 100%. Polecenie sleep musiałoby być jednak rzeczywiście przystosowane, gdyż obecne implementacje sleep bazują chyba na oczekiwaniu na odpowiedni sygnał od systemu, a więc proces śpi w momencie wywołania funkcji systemowej sleep i podobnym. Jednak zawsze może taka zliczajka powstać.

Jeszcze innym jest obserwacja pobierania plików z sieci torrent. Zwyczajnie pobieraczka zarejestruje każdy pobierany plik, jako inne zadanie. Będziemy więc mogli np. ustawić, że po pobraniu filmu, automatycznie zacznie się odtwarzać.

O rozwiązaniu

Powyżej był wstęp, a teraz przejdę do opisu i zaprezentuję poniższy filmik.

Monitor ma być ułatwieniem dla osób, które chcą się poczuć w roli poweruserów, jednak nie znających składni bash-a. Oczywiście, że możliwości będą ograniczone. NIe będzie możliwości tworzenia przekierowań wyjścia, m.in z powodu, że takie coś jest jedynie możliwe przed załadowaniem obrazu programu do pamięci. Zresztą, to nie ma być Bonsole - projekt, który przystopowal z powodu zbyt malej mocy obliczeniowej mojego komputera. 8 gibibajtów pamięci to zbyt mało, by zlinkować Firefoksa.

By wszystko działało, to należy uruchomić daemona w sesji użytkownika i monitor, a w razie potrzeby, to ustawić odpowiednią zmienną środowiskową dla programów, które korzystają z mojej biblioteki do komunikacji z daemonem. Zmienna ta wskazuje na nazwy usług DBus, z którymi ma rozmawiać aplikacja. Możliwe jest, aby program wysyłał informacje o swojej robocie kilku daemonom. Nic nie stoi również na drodze, by w przyszłości zintegrować monitor z daemonem.

Obecnie obsługiwane są dwa typy włączników zdarzeń

• ontaskdone - aktywowane, gdy zadanie się zakończy
• onstatuschange - aktywowane, gdy zadanie zmieni status z jakiegoś poprzedniego lub na jakiś nowy

W zamierzeniu ma być także obsługiwane onnewtask, które będzie aktywować zdarzenie, gdy zadanie o określonej ścieżce nazw zostanie utworzone.

Obecnie jest obsługiwany jeden rodzaj akcji dla zdarzenia, a dodatkowo zdarzenie może mieć tylko jedną akcję. Tą akcją jest polecenie powłoki. W przyszłości jednak będzie też proste polecenie (zaimplementowane, jednak brak GUI), wywołanie metody DBus, a także wywołanie zarejestrowanej akcji (tutaj będą obsługiwane najprawdopodobniej pliki *.desktop, a więc będzie można użytkownikowi pokazać opis akcji w jednym z wielu języków).

Podsumowanie

Obecnie wiele narzędzi, jak programy do pobierania plików, oferują coś podobnego. Moim zdaniem, jest to jednak błąd, gdyż za każdym razem robi się to w trochę inny sposób. Lepiej to ujednolicić, pozwalając użytkownikowi lepiej wszystko ogarnąć.

Pragnę zauważyć, iż rozwiązanie nie jest skończone, a jego ostateczny kształt nie jest przesądzony. Dlatego czekam na wasze opinie, jak i czekam na chętnych do pomocy. Jutro opublikuję kod źródłowy.