– –

Styczeń

Przez cały miesiąc pięć razy wybrałem się rowerem na zakupy, dzięki oponom z kolcami. Do tego tylko dwa razy przejechałem się dla frajdy. Raz skończyło się na 20 kilometrach, bo okazało się po kilku kilometrach, że szosa jest sucha i czysta tylko do granicy gminy, a dalej zaczyna się częściowo zmarznięty szary śnieg. Na szczęście za drugim razem drogi były już wolne od takich niespodzianek i udało się wykręcić ponad 36 kilometrów.

– –

Luty

Przymroziło zdrowo i przez pierwsze dwa tygodnie tylko raz wsiadłem na rower, by pojechać na zakupy. Na szczęście później zrobiło się przyjemniej i mogłem wybrać się na rowerowanie trzy razy: na lokalną pętelkę 36 km, Małą Pętlę Notecką oraz trochę dłuższe kulanie po okolicy (57 km).

– –

Marzec

W marcu zaczęło robić się cieplej i pojeździłem trochę więcej – pięć razy na zakupy i siedem dla frajdy.

W pierwszym tygodniu najpierw zaliczyłem kolejną trasę 50+, a potem machnąłem prawie 80 km w sporej części po leśnych szutrach.

Drugi tydzień to tylko wyjazd na zakupy, nie pamiętam dlaczego, ale podejrzewam, że mogło być tam jakieś załamanie pogody. Za to 17 marca wybrałem się do Gdańska (pociągiem, nie rowerem), na bike sizing w tamtejszym VeloLABie, by mój następny gravel jak najlepiej pasował do mnie.

O całym procesie wyboru i kupowania napiszę osobną notkę, gdy nakulam trochę więcej kilometrów na nowej maszynie. Może po przejechaniu 2k?

Kolejny tydzień to dwie jazdy w okolicy 40 kilometrów, pierwsza jeszcze ze starym komputerkiem GPS od Lezyne, druga już z nowym Coros Dura, kupionym z myślą o kilkudniowych wyjazdach na następcy wysłużonego Ridleya.

W tej chwili mam nakręcone na nim prawie 800 km i jestem bardzo zadowolony, zwłaszcza z czasu pracy na baterii. Dzięki ładowaniu ze słońca nie musiałem go podłączać do ładowarki ani razu od początkowego naładowania do 100%, a nadal ma ponad 43%. Więcej pewnie napiszę w osobnym tekście.

Później zaliczyłem jeszcze wypad na łapanie skwadratów w północno-wschodnim rogu mojego ubersquadratu, dzięki czemu powiększyłem go do rozmiaru 21×21 i w końcu „nadejszła wiekopomna chwila”, czyli przyjechał mój nowy rower, Caynon Grizl 7 w kolorze affogato, czyli kawy z lodami waniliowymi. Jak na złość akurat nie miałem czasu wybrać się na dłuższe kulanie i pierwsza jazda to tylko 36 km.

Dopiero kilka dni później, ostatniego dnia marca, mogłem wyskoczyć na kolejne zbieranie skwadratów, tym razem w północno-zachodnim rogu. 95 kilometrów, w części po lasach i polach, pokazało mi, że dobrze wybrałem, bo jechało się świetnie.

– –

Podsumowanie

W sumie w ciągu pierwszego kwartału 2026 zaliczyłem tylko 11 wypadów na zakupy (łącznie ok. 120 kilometrów) i 12 dla frajdy (610 km). W porównaniu z tym samym okresem 2025 zrobiłem o 44 kilometry więcej, więc mogło być gorzej.

W czasie pisania tego tekstu już wiem, że w kwietniu nie uda mi się zachować tej tendencji, głównie przez pracę, ale mam tak wielką frajdę z jazdy na nowym rowerze, że każda minuta spędzona na Gryzelku liczy się podwójnie.

Spis treści

• Wprowadzenie
• Tłumaczenie przy użyciu webinterfejsów
  • Weblate
  • Crowdin
• Przez ręczną edycję plików
• W polskim zespole GNOME

– –

Wprowadzenie

W końcu przyszła pora na mój ulubiony sposób angażowania się w WiOO, czyli tłumaczenie programów, tak by jak najwięcej osób mogło z nich korzystać.

W tej chwili mam na koncie tłumaczenie na polski m.in.:

• klienta Fediwersum Tuba,
• androidowych klientów fedi Pixelix oraz Pachli,
• edytora Markdown Scratchmark,
• klienta Tidala Tonearm,
• strony Join the Fediverse,
• aplikacji pogody Mousam,
• wtyczki dla WordPressa Embed Consent.

Przy okazji nauczyłem się zupełnie nowych rzeczy. Dzięki Tubie i Pixelix poznałem interfejsy do tłumaczenia Weblate i Crowdin, dla Join the Fediverse dowiedziałem się jak forkować repozytorium i tworzyć merge request ze zmianami, a Mousam zawdzięczam poznanie tworzenia plików tłumaczenia przy użyciu narzędzi gettext. Dla kogoś innego to może być masa roboty, dla mnie zdobywanie nowych umiejętności i doświadczeń jest jedną z zalet angażowania się w WiOO.

Na podstawie powyższej listy mogliście się zorientować, że samo przetłumaczenie komunikatów to nie wszystko, bo trzeba jeszcze nasze tłumaczenie przekazać osobom tworzącym program, aby mogły je do niego włączyć. Można to zrobić na różne sposoby, w zależności od mechanizmów, które oferuje konkretny projekt. Żeby sprawdzić, który jest dostępny w danym przypadku, trzeba zacząć od zajrzenia na stronę programu.

– –

Tłumaczenie przy użyciu webinterfejsów

Spora część aplikacji, które są rozwijane już dłuższy czas, dorobiła się mechanizmów ułatwiających tłumaczenie. Najczęściej są to wyspecjalizowane serwisy, z których najpopularniejsze są Weblate i Crowdin. Jeżeli na stronie projektu znajdziecie wzmiankę o którymś z nich, wasza praca przy tłumaczeniu będzie prosta i wygodna.

Zabawa zaczyna się od założenia konta w używanym przez dany program serwisie, po czym przechodzimy do wybranego projektu. Na liście dostępnych języków szukamy tego, na który chcemy tłumaczyć. Jeżeli już jest, możemy od razu przejść do tłumaczenia, w przeciwnym przypadku, trzeba najpierw go dodać.

W Weblate robi się to kliknięciem mało rzucającego się w oczy plusa, znajdującego się po lewej stronie nad ikonkami ołówka przy liście dostępnych tłumaczeń. Potem wybieramy język, na który chcemy tłumaczyć i klikamy „Rozpocznij nowe tłumaczenie”.

Na Crowdin trzeba kliknąć „Poproś o nowy język” i poza wyborem języka dodać wiadomość dla osób zarządzających projektem. Nie miałem okazji tego robić, ale zakładam, że taka prośba musi być ręcznie zatwierdzona, więc być może trzeba będzie trochę poczekać.

Gdy mamy już konto i wybrany język jest dostępny na liście tłumaczeń, możemy przystąpić do pracy, chyba że trafiliśmy na rzadki wypadek, w którym osoba rozwijająca oprogramowanie wymaga zaakceptowania „Contributor Licence Agreement”. Do tej pory przydarzyło mi się to tylko raz, przy tłumaczeniu Pachli.

Teraz już naprawdę możemy zabrać się za tłumaczenie. W większości małych i średnich programów całość tekstów do przetłumaczenia (nazywanych wiadomościami lub ciągami) jest zebrana w jednym module. Niektóre aplikacje, takie jak Pachli właśnie, rozbijają je na kilka różnych. Takie rozwiązanie ma swoje wady i zalety. Niektórym pewnie łatwiej ogarnąć garść ciągów na raz zamiast długiego zestawu, ja wolę raczej mieć wszystko w jednym miejscu.

No dobrze, mamy konto, wybrany język jest dostępny, zaakceptowaliśmy licencję i wklikaliśmy się w moduł do tłumaczenia. Co dalej? Zostało nam żmudne wypełnianie formularzy.

– –

Weblate

Powyżej znajduje się zrzut interfejsu Weblate z otwartym polskim tłumaczeniem Tuby. Pasek nad boksem „Tłumaczenie” pozwala na nawigację po ciągach i pokazuje aktualną pozycję na tle całości. Pole obok umożliwia wyszukiwanie ciągów spełniających określone wymagania (nieprzetłumaczone, oznaczone do dalszej edycji, z komentarzami itp.), a ostatnie służy do sortowania wiadomości do przetłumaczenia, dzięki czemu możemy np. szybko dotrzeć do ciągów ostatnio dodanych do aplikacji.

Główną część okna zajmuje miejsce na właściwe tłumaczenie. Pierwsze od góry jest pole z opisem ciągu dodawanym przez osoby tworzące aplikacje. Taki opis jest bardzo pomocny, zwłaszcza gdy trudno na podstawie ciągu źródłowego zorientować się, jaki jest kontekst jego wystąpienia, lub gdy w wiadomości występują jakieś zmienne (tutaj to %s oznaczające ilość wpisów).

Szkoda, że stosowanie opisów nie jest powszechniejsze, bo często zdarza się, że trudno zorientować się, jak najlepiej przetłumaczyć komunikat, bo np. w aplikacji oryginalny zwrot występuje w kilku miejscach, a każde wystąpienie po polsku będzie brzmiało inaczej. Tutaj może pomóc znajdująca się w prawej kolumnie informacja „Położenie ciągu źródłowego”, dzięki której możemy jednym kliknięciem otworzyć plik źródłowy i zobaczyć, gdzie znajduje się ten ciąg. Niestety, wymaga to chociaż podstawowej umiejętności czytania kodu.

Prawie zawsze w czasie tłumaczenia poza oknem, w którym pracuję, mam otwartą też aplikację, nad która pracuję, oraz repozytorium z kodem źródłowym, żeby móc odnaleźć kontekst, w którym występuje przekładany akurat tekst.

Pod opisem mamy oryginalną wiadomość. Tu wybrałem dla was rzecz trochę rzadszą, bo mamy do czynienia z rzeczownikiem z liczbą pojedynczą i mnogą. Jak widzicie, w angielskim to są dwa pola, u nas już trzy, ponieważ „posts” będziemy tłumaczyć inaczej w zależności od tego, czy to są „trzy wpisy”, czy „pięć wpisów”. Czerwone magiczne zaklęcie pod polami na tłumaczenie to formuła definiująca, dla jakich liczb występują odmienne formy liczby mnogiej.

Zazwyczaj jednak mamy do czynienia z prostą wersją jeden ciąg źródłowy = jeden ciąg przetłumaczony, ale wolałem wyjaśnić sprawę form liczby mnogiej, żebyście się nie dziwili, o co tu chodzi.

Pod polami na tłumaczenie znajduje się pole „Wymaga edycji”. Można go użyć, gdy np. nie jesteśmy pewni tłumaczenia i będziemy chcieli do niego wrócić.

Dwa z trzech przycisków poniżej są dość oczywiste: „Zapisz i kontynuuj” zapisze nasze tłumaczenie i przejdzie do następnego ciągu, „Zapisz i zostań” również zapisze, ale pozostanie w miejscu. Co robi „Zaproponuj”? Jeżeli chcemy poprawić czyjeś tłumaczenie, ale bez wcinania się w pracę tej osoby, możemy zaproponować swoją wersję. Taką sugestię osoba tłumacząca będzie potem mogła zaakceptować lub odrzucić, czasem też dodając komentarz tłumaczący decyzję.

Pod tłumaczeniem znajduje się pięć kart z przydatnymi narzędziami. Pierwsze z nich to „Ciągi sąsiadujące”, pozwalające czasem na umieszczenie wiadomości w kontekście lub przypomnienie sobie tłumaczenia zbliżonych tekstów. „Komentarze” to po prostu miejsce na skomentowanie tłumaczenia, z możliwością oznaczania zarówno innych tłumaczy, jak i osób tworzących aplikację. „Automatyczne sugestie” to tłumaczenia pochodzące z serwisu LibreTranslate oraz podsuwane na podstawie pamięci tłumaczeń, w której wyszukiwane są tłumaczenia podobnych ciągów. W „Innych językach” możemy sprawdzić, jak ten ciąg był przełożony w innych wersjach językowych, co jest przydatne raczej tylko dla osób posługujących się wieloma językami, a karta „Historia” pozwala na prześledzenie zmian w tłumaczeniu: kto, jak i kiedy przełożył ciąg.

W kolumnie po prawej, poza wspomnianym już odnośnikiem do pliku źródłowego, znajdują się informacje dotyczące ciągu, w tym data powstania i ostatniej aktualizacji. Powyżej znajduje się funkcja, której jeszcze nigdy nie użyłem, czyli „Słownik”, który pozwala na zapisanie własnych terminów, co pewnie jest bardzo przydatne zwłaszcza przy tłumaczeniu aplikacji używającej jakiejś zaawansowanej terminologii, gdy musimy pamiętać specjalistyczne słownictwo.

– –

Crowdin

Muszę przyznać, że nie jestem fanem Crowdin i jego interfejs uważam za mniej wygodny niż Weblate. Jak widać na zrzucie powyżej, bardzo różni się od tego drugiego serwisu, ale po przyjrzeniu się rozpoznacie podobne elementy. Lewa strona to przeglądarka ciągów (można przełączyć ją na przeglądanie plików) z opcjami ich filtrowania i sortowania.

Część środkowa to ciąg źródłowy z kontekstem (i możliwością zapytania o niego) oraz miejsce na tłumaczenie. Poniżej znajdują się informacje o tłumaczeniu oraz sugestie z pamięci tłumaczeń oraz tłumaczenia maszynowego Crowdin Translate. Jest też możliwość podejrzenia wersji w innych językach.

Prawa strona to miejsce na komentarze tłumaczy, w tym przypadku proszących o zmianę, gdyż forma, w jakiej ciąg występuje w aplikacji, nie działa w ich językach.

Zamiast komentarzy można włączyć panel przeszukiwania pamięci tłumaczeń, słownika i kontekstu, oraz asystenta AI (ha, tfu!).

– –

Tłumaczenie poprzez edycję plików

Tu już mamy do czynienia z trochę bardziej zaawansowanym tematem, bo takie tłumaczenie wymaga znajomości podstaw obsługi repozytoriów git i gotowości do posługiwania się trybem tekstowym. Konieczność sięgnięcia po ten tryb tłumaczenia pojawia się zwłaszcza w przypadku młodych projektów, które nie dorobiły się jeszcze integracji z np. Weblate.

Zanim zabierzemy się za jakiekolwiek dłubanie, warto sprawdzić, czy aplikacja w ogóle jest przetłumaczalna, czyli osoby ją tworzące napisały ją w sposób pozwalający na wyświetlanie różnych wersji językowych. Najprościej to zrobić rozglądając się w repozytorium kodu programu za katalogiem z plikami tłumaczeń.

Jeżeli aplikacja korzysta z gettext, czyli najpopularniejszego systemu tworzenia wielojęzycznego oprogramowania, to katalog ten najczęściej nazywa się po prostu po, ale spotkałem też np. i18n oraz l10n.

Te dwa ostanie ciągi znaków to sprytne skróty oznaczające internationalization oraz localization, a cyferki w nich to po prostu liczba znaków między pierwszą a ostatnią literą.

Jeżeli nie znajdziecie żadnego śladu po wersjach językowych w kodzie aplikacji, to jedyne, co możecie zrobić, to skontaktowanie się z osobami ją rozwijającymi i zasugerowanie dodania obsługi wielu języków. Najprościej to zrobić przez dodanie Issue na stronie projektu, najlepiej z tagiem Enhancement.

Jeśli jednak aplikacja okaże się przekładalna, możemy brać się za tłumaczenie. Żeby to zrobić, trzeba zacząć od stworzenia własnej kopii repozytorium, czyli zrobienia forka, do czego będziemy potrzebować konta w serwisie, w którym jest rozwijany dany program (np. Codebergu, GitHubie lub GitLabie).

W tej części będę sporo posługiwać się systemem kontroli wersji o nazwie Git. Pozwala on na zapanowanie nad zmianami w kodzie i np. cofanie ich, jeżeli były błędne, a także tworzenie gałęzi, w których trwa rozwój różnych funkcjonalności i późniejsze ich scalanie. Większość rzeczy będzie można załatwić przez interfejsy WWW, ale jeżeli spróbujecie obsługi z linii poleceń, możecie uznać, że jest dużo wygodniejsza i szybsza. W poznaniu obsługi git mogą pomóc gry w rodzaju Oh My Git!, Learn Git Branching czy GitMastery.

– –

Jak wygląda przebieg tłumaczenia pokażę na przykładzie Blood Pressure, aplikacji, którą znalazłem niedawno na Flathub.org, po tym, jak lekarz kazał mi przez tydzień mierzyć ciśnienie i zapisywać wyniki.

Po zalogowaniu na gitlab.com i przejściu do strony projektu klikam na przycisk Fork w prawym górnym rogu, po czym wypełniam krótki formularz. Zazwyczaj po prostu dodaję litery PL do nazwy repozytorium i informację w rodzaju „Polish translation” do opisu, tym razem się rozpisałem trochę bardziej

W tym momencie mam już swoje repozytorium i mogę zabierać się od razu za tłumaczenie. Mógłbym to zrobić przez edycję plików przy użyciu interfejsu GitLaba, ale wygodniej mi będzie pracować na plikach na dysku.

Jeżeli chcecie uniknąć pracy w terminalu, gdzie się tylko da, to po kliknięciu zielonego przycisku Code wybieracie opcję Download ZIP, to jednak oznacza, że stworzone i zmodyfikowane pliki będziecie trzeba wgrywać przez przeglądarkę.

Jeśli wybierzecie tryb tekstowy, to repozytorium klonuje się poleceniem git clone, po którym można podać albo adres sieciowy repozytorium w rodzaju

git clone https://gitlab.com/LukaszH77/cisnienie-krwi.git

albo SSH

git clone git@gitlab.com:LukaszH77/cisnienie-krwi.git

Ta druga opcja jest na dłuższą metę wygodniejsza, ale wymaga konfiguracji kluczy SSH w systemie oraz w serwisie z repozytorium. Ten wpis i tak będzie bardzo długi, więc nie podejmę się w nim jeszcze tłumaczenia działania i tworzenia kluczy SSH. Zarówno GitLab, jak i GitHub oraz Codeberg mają tę procedurę opisaną krok po kroku.

W końcu mamy pliki na dysku i można się przyjrzeć, z czym będziemy pracować.

Tłumaczenia przy użyciu systemu gettext opierają się na kilku rodzajach plików. POTFILES (lub POTFILES.in) zawiera listę plików źródłowych, w których znajdują się przetłumaczalne ciągi, a LINGUAS to lista języków, na które przetłumaczono aplikację. Plik z rozszerzeniem .pot (zazwyczaj nazwa_programu.pot) to wygenerowany przez gettext szablon tłumaczenia i na jego podstawie powstają pliki .po z konkretnymi wersjami językowymi (np. pl.po dla polskiego, pt_BR.po dla brazylijskiej wersji portugalskiego itd.).

W przypadku Blood Pressure nie było tego pierwszego pliku, więc postanowiłem przy okazji uzupełnić ten brak. Po jego przygotowaniu mogłem wygenerować szablon tłumaczenia poleceniem

xgettext --from-code=UTF-8 --keyword=_ --keyword=C_:1c,2 --output=po/blood-pressure.pot -f po/POTFILES

Parametry użyte w tym poleceniu wskazują jak jest kodowany plik, jak oznaczane w kodzie są przetłumaczalne ciągi, jak ma nazywać się tworzony plik .pot oraz z jakiej listy ma skorzystać.

Na podstawie szablonu plik z tłumaczeniem tworzy się komendą

msginit --locale=pl --input=blood-pressure.pot

wydanym w podkatalogu po.

--locale=pl oznacza oczywiście, że generujemy plik dla języka polskiego, a --input=blood-pressure.pot wskazuje na plik szablonu tłumaczeń.

Po jej uruchomieniu zostaniemy zapytanie o adres e-mail, który ma być podany w pliku jako adres tłumacza. Po wpisaniu adresu i zatwierdzeniu powinien powstać plik pl.po, w którym będziemy wpisywali polskie tłumaczenie. Zanim się za to zabierzecie, warto najpierw otworzyć plik LINGUAS i dopisać pl w osobnym wierszu tak, żeby zachować alfabetyczną kolejność wpisów.

Tłumaczenie można załatwić w jakimkolwiek edytorze tekstu, ponieważ pliki .po są plikami tekstowymi o określonej, dość prostej strukturze. Wiersze zaczynające się od msgid zawierają oryginalny tekst, a w liniach poprzedzonych msgstr wpisujemy tłumaczenie. Każda taka para jest poprzedzona komentarzem zawierającym ścieżkę do pliku i numer linii, w której występuje ciąg, co przydaje się, gdy chcemy sprawdzić kontekst, w jakim się pojawia.

Są jednak wygodniejsze sposoby na tłumaczenie plików .po, moim ulubionym jest program Gtranslator, który powstał na potrzeby tłumaczenia GNOME (o czym więcej napiszę w dalszej części). Można go zainstalować z Flathuba.

Interfejs Gtranslatora jest dość prosty. Główna część okna to lista ciągów i ich tłumaczeń, które wpisuje się w polu na dole. To, co nas interesuje w tej chwili w panelu po prawej, to pola „Wydobyte komentarze” gdzie trafiają informacje dołączone przez osoby tworzące program oraz „Ścieżki” zawierające dane o tym, w jakim pliku i wierszu występuje wybrany komunikat.

Polecam zapoznanie się ze skrótami klawiszowymi (np. Alt + -> to następny komunikat, a Alt + Page Down przechodzi do następnej nieprzetłumaczonej wiadomości), dzięki którym poruszanie się po pliku jest szybkie i wygodne.

Po przygotowaniu tłumaczenia trzeba je wrzucić do naszego repo. Jako że sklonowałem repozytorium przy użyciu git clone, to teraz mogę załatwić to wygodnie w terminalu. Najpierw przy pomocy git add dodaję po kolei pliki (całość zmian można od razu dodać komendą git add .), które utworzyłem lub zmodyfikowałem, a potem poleceniem git commit -m "Opis zmian" tworzę zatwierdzenie. Na koniec zostaje użycie git push do wypchnięcia zmian do zdalnego repozytorium na GitLabie.

Jeżeli zamiast klonować repozytorium pobraliście tylko archiwum zip i pracowaliście na wypakowanych plikach, wszystkie te, które stworzyliście i zmieniliście, musicie teraz przez interfejs WWW wgrać do odpowiednich katalogów, co w przypadku GitLaba załatwia się nawigując po drzewie plików, a po wybraniu właściwego miejsca klikając na ikonkę plusa i wybierając pozycję „Upload file”. Oczywiście także w tym wypadku trzeba będzie podać opis zmiany.

Ostatni krok to wysłanie zmian do oryginalnego repozytorium programu. Na stronie mojego forka klikam „Create merge request” i w formularzu, który się wyświetli mogę opisać na czym polegają zmiany.

Zazwyczaj załatwiam to wcześniej, już w wiadomości dołączonej do zatwierdzenia zmienianych plików i na tej podstawie wypełniany automatycznie jest tytuł merge request, więc muszę tylko zatwierdzić wysłanie oraz zaczekać aż osoby rozwijające aplikację przejrzą moje zmiany i je zatwierdzą.

– –

Praca w polskim zespole GNOME

Właśnie zobaczyłem, że wpis przekroczył już 2,5k słów, więc postaram się tę ostatnią część ograniczyć do minimum.

Jak już nabierzecie trochę doświadczenia przy tłumaczeniu różnych aplikacji, to zapraszam do ekipy tłumaczącej na język polski środowisko GNOME z przylegającymi aplikacjami. Praca tutaj trochę się różni od tej, którą pokazywałem powyżej. Trzeba zacząć od założenia konta w serwisie Damned Lies, zwanego w skrócie DL. Niestety nie można zrobić tego bezpośrednio, tylko trzeba do tego użyć SSO z np. GitLaba lub GitHuba.

Następnym krokiem jest dołączenie do polskiego zespołu. Zespół jest w trakcie reorganizacji, która nałożyła się na natłok pracy przy wydaniu GNOME 50, ale nowa koordynatorka to osoba bardzo dynamiczna i sprawy idą w dobrą stronę. Dorobiliśmy się już forum na oficjalnym Discourse GNOME oraz kanału Matrix, który jest najlepszym sposobem na komunikację z resztą zespołu i zadawanie pytań związanych z tłumaczeniem.

Jeżeli mamy wybrany moduł, który chcemy przetłumaczyć, pracę nad nim trzeba zacząć od zarezerwowania go do tłumaczenia poprzez formularz na stronie modułu. Możemy przy okazji dopisać komentarz, chociaż nie jest to konieczne. Potem pobieramy plik PO i zabieramy się za tłumaczenie.

Do tłumaczenia najlepiej wykorzystać Gtranslatora, którego polecałem wyżej. Można go połączyć ze swoim kontem na Damned Lies (po wpisaniu w danych profilu naszego tokenu z DL), co teoretycznie pozwoli na pobieranie i wgrywanie plików (chociaż ja wolę załatwiać to przez strony modułów, bo mogę od razu np. wyklikać rezerwację). Bardziej ciekawą możliwością jest pamięć tłumaczeń, którą można sobie zbudować na podstawie innych tłumaczeń zespołu.

Dzięki skryptowi udostępnionemu przez brazylijską ekipę przygotowałem zbiorczy plik .po z całości tłumaczeń przygotowanych dla GNOME50 i udostępniam go na swoim koncie na Codebergu. Po ściągnięciu pliku trzeba jego położenie wskazać Gtranslatorowi (Menu główne -> Zbuduj pamięć tłumaczeń). Od tej chwili w panelu po prawej będziecie mieli podpowiedzi tłumaczeń podobnych ciągów.

Po skończeniu tłumaczenia i zapisaniu pliku otwieramy znowu stronę modułu i w formularzu wybieramy opcję „Wyślij nowe tłumaczenie” i wgrywamy plik. Takie tłumaczenie musi zostać przejrzane przez osobę z uprawnieniami do recenzowania i jeżeli będzie poprawne, to zostanie zatwierdzone i wypchnięte do repozytorium.

Może się zdarzyć, że zamiast tego dostaniemy recenzję z informacjami, które ciągi mają błędy i jak je należy poprawić tak, by spełniały standardy zespołu. Aby ograniczyć prawdopodobieństwo poprawek, warto pamiętać m.in. o tym, że po każdym jednoliterowym spójniku (a, i, o, u, w, z) powinna znaleźć się niełamliwa spacja (wstawiana za pomocą Prawy alt + Spacja), dzięki czemu przy dzieleniu tekstu na wiersze, na ich końcu nie będą wisieć pojedyncze litery.

Zespół planuje przygotowanie wytycznych dotyczących tłumaczenia (np. preferowanych form gramatycznych dla różnych elementów interfejsu oraz używania form neutralnych płciowo) i gdy będą gotowe, to je tutaj podczepię, ale na razie warto przyjrzeć się temu, jak wyglądają dotychczasowe tłumaczenia, a w razie wątpliwości zapytać w naszym pokoju Matrix.

– –

Myślę, że to najwyższy czas, żeby zakończyć ten wpis i cały cykl. Mam nadzieję, że pokazując tyle różnych sposobów na zaangażowanie się w FOSS uda mi się namówić do tego chociaż jedną osobę.

Jeżeli macie jakieś pytania dotyczące poruszonych w tych wpisach zagadnień, lub uważacie, że podane przeze mnie informacje wymagają uzupełnienia, a być może są błędne, to proszę dajcie znać w komentarzach. Z chęcią poznam wasze zdanie i uzupełnię swoje braki w wiedzy.

Spis treści

• Testowanie wersji rozwojowych aplikacji
  • Wydania nightly
  • Przy użyciu GNOME Buildera
  • Z ręcznym budowaniem pakietów flatpak
  • Kod spoza głównej gałęzi repozytorium
  • Jak testować?
• Pomaganie innym osobom używającym WiOO i advocacy
• Wsparcie finansowe osób rozwijających FOSS

– –

Testowanie wersji rozwojowych aplikacji

O wyłapywaniu błędów w czasie używania programów i ich zgłaszaniu pisałem w pierwszej części, tym razem opowiem o używaniu niewydanych jeszcze wersji, samodzielnym budowaniu i instalowaniu oprogramowania prosto z repozytorium, po to, by przetestować nowe funkcje i wychwycić błędy jeszcze zanim program zostanie udostępniony zwykłym użytkownikom.

To zagadnienie bardziej zaawansowane, wymagające umiejętności korzystania z trybu tekstowego i instalowania potrzebnych programów i bibliotek. Jeżeli jeszcze nie masz tych umiejętności w swoim repertuarze, to może być właśnie dobra okazja na uzupełnienie braków.

O ile stosunkowo często zdarza mi się zgłaszanie błędów w różnych programach, to za testowanie wersji rozwojowych biorę się tylko w przypadku programów, które naprawdę lubię i rozwijają się na tyle szybko między wydaniami, żeby było warto sprawdzać, co ciekawego się w nich dzieje.

Robiłem tak np. z Tubą (klientem fediwersum), Scratchmarkiem (edytorem Markdown, w którym piszę wszystkie teksty na bloga), a ostatnio z Tonearm, natywnym klientem Tidala.

Wymaga to trochę więcej pracy niż zwykłe używanie i ewentualne zgłaszanie zauważonych błędów, ale jest też bardzo satysfakcjonujące, zwłaszcza jeżeli jest się osobą, którą cieszy zdobywanie nowych umiejętności i lubi dłubać w terminalu.

Wiadomości, którymi się poniżej podzielę, pewnie będą banalne dla bardziej zaawansowanych, ale sam nieraz musiałem się naszukać i nadłubać, zanim załapałem co i jak. Przyznaję, że mimo zebranego doświadczenia i tak zdarza się, że w niektórych przypadkach działam trochę po omacku, co zresztą jest dla mnie sporą częścią frajdy, jaką mam z tej całej zabawy.

– –

Korzystanie z wydań niestabilnych

Zanim zabierzecie się za samodzielne budowanie niewydanych jeszcze wersji programów, sprawdźcie czy czasem osoby tworzące aplikację nie udostępniają wydań niestabilnych, często budowanych codziennie. Jeżeli się nie mylę, to Firefox wprowadził nazwę nightly na takie wydania i od tego czasu widuję ją używaną w innych projektach.

Czasem nie są dostępne w jakimś rzucającym się w oczy miejscu na stronie projektu, tylko trzeba się do nich doklikać. W przypadku Tonearm osoby rozwijające program włączyły automatyczne budowanie pakietów, do których można się dostać po wybraniu interesującej nas zmiany w repozytorium w sekcji Actions.

Takie rozwiązanie bardzo ułatwia życie osób chcących testować aplikacje w czasie ich rozwoju. Niestety, zazwyczaj nie jest dostępne i trzeba radzić sobie samodzielnie.

– –

Budowanie przy pomocy GNOME Builder

W wielu przypadkach, zwłaszcza gdy mowa o aplikacjach tworzonych dla ekosystemu GNOME, najłatwiej będzie do ich budowania i instalacji wykorzystać program GNOME Builder. To zintegrowane środowisko programistyczne (IDE) najprościej zainstalować z Flathuba.

Po odpaleniu Buildera otwiera się okno powitalne, w którym można stworzyć nowy projekt albo otworzyć znajdujący się już na dysku, ale nas interesuje pobranie źródeł programu z jego repozytorium, które umożliwia znajdujący się na dole okna przycisk „Sklonuj repozytorium…”.

Dostępny w tej chwili Builder jest spolszczony w 36%, ale dopiero co skończyłem jego pełne tłumaczenie, które w tej chwili musi zostać przejrzane przez koordynatorkę zespołu przekładającego GNOME na język polski i po poprawkach będzie mogło zostać włączone do następnego wydania.

W następnym oknie wklejacie adres repozytorium i wybieracie, do jakiego folderu mają trafić źródła. Możecie tam też podać swoje dane, na wypadek, gdybyście chcieli zmieniać kod i wysyłać poprawki.

Adres URL repozytorium ma formę https://serwis/autor/projekt.git. Na GitHubie schowany jest pod zielonym przyciskiem „Code”, a na GitLabie pod niebieskim. Po jego kliknięciu zobaczycie adres HTTPS, a obok ikonkę kopiowania go do schowka. Na Codebergu nie trzeba nic rozwijać, można od razu klikać przycisk kopiowania znajdujący się obok pola z adresem.

Po zatwierdzeniu klonowania Builder pobierze źródła z głównej gałęzi programu i otworzy projekt. Dla osób niezaznajomionych z edytorami dla programistów interfejs Buildera może wydawać się nieprzyjazny i skomplikowany. Najważniejsze dla nas rzeczy kryją się na górze w centrum ekranu. Znajdziecie tam ikonkę młotka, która uruchamia budowanie projektu. Na prawo od niej jest strzałka w dół rozwijająca listę działań. Warto rozpocząć od kliknięcia „Update Dependencies…”, co zainstaluje pakiety potrzebne do zbudowania programu.

Gdy ten proces zakończy się sukcesem, można kliknąć młotek lub wybrać „Zbuduj” z menu. W dolnej części ekranu zaczną wyświetlać się proces budowania, który powinien przelecieć bez problemów, o ile w systemie macie wszystkie potrzebne narzędzia. Czasem wywali się z informacją o nieznalezionym poleceniu czy bibliotece, wtedy będzie trzeba użyć narzędzia zarządzania oprogramowaniem waszej dystrybucji i doinstalować potrzebne rzeczy.

Jeżeli wszystko się powiedzie, to na pasku na lewo od młotka wyświetli się napis „Pomyślnie zbudowano”. W tym momencie możecie kliknąć ikonkę trójkąta po prawej, by uruchomić program, co zazwyczaj wystarcza do testowania. Można też stworzyć pakiet flatpak, wybierając „Export” z menu.

– –

Ręczne budowanie

Niektóre programy nie dawały mi się zbudować w powyższy sposób, całkiem możliwe, że przez mój brak umiejętności i wiedzy do tego potrzebnej. W takich wypadkach załatwiam to ręcznie.

Jeżeli nie macie kopii repozytorium utworzonej w Builderze, można to zrobić bez niego. Otwieramy terminal w katalogu, w którym ma znaleźć się kod źródłowy i używamy polecenia git clone. Na przykład w przypadku Tonearm to

git clone https://codeberg.org/dergs/Tonearm.git

Następny krok to sprawdzenie na stronie projektu, czy są tam zamieszczone instrukcje budowania/instalacji. Niekiedy znajdziecie tam dokładne polecenie i wystarczy je skopiować do terminala, by zbudować program, oczywiście, jeżeli macie zainstalowane wszystkie zależności.

Niektóre programy mają skrypty zajmujące się budowaniem i instalowaniem. Na przykład w katalogu build-aux źródeł Scratchmark znajduje się skrypt generate_flatpak.sh, którego wywołanie buduje pakiet Scratchmark.flatpak, który można potem zainstalować poleceniem

flatpak install Scratchmark.flatpak --user

Opcja --user powoduje zainstalowanie pakietu wyłącznie dla aktywnego użytkownika. Dzięki temu jeżeli dzielimy komputer z innymi osobami, nie będą widziały w swoim menu potencjalnie niestabilnej wersji aplikacji.

Czasem jednak instrukcji nie ma i trzeba sobie radzić bez nich. Tak było właśnie w przypadku Tonearm, gdy zaczynałem kręcić się przy tej aplikacji. Na szczęście po wcześniejszych doświadczeniach wiedziałem, co zrobić. Rozejrzałem się za zawierającym manifest budowania plikiem .json lub .yaml, który znalazłem w build/flatpak, a potem wydałem polecenie

flatpak-builder --force-clean --install-deps-from=flathub --user --install build dev.dergs.Tonearm.yaml

Dodanie --install-deps-from=flathub spowoduje, że brakujące zależności zostaną dociągnięte z repozytorium flathuba, a --force-clean usunie pliki wygenerowane w czasie poprzedniego budowania.

Jeżeli proces budowania i instalowania przebiegnie bez błędów, można się zabrać za testowanie.

– –

Kod spoza głównej gałęzi repozytorium

Zazwyczaj opisane powyżej sposoby instalacji programów ze źródeł pobranych z repozytorium wystarczają do testowania wersji rozwojowej. Czasem jednak rozwój nowych funkcjonalności odbywa się poza główną gałęzią repo (najczęściej nazywającą się main lub master) i kod ją zawierający trafia do niej dopiero po doszlifowaniu.

Niektóre projekty mają stałą gałąź w rodzaju dev lub devel, w większości przypadków gałęzie powstają na potrzeby konkretnych zmian i mają zazwyczaj dość oczywiste nazwy, np. feat/nowy-edytor albo fix/wycieki-pamieci. Żeby przetestować taką wersję programu, trzeba przełączyć źródła na wybraną gałąź.

W Builderze po lewej stronie pola, w którym były wyświetlane komunikaty budowania aplikacji, znajduje się kolumna ikonek. Druga od góry przełącza na terminal, w którym wpisujemy polecenie git switch. Po naciśnięciu klawisza TAB pokaże się lista dostępnych gałęzi, na której odszukujemy tą, która nas interesuje i dopisujemy do polecenia

git switch feat/nowy-edytor

Przy ręcznym budowaniu po prostu używamy tego samego polecenia w terminalu, po wejściu do katalogu ze źródłami.

Po przełączeniu na wybraną gałąź dalsze budowanie jest takie samo, jak opisałem powyżej.

Jeżeli od sklonowania repozytorium do chwili budowania programu minęło trochę czasu, można je zaktualizować, pobierając zmienione pliki poleceniem git pull wydanym w główny katalogu repo, a ponowne przestawienie repozytorium z bocznej gałęzi na główną załatwiamy oczywiście poleceniem git switch main.

– –

Jak testować?

Niezależnie od tego, w jaki sposób zainstalowaliście testową wersje programu, testowanie wygląda tak samo. Najprostsza opcją jest po prostu używanie programu jak zazwyczaj, z jednoczesnym zwracaniem uwagi na zamykanie się aplikacji, skoki zajęcia pamięci, zamulenie, niedziałające elementy. Po natrafieniu na takie problemy zgłaszamy je w sekcji Issues strony programu, co opisałem już w poprzedniej części. Pamiętajcie o wcześniejszym upewnieniu się, że problem jeszcze nie został zgłoszony.

Bardziej zaawansowaną opcją jest sprawdzenie, co się zmieniło od ostatniego wydania i testowanie rzeczy z tej listy. Żeby to zrobić trzeba wejść na zakładkę Wydania (Relases) na stronie projektu i wybrać najnowsze, a po jego otwarciu poszukać odnośnika w rodzaju „15 commits to master since this release”, który otworzy stronę zawierające listę wszystkich zmian, które zaszły w repozytorium od tego czasu.

Lista, którą zobaczycie, może w pierwszej chwili może wydawać się nieczytelna i przytłaczająca, zwłaszcza jeżeli w repozytorium sporo się wydarzyło od czasu ostatniego wydania. Na szczęście da się to dość łatwo ogarnąć, o ile osoby rozwijające program dbają o sensowne opisywanie zmian.

Zazwyczaj można zignorować aktualizacje tłumaczeń oraz zmiany oznaczane jako chore, które z reguły dotyczą np. aktualizacji zależności i podobnych zabiegów związanych z utrzymaniem kodu. Te, które nas interesują, często są mają oznaczenia fix dla zmian łatających błędy oraz feat dla dodających nowe funkcjonalności lub zmieniających działanie dotychczasowych.

Testowanie pierwszych jest bardziej oczywiste, zwłaszcza jeżeli dotyczy błędów, które zgłaszaliśmy. Odtwarzamy okoliczności, w których błąd występował i sprawdzamy, czy nadal tak się dzieje. Jeżeli jest już naprawiony, warto w komentarzu pod konkretną zmianą napisać, że poprawka zadziałała. Jeżeli błąd pojawia się nadal, tym bardziej warto dać o tym znać.

Te drugie pewnie są najbardziej atrakcyjne – ja sam mam wielką frajdę, gdy mogę używać rzeczy, które są jeszcze niedostępne dla osób korzystających tylko ze stabilnych wydań i często robię to jako pierwsza osoba po bezpośrednio zaangażowanych w rozwój programu. Poza sprawdzeniem, czy dodany/zmieniony element aplikacji działa tak, jak powinna, warto spojrzeć na to, jak łączy się z jej resztą i czy np. nie psuje używalności, albo jeżeli się sprawdza, czy nie pasowałby też w innych miejscach.

Przykład 1: Niedawno do Scratchmark doszła możliwość zmiany rozmiaru tekstu w edytorze za pomocą skrótów Ctrl+ i Ctrl-. Osoba rozwijająca Scratchmarka uznała, że skoro można ustawić rozmiar czcionki w ten sposób, to może usunąć ustawianie rozmiaru w preferencjach. Zgłosiłem w pokoju Matrix aplikacji, że IMHO to nie jest najlepszy pomysł, bo skoro możemy tam zmienić krój czcionki, to dziwne będzie, jeżeli nie będziemy mogli zmienić tam również jej rozmiaru. Za to jak najbardziej powinna się tam znaleźć informacja, że wielkość tekstu można zmienić też w czasie pisania za pomocą skrótów klawiszowych.

Przykład 2: Zaproponowałem dodanie do Tonearm podglądu okładek albumów, co dość szybko zostało zrealizowane. Gdy przetestowałem wersję z tą zmianą odkryłem, że działa to wyłącznie po kliknięciu z okładkę obecnie odtwarzanego utworu, która i tak jest dość powiększona w panelu odtwarzacza, za to nie działa z okładkami na stronach albumów, jeżeli ich nie odtwarzamy, a tam przydałoby się bardziej, bo okładki są dużo mniejsze, więc słabiej widoczne. W tym przypadku również zasugerowałem zmianę na Matriksie.

Matrix jest sposobem komunikacji popularnym w świecie FOSS. To taki Discord dla geeków – otwarty i niezależny od korporacji. Mniej wybajerzony, ale IMHO bardziej wygodny. Gorąco zachęcam do korzystania z niego, bo jest dobrym sposobem na bezpośrednią komunikację z osobami rozwijającymi WiOO, mniej formalną niż wypełnianie issues na stronach projektów. Jeżeli zdecydujecie się spróbować, to polecam polski serwer noevil, na którym mam swoje konto oraz klienta o nazwie Fractal.

– –

Pomaganie innym osobom używającym WiOO i advocacy

Jeżeli propozycje, które przedstawiłem w poprzedniej części i powyżej to dla was za dużo zachodu, to teraz pokażę działalność, która w przeciwieństwie do powyższych nie wymaga dłubania, a jedynie chwili wolnego czasu.

Sporą częścią całego środowiska WiOO jest wzajemne pomaganie. Kiedyś było to dużo łatwiejsze, po prostu siedzieliśmy na usenetowej grupie (alt.pc.comp.os.linux.newbie na zawsze w moim sercu, jeżeli ktoś z a.p.c.o.l.n. to czyta, to pozdrawiam serdecznie) i w miarę możliwości odpowiadaliśmy na pytania, które się na niej pojawiały. Polecaliśmy programy, kompatybilny sprzęt, podpowiadaliśmy sposoby rozwiązywania problemów, dzieliliśmy się sztuczkami, skryptami, pisaliśmy FAQ itd.

Usenet niestety odszedł w niepamięć, ustępując pola forom dyskusyjnym, które z kolei prawie wyginęły po nastaniu czasu mediów społecznościowych i discordów, przetrwały chyba głównie w formie poświęconej konkretnym dystrybucjom, np. Arch, Debian, Fedora, Mint, openSUSE, Ubuntu. To bardzo dobre miejsca, aby pomóc osobom zaczynającym przygodę z Linuksem i szukających rozwiązania jakiegoś problemu. Jeżeli tylko macie wiedzę, którą możecie się podzielić, to z pewnością znajdziecie tam osoby, którym się ona przyda.

Jeżeli nie macie ochoty zaglądać na fora, to zostają jeszcze media społecznościowe. Co prawda na takim Facebooku czy Twitterze raczej nie będzie okazji do zaangażowania się w taką działalność (no chyba, że są jakieś grupy okołoFOSSowe na fb), ale w fediwersum to dość popularny temat, więc na pewno trafi się okazja polecić jakiś program, podpowiedzieć rozwiązanie problemu, a może nawet zagadać bezpośrednio do osób rozwijających WiOO. Fedi zresztą jest świetne jako sposób do trzymania palca na pulsie świata FOSS, sam śledzę w ten sposób np. dystrybucje Linuksa, klienty Mastodona i innych platform oraz garść innych programów WiOO.

Poza pomaganiem przy rozwiązywaniu problemów, można w takich miejscach zająć się głoszeniem dobrej nowiny o FOSS, czyli tak zwanym advocacy. Można np. pokazywać zalety używania Linuksa zamiast zamkniętych systemów operacyjnych czy polecać ciekawe aplikacje WiOO, na które natrafiliście. Warto to robić nienachalnie i bez pogardy dla innych systemów. Na a.p.c.o.l.n. mieliśmy zasadę, że skoro nie chcemy, żeby ktoś pisał o „Linuchu”, to my nie mówimy o „Winshicie” itd. (obecnie zrobiłbym wyjątek od tej zasady dla „Microslopu”, jego użycie jest jak najbardziej uzasadnione, podobnie jak deadname’owanie Twittera).

Pamiętajcie przy tym, że odwieczna tradycja flejmów (flame wars) o wyższość jednej dystrybucji nad drugą, jak bardzo rozrywkowa by nie była, raczej nie przysłuży się celowi. Lepiej zamiast tego pokazać np. jak można wykorzystać Linuksa do grania (dzięki Steamowi i Protonowi) czy przedłużenia życia starszego sprzętu, niewspieranego już przez Windows.

Masa aplikacji FOSS jest pisana także na inne systemy, więc można polecać je bez namawiania do przesiadki na Linuksa.

– –

Wsparcie finansowe osób tworzących WiOO

Sporym problemem wśród osób rozwijających WiOO jest zmęczenie, a nawet wypalenie. Więcej o tym możecie przeczytać np. w artykule w serwisie „It’s FOSS”, opartym na badaniu Mirandy Heath z The University of Edinburgh, tu pozwolę sobie nawiązać tylko do jednego fragmentu.

Raport zawiera sześć czynników, które powodują stan wypalenia u osób rozwijających FOSS i ich odchodzenie od rozwijanych projektów. W skrócie to stres związany z przytłaczającym obciążeniem, poczuciem odpowiedzialności i potrzebą udowadniania własnej wartości. Osoby utrzymujące popularne oprogramowanie są zasypywane zgłoszeniami, a że często pracują solo, nie są w stanie sobie z tym poradzić. Jednocześnie czują zobowiązanie do dalszej pracy, bo porzucenie projektu byłoby jak zdrada.

Do tego dochodzi często toksyczne zachowanie społeczności: bezrefleksyjne wymaganie nowych funkcjonalności, bez zastanowienia się, czy osoba tworząca projekt ma czas i możliwości na ich realizację oraz bezwzględne krytykowanie wszelkich wpadek, podczas gdy dobra praca jest niedoceniania.

Kolejną kwestią jest fakt, że utrzymywanie istniejącego projektu jest mniej wynagradzające od tworzenia: programowanie nowej aplikacji czy biblioteki jest źródłem frajdy, ale utrzymywanie ich, naprawa błędów, aktualizacja zależności itp. to po prostu uciążliwa, powtarzalna praca.

Ostatnim czynnikiem są kwestie finansowe. Według raportu 60% osób utrzymujących przy życiu WiOO nie otrzymuje za to żadnego wynagrodzenia. Muszą najpierw wykonywać swoją pracę zarobkową, a po niej często odrabiają kolejny etat pracując przy jakimś projekcie FOSS, poświęcając swój czas przeznaczony na życie prywatne, rodzinę i przyjaciół.

Wszyscy lubimy fajne programy WiOO, chcemy by były dobrze zaprojektowane i działające, regularnie aktualizowane i naprawiane. Ale tak przywykliśmy do tego, że są dostępne za darmo, że rzadko myślimy, że ktoś płaci za ich rozwój swoim czasem. Nie jestem w stanie załatwić tym osobom etatów polegających na pracy nad FOSS, dlatego staram się co jakiś czas, w miarę możliwości, wesprzeć jakiś projekt, np. z okazji kolejnego wydania. To samo z osobami lub organizacjami utrzymującymi ważną infrastrukturę np. serwer Matriksa. Moje parę złotych dużo nie zmienia, ale jeżeli takich wpłat zbierze się więcej, mogą naprawdę pomóc. Jeżeli tylko możecie, to gorąco zachęcam, nawet jeżeli będzie to tylko równoważność jednej kawy czy innego napoju.

Jeżeli się na to zdecydujecie, to najlepszym sposobem będzie poszukanie na stronie ulubionego oprogramowania odnośników do serwisów w rodzaju Ko-Fi czy Liberapay, często wykorzystywanych jako metody na przekazywanie finansowego wsparcia.

– –

To koniec drugiej części, trzecia powinna pojawić się wkrótce. Tymczasem zapraszam do rozmowy – jeżeli macie jakieś pytania dotyczące poruszonych zagadnień lub uważacie, że podane przeze mnie informacje wymagają uzupełnienia, a może nawet są błędne, to proszę dajcie znać w komentarzach. Z chęcią poznam wasze zdanie.

• Czym jest WiOO?
• Po co?
• Moje początki
• O wpisie
• Programowanie
• Dokumentacja
• Grafika
• Zgłaszanie błędów
• Pomysły na nowe funkcjonalności

Czym jest WiOO?

Skrót WiOO oznacza Wolne i Otwarte Oprogramowanie i jest polskim odpowiednikiem angielskiego FOSS (Free and Open-Source Software).

Wolne oprogramowanie to takie, „które może być uruchamiane, kopiowane, rozpowszechniane, analizowane oraz zmieniane i poprawiane przez użytkowników, oraz dające użytkownikom wolność do dzielenia się tym oprogramowaniem bez ograniczeń prawa autorskiego” (za Wikipedią).

Żeby spełniać warunki do uznania za wolne, oprogramowanie musi zapewniać użytkownikowi cztery wolności:

• Wolność do uruchamiania programu jak chcecie, w dowolnym celu (wolność 0).
• Wolność do analizowania, jak działa program i zmieniania go, aby robił co i jak potrzebujecie (wolność 1). Warunkiem koniecznym jest dostęp do kodu źródłowego.
• Wolność do rozpowszechniania kopii, byście mogli pomóc innym (wolność 2).
• Wolność do udoskonalania programu i publicznego rozpowszechniania własnych ulepszeń, dzięki czemu może z nich skorzystać cała społeczność (wolność 3). Warunkiem koniecznym jest tu dostęp do kodu źródłowego.

(Lista pochodzi ze strony gnu.org).

Otwarte oprogramowanie to z kolei takie, „w którym kod źródłowy jest wydawany na podstawie licencji, na mocy której właściciel praw autorskich przyznaje użytkownikom prawa do badania, zmiany i rozpowszechniania oprogramowania w ramach licencji wolnego oprogramowania” (cytat z Wikipedii).

Pierwszy termin dotyczy bardziej ideowego podejścia, a drugi bardziej technicznego. Praktycznie każdy program spełniający wymogi bycia wolnym oprogramowaniem będzie też otwarty, ale nie zawsze działa to w drugą stronę.

Przykłady znanego oprogramowania, które jest w ten sposób rozwijane:

• Edytor grafiki Gimp,
• Pakiet biurowy LibreOffice,
• Program do grafiki i animacji 3D Blender,
• Odtwarzacz wideo VLC,
• Edytor plików audio Audacity.

Przyznaję, że sam używam tych terminów zamiennie, bez przywiązywania uwagi do różnic, lub sięgam po skrót FOSS. W oczach osób z Free Software Foundation i okolic to pewnie myślozbrodnia, ale się tym nie przejmuję.

Niezależnie od terminu, będę w tym wpisie opowiadał o ruchu, czy może raczej środowisku osób wspólnie tworzących oprogramowanie, którego każdy może używać i modyfikować. Głównym celem, który mi przyświeca jest zachęcenie jak największej liczby osób do włączenia się, dlatego spróbuję pokazać, jak można to zrobić, niezależnie od posiadanych umiejętności.

– –

Po co?

Z wielu powodów. Dla kogoś może to być okazja na zyskanie nowych umiejętności i doświadczeń, czy to dla siebie, czy jako czegoś, co można wpisać do CV. Nie chodzi tu tylko o same techniczne umiejętności, jak obsługa repozytorium z oprogramowaniem, ale też np. pracę w zespole.

Dla innych to szansa na poznanie nowych osób, o podobnych zainteresowaniach, zwłaszcza jeżeli trudno im znaleźć kogoś takiego w swoim otoczeniu.

Czasem zaletą może być zwykła chęć tworzenia wspólnego dobra albo satysfakcja którą czujesz, gdy widzisz, że ludzie używają aplikacji, do której powstania się przyczyniasz.

Motywacją może być ochota pokazania, że w zgównowaconym świecie zalewanym AI-slopem przez korporacje Big Tech, nadal jest miejsce na ludzi tworzących razem coś fajnego.

Jeżeli napędza cię coś jeszcze innego, daj znać w komentarzu.

– –

Moje początki

Sam zostałem fanem tej idei około 25 lat temu, gdy w czasie pierwszych podejść do Linuksa (wtedy był to Slackware albo Red Hat), postanowiłem zainstalować port Quake’a, o którym przeczytałem w jakimś magazynie (pewnie „Chip Special Linux” lub „Linux+”). Gra była chyba na płycie dołączonej do magazynu, bo nie sądzę, żebym ją ściągał na dial-upie, zamieszczona w postaci kodu źródłowego i żeby pograć, musiałem ją skompilować.

Zupełnie nie miałem pojęcia, co robię i po prostu przepisywałem polecenia literka po literce (klasyczne ./configure, make, make install), ale nie rozumiałem, co się wyświetla w ich wyniku. A że zwracały jakieś błędy, to gra się nie budowała.

W pliku README znalazłem adres e-mail autora i bez większego przekonania, że to coś da, postanowiłem wysłać do niego pytanie. Ku mojemu zdziwieniu nie tylko odpisał, ale i krok po kroku przeprowadził mnie przez cały proces instalowania zależności, kompilacji i instalacji.

Już nie pamiętam, jak się grało w tamten port Quake’a, ale na zawsze zostało ze mną wrażenie, jakie zrobił na mnie fakt, że komuś nie tylko chciało się stworzyć jakieś oprogramowanie i udostępnić je za darmo, ale też potem całkowitemu newbie z drugiego końca świata cierpliwie wyjaśniać, jak go używać.

Od tamtego momentu chciałem zostać częścią tego świata i myślę, że jakoś mi się to udaje, a tym przydługim tekstem chcę zaprosić was do dołączenia.

– –

O wpisie

Wpis składa się z rozdziałów poświęconych różnym sposobom angażowania się w WiOO. Jeżeli po przeczytaniu tytułu lub kilku pierwszych zdań któregoś z nich dojdziesz do wniosku, że nie ten aspekt cię nie interesuje, zapraszam do przeskoczenia do następnego rozdziału, może w nim uda mi się podsunąć coś, co bardziej ci się spodoba.

Gdy w czasie pisania przekroczyłem granicę 3 tysięcy słów, a końca nie było widać, postanowiłem podzielić wpis na części, żeby łatwiej się go czytało.

Pierwsza z nich zawiera informacje o wejściu w WiOO jako osoba programująca, tworząca dokumentację lub grafikę, zgłaszająca błędy i podsuwająca pomysły na nowe funkcjonalności. Drugą poświęciłem testowaniu aplikacji w czasie ich powstawaniu, pomaganiu innym osobom używającym otwartego oprogramowania oraz wspieraniu osób rozwijających FOSS, a trzecia opowiada o tłumaczeniu aplikacji.

Cytaty, które zobaczycie poniżej dostałem na Fediwersum po zapytaniu o porady dla osób wchodzących w świat FOSS. Bardzo dziękuję i pozdrawiam wszystkie osoby, które odpowiedziały na tamto pytanie.

I jeszcze uwaga techniczna: o ile ogólna tematyka jak najbardziej może dotyczyć różnych systemów operacyjnych, to ze względu na to, że od lat używam wyłącznie Linuksa (w tej chwili openSUSE Tumbleweed), konkretne przykłady programów i poleceń będą pochodziły z tego środowiska. Przy budowaniu i instalowaniu pakietów z programami używam flatpaka, jako że jest niezależny od dystrybucji i praca z nim wszędzie wygląda tak samo.

Dosyć już tych wstępów, pora na właściwą część tekstu.

– –

Programowanie

Najłatwiej oczywiście mają osoby potrafiące programować, bo mogą po prostu swoją aplikację udostępnić na którejś z otwartych licencji. Najpopularniejsze z nich to GNU General Public Licence (GPL), MIT oraz BSD. Więcej o nich możecie poczytać np. na stronie Open Source Initiative. Różnice między nimi w prosty sposób pokazuje strona Open Licence Helper, na której znajduje się też wizard, w którym można wyklikać najbardziej pasującą licencję, po odpowiedzeniu na kilka pytań.

Jeżeli nie macie pomysłu na własny program lub szukacie czegoś prostszego, niż tworzenie całej aplikacji, to może zainteresować was pisanie poprawek lub dodawanie funkcjonalności do istniejących już aplikacji. Najlepiej w takim przypadku wybrać program, którego używacie regularnie i dobrze go znacie. I zacząć od czegoś niewielkiego, a nie porywać się na rzeczy zmieniające pół aplikacji.

– –

Osobom mającym doświadczenie z programowaniem, raczej nie muszę tłumaczyć jak działają serwisy z repozytoriami kodu w rodzaju Codeberga czy GitHuba.

Jeżeli jednak tak nie jest, to warto się zapoznać z tematem, bo znajomość obsługi repozytoriów git jest absolutnie kluczowa i bez niej będzie ci trudno. Nie wyobrażam sobie zabierania się za współpracę w jakimś projekcie bez umiejętności stworzenia forka, pracy na swoim repozytorium, zapisywania zmian w nim i tworzenia pull request, w celu scalenia twojego kodu z oryginalną aplikacją. Sama umiejętność kodowania nie wystarczy, jeżeli nie potrafisz obsłużyć repo.

– –

Niezależnie od tego, czy masz doświadczenie w komercyjnym tworzeniu oprogramowania w zespołach, czy nie, musisz pamiętać o bardzo ważnej rzeczy – osoby tworzące FOSS robią to zazwyczaj w swoim wolnym czasie, godząc to z pracą i życiem osobistym. Jeżeli będziesz natarczywie domagać się natychmiastowej reakcji np. na swoją łatkę, to może się to po prostu skończyć jej odrzuceniem, a może nawet zablokowaniem cię.

To samo dotyczy osób wchodzących w istniejące projekty „z buta”, domagając się np. zmiany konwencji zapisu kodu, filozofii działania programu, korzystania z innej biblioteki albo przepisania na inny język (a widziałem kilka takich zagrywek ze strony fanów Rust), czy po prostu zachowujących się jak buc.

Zanim zabierzesz się za pisanie kodu, sprawdź najpierw, czy w repo aplikacji nie ma informacji dla osób chcących przy niej współpracować, na przykład w pliku CONTRIBUTING.md. Warto też rozejrzeć się za czymś w rodzaju „Code of Conduct”, który często znajduje się w repozytoriach projektów związanych z GNOME. To dokument zawierający standardy i wytyczne dla społeczności, łącznie z przykładami niewłaściwych zachowań, które nie są tolerowane w GNOME.

Szanujmy się wszyscy, bez tego nie ma mowy o owocnej współpracy. W FOSS wchodzi się, by współtworzyć, nie narzucać swoją jedynie słuszną wizję.

Jeszcze jedno: nawet jeżeli zachowamy się odpowiednio, nie ma gwarancji, że osoby zarządzające danym projektem przyjmą nasze zmiany. Przeszkodą może być coś niedużego i zostaniemy poproszeni o jakieś poprawki, a po ich wprowadzeniu łatka zostanie przyjęta. Może się jednak zdarzyć, że nie pasuje do konkretnej wizji projektu, planu jego rozwijania, sposobu działania programu itp.

Paweł Gronowski radzi:

Czasem może się zdarzyć, że Twój PR działa, ale nie możemy go przyjąć z różnych względów – np. jest to brzydki hack albo nie pasuje do długoterminowej wizji projektu.
Zanim spędzisz czas, pracując nad implementacją bardzo dużej funkcjonalności, warto najpierw przedyskutować czy jest to dobre rozwiązanie i czy zostanie ono przyjęte.

Jeżeli bardzo będzie zależało wam na konkretnych zmianach, można taki program sforkować, czyli zrobić swoją wersję, bazując kodzie oryginału, a potem regularnie brać zaktualizowany kod macierzystego programu i nakładać łatki dopasowujące go do własnej wizji.

– –

Dokumentacja

Wśród rad dla początkujących, jakie dostałem na fedi od osób już działających w takich projektach powtarzała się jedna, o której sam nie pomyślałem. Poza pisaniem kodu, bardzo ważne jest tworzenie dokumentacji:

Paweł Gronowski:

Kontrybucja dokumentacji jest często cenniejsza od kodu, a przede wszystkim łatwiejsza do oceny dla opiekuna niż kodu.

Marcin Juszkiewicz:

Wybrać coś, czego używają. […] Gdzie wiedzą czego brakuje w dokumentacji i chcą to dodać. Pisanie kodu to nie jest umiejętność, którą trzeba posiadać, by pomóc w projektach FOSS.

dopelover:

No i jest jeszcze kwestia tworzenia, nazwijmy to nieprogramistycznych zasobów, oczywiście zależnych od rodzaju projektu np. szablony dokumentów, dokumentacja dla użytkowników, tutoriale, wiki itp. itd.

Sam się tym nigdy nie zajmowałem, ale rzeczywiście tworzenie dokumentacji wygląda na całkiem dobry sposób na wejście w jakiś projekt i poznanie sposobu jego działania.

Oczywiście, zanim się za to zabierzecie, warto porozmawiać na ten temat z osobami tworzącymi oprogramowanie i zapoznać się z tym jak wygląda dotychczasowa dokumentacja, żeby zachować spójność.

– –

Grafika

Nie macie ochoty grzebać się w kodzie, ale macie za to artystyczne zacięcie? Świetnie się składa, każda aplikacja potrzebuje ikony, część także ilustracji, a gry całej masy rozmaitej grafiki.

Jeżeli natraficie na nowy projekt, który używa tymczasowej ikony i moglibyście zaproponować coś bardziej dopracowanego – śmiało zgłaszajcie się z propozycją. Może uważacie, że obecną ikonę jakiegoś programu można by poprawić, podnosząc np. jej czytelność? w takim wypadku skontaktujcie się z kimś z osób tworzących aplikację i przedstawcie swoją sugestię.

Warto się przed tym zapoznać z wytycznymi dotyczącymi ikon i kolorów aplikacji z serwisu Flathub, który jest najpopularniejszym źródłem oprogramowania w pakietach flatpak. A jeżeli program, który chcecie wspomóc swoją grafiką, jest przeznaczony głównie dla środowiska GNOME, lekturą obowiązkową będzie odpowiednia sekcja GNOME Human Interface Guidelines, która zawiera porady dotyczące rozmiarów, kształtu, wykorzystania perspektywy i szegółowości ikon.

– –

Zgłaszanie błędów

Tak samo, jak oprogramowanie produkowane przez korporacje, tak i aplikacje tworzone przez społeczność WiOO nie są wolne od błędów. Te pierwsze jednak mogą zatrudnić testerów, drugie polegają na zgłoszeniach od użytkowników.

Jeżeli traficie na błąd, zwłaszcza jeżeli to coś dużego, jak np. wywalanie się aplikacji, dobrze zgłosić go osobom tworzącym projekt. Czasem wydaje się, że problem jest tak dokuczliwy, że na pewno ktoś już go zgłosił i nie ma co się tym przejmować. Warto jednak sprawdzić, czy rzeczywiście jest już zgłoszenie, bo być może wszyscy pomyśleli podobnie i nie zgłosił nikt.

Żeby ustalić, jak to zrobić, najprościej zajrzeć do okna informacji o programie, które w aplikacjach dla ekosystemu GNOME jest zazwyczaj ostatnią pozycją w menu głównym. Poza informacją o osobach rozwiajającyn program, powinna tam się znaleźć opcja „Zgłaszanie błędów”, której kliknięcie otworzy w przeglądarce stronę zgłoszeń (issues) w repozytorium projektu, na którymś z serwisów w rodzaju Codeberga, GitHuba czy Gitlaba.

Niestety, wszystkie z nich wymagają założenia konta przed wysłaniem zgłoszenia, ale warto to zrobić, bo jeżeli się wciągniecie w taką działalność, to przyda się wam niejednokrotnie. Poza raportowaniem konto pozwala też m.in. na otrzymanie informacje o reakcji i ewentualnym rozwiązaniu problemu oraz śledzenie projektów, by np. dowiedzieć się o nowym wydaniu jeszcze zanim paczka z nim pojawi się w repozytorium twojej dystrybucji lub na Flathubie.

Zanim zabierzesz się za raportowanie błędu, sprawdź listę zgłoszeń, czy ktoś już czasem tego nie zrobił. Może nawet jest już pod nim informacja o rozwiązaniu i tym, czy pojawi się ono w nadchodzącym wydaniu.

– –

Samo zgłaszanie jest dość proste i polega na wypełnieniu kilku pól formularza. Sporo projektów ma je dopasowane do własnych potrzeb, tak by raport dawał jak najwięcej pomocnych informacji.

W przypadku androidowego klienta Mastodona o nazwie Pachli wszystko zawarte jest w jednym polu: opis błędu, sposób odtworzenia go, co się powinno dziać zamiast błędu oraz zrzuty lub nagrania demonstrujące wystąpienie błędu i wersja aplikacji, w której występuje.

Z kolei Tuba (też klient fediwersum, tyle że dla Linuksa) ma to rozbite na osobne pola, z dodatkowym miejscem na rodzaj platformy, z której korzystamy z Tubą, system operacyjny i sposób instalacji samego programu.

Ciekawe pole, którego nie widziałem w innych formularzach, ma Tonearm, klient Tidala, którego niedawno polecałem na blogu. Przy zgłaszaniu błędu możemy wybrać, jak duży ma wpływ na używalność programu (Impact on usability).

Jednym z najważniejszych elementów zgłoszenia są Steps to reproduce czy kroki prowadzące do wystąpienia błędu. Czasem jest to dość oczywiste: „kliknij to, to i gotowe”, ale nie zawsze jest to takie proste i problem wydaje się losowy. Warto jednak się przyjrzeć dokładniej i sprawdzić, czy są jakieś powtarzające się okoliczności, np. Tuba wywalała się przy odpowiadaniu na wpis zawierający czyjąś nazwę użytkownika, a Tonearm pada po otworzeniu elementu z wyników wyszukiwania i późniejszym powrocie do nich.

Przydatne są również troubleshooting information, czyli informacje debuggowania. O ile program je udostępnia, to znajdziecie je w oknie „O programie” i zawierają informacje o środowisku, w jakim działa aplikacja. Wystarczy je skopiować i wkleić w odpowiednie pole formularza zgłaszania błędów.

– –

W większości przypadków wypełnienie takiego formularza powinno wystarczyć do udanego zgłoszenia błędu. Czasem jednak może się okazać, że będą potrzebne dodatkowe informacje i osoba tworząca aplikację zapyta np. o to, jakie opcje mamy włączone i poprosi o przetestowanie po ich wyłączeniu. Bywa, że przydają się dodatkowe informacje, które program wyświetla po uruchomieniu w emulatorze terminala, takim jak Konsola albo Terminal GNOME.

W przypadku Tuby zainstalowanej z Flathuba robi się to wpisując polecenie flatpak run dev.geopjr.Tuba.

Ciąg dev.geopjr.Tuba jest identyfikatorem pakietu flatpak, który można znaleźć np. na stronie programu na Flathubie lub wyszukując go w wyniku polecenia flatpak list, które wypisuje wszystkie zainstalowane pakiety (`flatpak list | grep Tuba“ wyświetli wyłącznie linie zawierające słowo Tuba).

Po uruchomieniu programu w ten sposób doprowadzamy do wystąpienia błędu i wysyłamy osobie rozwijającego apkę to, co pojawiło się w terminalu.

Okno emulatora terminala z komunikatami z uruchomionej Tuby.

Bywa, że zwykłe komunikaty z terminala to za mało i przydałoby się uruchomić program w sposób dający więcej informacji, np. tak: G_MESSAGES_DEBUG=Tuba flatpak run dev.geopjr.Tuba

Na początek nie ma co się tym przejmować. Jeżeli osoba rozwijająca program poprosi nas o dodatkowe informacje, a my nie będziemy wiedzieli, jak je uzyskać, to wystarczy zapytać. Nie ma w tym żadnego wstydu, każdy ma prawo czegoś nie wiedzieć, a w interesie twórców oprogramowania jest pomoc w dostarczeniu potrzebnych danych.

Wiem, że to wszystko może wydawać się dużą ilością informacji dla kogoś, kto chce tylko spokojnie używać jakiegoś programu. Ostatecznie jednak zgłaszanie błędów pomaga zarówno osobom tworzącym, jak i używającym programów. I zazwyczaj naprawdę jest proste i rzadko wymaga większego dłubania, o którym (może niepotrzebnie) wspomniałem wyżej.

– –

Pomysły na nowe funkcjonalności

Raportowanie błędów to nie jedyne, do czego można wykorzystać sekcję „Issues” w repozytoriach programów. Inną możliwością jest zgłaszanie zapotrzebowania na nowe funkcje, czyli feature requests, po sprawdzeniu, czy już nie zostały zgłoszone.

Edytor Markdown nie ma możliwości ustawienia używanej czcionki? Klient fediwersum nie wspiera sprawdzania pisowni przy edycji alt tekstu? Odtwarzacz nie pokazuje, która piosenka na liście jest aktualnie grana? Nie ma problemu – jeżeli brakująca funkcjonalność ma sens, pasuje do wizji osoby tworzącej program i jest możliwa do zaimplementowania, to jest spora szansa, że się pojawi w którymś z przyszłych wydań.

Pamiętajcie jednak, że nikt nie jest wam winny dodania do swojego programu rzeczy, które potrzebujecie i nie ma co się awanturować, gdy się to nie stanie. Zamiast tego możecie spróbować lepiej uzasadnić swoją propozycję, albo poszukać innego programu, który ma funkcję, której potrzebujecie.

– –

Na tym kończę część pierwszą, druga powinna pojawić się niedługo. Jest już w większości napisana, została mi korekta i dodanie ilustracji.

Jeżeli macie jakieś pytania dotyczące poruszonych zagadnień lub uważacie, że podane przeze mnie informacje wymagają uzupełnienia, a może nawet są błędne, to proszę dajcie znać w komentarzach. Z chęcią poznam wasze zdanie.

Natrafienie na niego nie mogło przyjść w lepszym momencie, bo High Tide, czyli klient Tidala, którego używałem do tej pory, aktualnie ma problemy i zapętla w kółko jedną piosenkę. Podobno dzieje się tak tylko na PipeWire, u mnie jednak zmiana wyjścia dźwięku w preferencjach nic nie dawała, a nie chciałem grzebać w ustawieniach audio w całym systemie, żeby obejść błąd w jednym programie. Wróciłem więc do używania strony Tidala zapakowanej w przeglądarkę i udającej samodzielną aplikację.

Może jest używalna, ale wygląda nieporywająco i słabo pasuje do reszty moich aplikacji.

– –

I wtedy właśnie znalazłem Tonearm, na samym początku jego drogi, świeżo po pierwszym publicznym wydaniu.

Poużywałem go przez chwilę, spodobało mi się i zacząłem wypełniać issue trackera na stronie projektu na Codebergu zgłoszeniami błędów i prośbami o nowe funkcjonalności.

Gdy okazało się, że osoby tworzące Tonearm (dwa sympatyczne smoki ze Szwajcarii) nie tylko nie zablokowały mnie za ten spam, ale też są otwarte na współpracę i reagują na zgłoszenia, naprawiając i dodając różne rzeczy oraz wyjaśniając, na czym polega problem, postanowiłem się zaangażować bardziej i przygotowałem polskie tłumaczenie, bazując na terminach używanych przez tidal.com.

Tonearm nie miał wtedy jeszcze integracji z żadnymi serwisami ułatwiającymi tworzenie wersji językowych (po mojej sugestii już jest podczepiony do Weblate), więc całość odbywała się przez pracę na forku repozytorium i wysyłaniu pull requestów ze zmianami, co przynajmniej wymusiło na mnie odświeżenie lekko zardzewiałej znajomości obsługi gita.

Dość szybko zostało naprawione kilka najbardziej dokuczliwych błędów: z wyświetlaniem większych kolekcji i dłuższych playlist, czy wywalaniem programu po kilkukrotnym przełączaniu utworów. Smoki pracują naprawdę błyskawicznie, czasem ledwo zdążyłem napisać znajomym nerdom, że znowu coś znalazłem, a już przychodził mejl z info o zamknięciu zgłoszenia.

Najdłużej czekałem na naprawienie błędu powodowanego przez nowsze API Tidala, które dla niektórych albumów zwracało tylko część utworów. Ten wpis miałem prawie gotowy ponad tydzień przed publikacją i odkładałem jego wrzucenie, aż będzie można słuchać całej biblioteki Tidala.

– –

Wystarczy jeden rzut oka na okno Tonearm, żeby było wiadomo, dlaczego program tak bardzo mi się spodobał. GUI wykorzystujące Gtk4 i bibliotekę Adwaita idealnie pasuje do całej reszty mojego gnomowego biurka.

Oczywiście obsługuje również ciemny styl oraz zmianę koloru akcentu.

Te delikatne paski ostrzegawcze na górze okna oznaczają, że używam aplikacji w wersji rozwojowej, a nie ostatecznego wydania, to taki standard wśród aplikacji dla GNOME.

– –

Dobry wygląd to nie wszytko i na szczęście się na nim nie kończy. Tonearm obsługuje przeglądanie i odtwarzanie muzyki ze strony głównej Tidala, jego biblioteki i kolekcji użytkownika (śledzonych artystów oraz polubionych płyt i utworów), a także feedu, czyli „treści dla ciebie”, ukrywającego się tu pod ikonką dzwonka.

W przeciwieństwie do High Tide potrafi skorzystać z Tidalowej funkcji autoplay, czyli odtwarzania powiązanych utworów po zakończeniu albumu/playlisty, co dla mnie jest dość istotną opcją, dzięki której często odkrywam nową muzykę.

Jak widać na zrzucie powyżej, w preferencjach możemy włączyć scrobblowanie do ListenBrainz oraz Last.fm. Dzięki temu mogłem wyłączyć zajmującego się tym do tej pory demona rescrobbled. Przy okazji mogę go szczerze polecić, bo pracuje ze wszystkimi odtwarzaczami obsługującymi MPRIS, dzięki czemu można niezależnie od tego, którego programu używa się do słuchania muzyki, czy to streamowanej, czy z lokalnej biblioteki, wszystko automagicznie ląduje na Last.fm.

Scrobblowanie (od nazwy serwisu Audioscrobbler) to wysyłanie danych o słuchanej muzyce do serwisu, który na tej podstawie tworzy statystyki i rekomendacje. Last.fm używam w tym celu już od 2005 roku.

Tonearm pozwala też na wyświetlenie tekstu utworu (o ile jest dostępny) i zarządzaniem kolejką odtwarzania. Obie funkcjonalności są dostępne przez przyciski na spodzie panelu, w którym znajduje się odtwarzacz.

Przydatną możliwością jest wybór jakości dźwięku serwowanego z Tidala (do wyboru cztery poziomy) oraz sposobu normalizowania dźwięku utworów, czyli ReplayGain: automatycznie, dla całych albumów (AlbumGain) i pojedynczych piosenek (TrackGain).

– –

Poza tym wszystkim, co już pojawiło się w Tonearm, poprosiłem również o dodanie powiększania okładek albumów i zmiany layoutu aplikacji, tak by lepiej dopasowywał się do dostępnego miejsca i dzięki temu był przyjaźniejszy dla urządzeń mobilnych.

Z rzeczy zgłoszonych przez innych czekam jeszcze na tworzenie i edycję playlist oraz filtrowanie i sortowanie artystów, albumów i playlist w kolekcji.

Jak widać z powyższej listy zostały rzeczy mniej istotne dla codziennego korzystania z Tidala, dlatego mogę śmiało polecić tę aplikację, mimo że jest naprawdę świeża.

Najnowsze wydanie 1.3.1 możecie znaleźć na Flathubie. Nie zawiera jeszcze obejścia problemu API Tidala z niektórymi utworami, ale pewnie pojawi się ono niedługo.

Jeżeli chcielibyście spróbować wersji rozwojowych, to źródła programu znajdują się na Codebergu. Tonearm od niedawna bardzo ładnie buduje się w GNOME Builderze, ale jeśli wolicie uniknąć samodzielnego tworzenia flatpaka, na stronie akcji znajdują się testowe pakiety generowane automatycznie po każdej zmianie w głównej gałęzi repozytorium.