wtorek, 24 stycznia 2017

Sprawdzanie pisowni w QupZilla 2.1

Nie. Numer wersji QupZilli w tytule nie jest pomyłką. Tekst dotyczy nadchodzącego wydania QupZilli, która od tej właśnie wersji zostanie wyposażona w narzędzie do sprawdzania pisowni.
Obecnie można opcję tę wypróbować w wersji przeglądarki budowanej z GIT.
Muszą zostać jednak spełnionych kilka warunków. Po pierwsze, przeglądarka musi zostać zbudowana z użyciem Qt5.8, które właśnie trafiło do repozytorium testing. Innymi słowy - chcąc wykorzystać tę funkcjonalność już dzisiaj, musielibyśmy udostępnić systemowi to repozytorium oraz dokonać aktualizacji systemu. Nie namawiam. Za kilka dni prawdopodobnie pojawi się w repozytorium stabilnym.
Po drugie musimy skompilować i zainstalować paczkę qupzilla-git. Jest w AUR, można zatem wykorzystać tam znajdujący się PKGBUILD.
Po trzecie musimy przeglądarce udostępnić słownik, którego też nie ma.
Jeśli to już uczynimy to w przeglądarce możemy uruchomić tę funkcję w ustawieniach.
Niestety obecna funkcja ma pewne ograniczenia. Przede wszystkim nie możemy wykorzystać więcej niż jednego słownika, po drugie do słownika nie dodamy żadnego słowa, po trzecie słownik musi zostać umieszczony w jednej z dwu akceptowanych lokalizacji.

Sam słownik nie jest trudno stworzyć. Możemy zrobić to odręcznie, czego nie polecam, gdyż dostarczamy systemowi pliki z pominięciem pacmana.
Możemy posłużyć się przygotowanym przeze mnie PKGBUILDem (w wersji polskiej; podobny można stworzyć w oparciu o ten PKGBUILD dla innych języków posługując się słownikami myspell).

Kilka uwag na temat paczki, abyście wiedzieli co ona robi. Po pierwsze dokonuje ściągnięcia słownika polskiego w formacie hunspell (dokładnie to myspell). Po drugie wykorzystuje dostarczane wraz z qt5-webengine 5.8 narzędzie qwebengine_convert_dic do konwersji pliku pl_PL.dic na pl_PL.bdic. Po trzecie dokonuje spakowania tak powstałego słownika do pkg.tar.xz. Przy instalacji, paczka umieszczana jest w katalogu /usr/share/qt/qtwebengine_dictionaries (który jest zresztą tworzony). Jeśli zatem w przyszłości powstanie jakaś paczka dostarczająca słownika polskiego w formacie bdic i nie będziecie jej mogli zainstalować, bowiem ta nowa paczka napotka na istniejący już w systemie słownik, to należy odinstalować zaproponowane przeze mnie rozwiązanie.

Oczywiście słownik możemy sobie aktualizować co jakiś czas.

niedziela, 22 stycznia 2017

Sprawdzamy co zainstalowało się przy ostatniej aktualizacji

Taki mądry to nie jestem. Rozwiązanie znalazłem na BBS Archa, a jego autorem jest Trilby.
Często zastanawiamy się, bądź jesteśmy pytani o to co zostało zaktualizowane w systemie. Okazuje się, że rozwiązanie jest banalne. Otóż należy wydać w konsoli następujące polecenie:
tac /var/log/pacman.log | sed -n '/full system upgrade/q;s/.*\[ALPM\] upgraded //p'
Można sobie sprawę ułatwić i zapisać je w pliku basha:
#!/bin/bash
tac /var/log/pacman.log | sed -n '/full system upgrade/q;s/.*\[ALPM\] upgraded //p'
nazwać plik np. lastupdate.sh, nadać mu uprawnienia wykonywalne (przypominam chmod +x nazwa_pliku) i umieścić gdzieś w $PATH (np. w /usr/bin).
Od tej pory dość łatwo możemy uzyskać przegląd ostatniej instalacji. Podkreślam tu słowo ostatniej, albowiem jeśli po aktualizacji (która w istocie coś w systemie zmieniła), wykonamy następną aktualizację, która zakończy się stwierdzeniem, że "nie ma nic do zrobienia", to wydając powyższe polecenie nie uzyskamy żadnych danych. Może zatem warto wykonywać je praktycznie po każdej aktualizacji i zrzucać wynik do jakiegoś pliku tekstowego oznaczonego datą. Jeśli aktualizacja okaże się sukcesem można plik usunąć.

niedziela, 15 stycznia 2017

Greeter LightDM w Qt5

Rozglądam się od pewnego czasu za DM-em, który umożliwiałby tzw. sesję gościa. SDDM, który jest proponowany dla Plasma 5 nie oferuje takiej opcji. Wprawdzie od dawna znajduje się ona na liście prac do zrobienia, jednakże nikt się tym nie zajmuje. W pamięci mam, że lightDM ją umożliwiał. Niestety to, co lightDM ma "oficjalnie" do zaproponowania dla środowisk opartych o Qt5 nie bardzo mi pasuje. LightDM jest niejako dwuskładnikowy: sam lightdm oraz tzw. greeter. Greetera nie trzeba mieć, jednakże wówczas lightDM daje wyłącznie możliwość tzw. autologowania. Z dostępnych greeterów niestety są takie, które albo oparte są o Gtk, albo o biblioteki KDE4. Zarówno jednymi, jak i drugimi nie chce mi się obciążać zasobów komputera, skoro nie używam takich aplikacji (z niewielkimi jedynie odstępstwami dla tych, które wymagają Gtk). Przydałby się zatem greeter, który byłby zbudowany na Qt5.
Teoretycznie, "oficjalnie", takiego nie ma.
Niezbadane są jednakże zasoby githuba. Nie tak dawno pojawił się tam właśnie taki greeter. Zainstalowałem i testuję. Jak na razie z powodzeniem. Jeśli i Wam przyjdzie taki pomysł do głowy, zapraszam do testów na podstawie dołączonego PKGBUILDu.
Oczywiście proszę pamiętać, że to jest rozwiązanie testowe.
O samej instalacji i konfiguracji lightDM nie będę się rozwodził, albowiem jest ona doskonale opisana na wiki Archa, włącznie z automatyzacją uruchamiania KWallet na starcie, tak by nie pytał się ponownie o hasła, które są takie same jak przy logowaniu.
Ustawień samego greetera dokonamy w pliku /etc/lightdm/qt-lightdm-greeter.conf. Sam lightDM uruchomimy z tym greeterem edytując plik /etc/lightdm/lightdm.conf, dopusując w sekcji [Seat:*] następującą linię:
greeter-session=qt-lightdm-greeter

piątek, 13 stycznia 2017

Czcionki Infinality

Niektórzy z Was już prawdopodobnie zdążyli poznać na własnej skórze niekompatybilność czcionek Infidelity z aktualnym systemem czcionek linuksa. W efekcie muszę stwierdzić, że rekomendowany niegdyś przeze mnie sposób polepszenia wyglądu czcionek linuksowych przez instalację Infinality nie jest już aktualny.
Strona Infinality nie jest już od dłuższego czasu aktywna. Autor ich implementacji w Archu od dłuższego czasu też pozostaje nieobecny, a społeczność proponuje różne alternatywy.
Pozytywnym aspektem jest, że FreeType wraz z wersją 2.7 włączyło część ustawień Infinality do własnego kodu.
Jak być może już też wiecie, nie istnieje możliwość kompilacji Infinality czy to z AUR, czy to bezpośrednio z GIT, nie mówiąc już o instalacji ich z repozytorium.
Jak się też okazuje, problem dotyczy dużo większej ilości aplikacji, czy środowisk niż wydawało mi się na początku.
Dla ustrzeżenia się błędów należy odinstalować wszelkie pozostałości tych czcionek. Nie ma żadnej opcji, by Arch z Infinality działał obecnie poprawnie.
Kompletne usunięcie czcionek Infinality dokonamy poprzez usunięcie wszystkiego, co znajdziemy w systemie z nazwą "infinality". Po wykonaniu czyszczenia systemu, powinniśmy jeszcze usunąć ich pozostałości w ustawieniach czcionek:
sudo fc-presets set
i wybrać kolejno 4, a następnie 5.
Musimy również zainstalować niezbędne paczki czcionek, czyli oryginalne paczki, które zastąpiliśmy paczkami infinality. Lista zamienników wygląda następująco

  • freetype2-infinality-ultimate = freetype2
  • lib32-freetype2-infinality-ultimate = lib32-freetype2
  • fontconfig-infinality-ultimate = fontconfig
  • lib32-fontconfig-infinality-ultimate = lib32-fontconfig
  • cairo-infinality-ultimate = cairo
  • lib32-cairo-infinality-ultimate = lib32-cairo
  • jdk8-openjdk-infinality = jdk8-openjdk
  • jre8-openjdk-infinality = jre8-openjdk
  • jre8-openjdk-infinality = jre8-openjdk-headless

Zasadniczo, zamiast usuwać paczki infinality możemy również wydać polecenie instalacji paczek z prawej listy wyżej w miejsce istniejących paczek z listy po lewej stronie. Pacman winien wykryć konflikt i usunąć infinality przed instalacją czcionek dostarczanych z systemem.

Powinniśmy też usunąć zainstalowane czcionki dostarczane wraz z infinality. Czcionki te obok nazwy mają też sufix ibf po czym je łatwo poznamy. Dokładna lista zamienników czcionek dostarczanych wraz z Infinality została przygotowana przez Bohomila.

Gdyby jednakże czcionki po usunięciu Infinality z systemu okazały się nieprawidłowe, to możemy skorzystać choćby z takiego rozwiązania.

środa, 11 stycznia 2017

Okiełznajmy UFW w Plasma 5

W zamierzchłej przeszłości, bodaj Kubuntu spopularyzowało nakładkę na UFW działającą natywnie w KDE4. Przez długi czas nie było żadnego narzędzia dostępnego dla Plasma 5. Przeszukując zasoby githuba trafiłem i na takie rozwiązanie. Programik ufw-kde jest przeportowanym do bibliotek KF5 forkiem dawnego narzędzia, które było niegdyś dostępne nawet na serwerach KDE.
Jeśli ktoś zatem używa UFW i chciałby mieć wygodną nad nim kontrolę pod Plasma 5, zapraszam do zbudowania sobie programiku z załączonego PKGBUILDu. Program umieści się w "Ustawieniach systemowych".

Budujemy NixNote2 ze źródeł

Znów odwołam się do Przystajnika. Niedawno zaprezentował program do obsługi notatek korzystających z serwera Evernote - NixNote2. Wprawdzie w AUR dostępne są aż trzy wersje tego programu, jednakże ta, która dostarcza dokładnie tę wersję, którą przedstawiam jest wyłącznie przebudowaną paczką deb. Nie wiem dlaczego autor tego PKGBUILDu postąpił w ten sposób, albowiem NixNote2 udostępnia źródła, a sama kompilacja nie trwa długo.
Więcej o programie w wyżej zamieszczonym odnośniku do Przystajnika.
Zatem już wyłącznie krótko - to co przedstawiam to PKGBUILD programu w wersji 2.0-beta11, budowanej bezpośrednio ze źródeł. Obecnie to ostatnia dostępna beta tego programu i jednocześnie najnowsze wydanie. Jeśli ktoś korzysta z Evernote i nie są mu straszne zapędy ich pracowników, ma do dyspozycji również możliwość zbudowania sobie natywnej paczki dla Archa, Manjaro i pochodnych.

Filmulator-GUI - edytujemy zdjęcia

Zaprzyjaźniony Przystajnik, który udaje, że go nie ma jest niestrudzonym dostawcą informacji o wszelkiego rodzaju programach do obróbki zdjęć, czy filmów, które są dostępne na linuksa. Polecam jego blog, bo ciężko znaleźć lepszą i bardziej syntetyczną informację o tego typu programach. Z początkiem roku obwieścił nam o istnieniu kolejnego już programu, który temu służy - Filmulator-GUI. Autor tego ostatniego opisując program stwierdza tajemniczo, że program jest: A Qt Quick GUI adaptation of Filmulator :) O samym programie nie będę pisał. Wyżej macie odsyłacz do tekstu salvadhora, który polecam. Jedyne co napiszę, to, że program znajduje się jeszcze we wstępnej fazie rozwoju i choć dorobił się numeru 0.6, to jednakże wciąż jest to alpha. M.in. dlatego zdecydowałem się na przedstawienie PKGBUILDu w wersji rozwojowej (GIT). O programie mogę powiedzieć tylko tyle, że jego autor umieszcza plik wykonywalny programu w niestandardowym miejscu. PKGBUILD naprawia ten błąd bez ingerencji w kod źródłowy (stąd też taka "dziwna" sekcja package).

Latte-Dock - dock jak w macOS w Plasma 5

Z jakiegoś powodu wielbimy zawsze to czego nie mamy. Najlepsze środowisko? Niemal zawsze prędzej czy później pojawi się stwierdzenie: to od "makówki".  Ok, jednym z jego elementów jest tzw. dock. W linuksie jest dostępnych dość sporo tego typu rozwiązań (choćby minimalistyczny plank, czy rozbudowane cairo-dock). Niemniej jednak wszystkie te rozwiązania korzystają zwykle z bibliotek gtk. Pewnie już znacie moje poglądy - jeśli w środowisku nie potrzebuję "obcych" bibliotek, to ich nie używam. Pchanie do pamięci dodatkowo bibliotek gtk, tylko i wyłącznie po to, by uzyskać efekt wow w postaci docka w Plasma 5 jest dla mnie bez sensu (choć może się okazać, że taki plank ma absolutnie minimalny apetyt na zasoby). Mniejsza o to. Dla Plasma 5 (czy też ogólnie dla środowisk, które wykorzystują KF5) do tej pory nie było niemalże takich rozwiązań. Niedawno na store.kde.org zagościł New Dock. Ja proponuję inne rozwiązanie: Latte-Dock, zresztą tego samego twórcy. Zasada taka sama - dodatkowy "panel", który umożliwia dodanie do niego najpopularniejszych aplikacji i wyzwalanie ich z owego miejsca. Hmmm... w zasadzie, to przecież Plasma 5 ma "w standardzie" - nic nie stoi na przeszkodzie w taki sposób skonfigurować panel. Ludzie (w tym ja) lubią jednak gotowe rozwiązania. Zatem Latte-Dock w wersji na Archa, Manjaro i pochodne. Oczywiście u mnie wyłącznie PKGBUILD.
Programik jest tak prosty, że opisu - niemal jak zawsze - u mnie nie będzie. Zachęcam do wypróbowania, albowiem wydaje się być dość dobrze konfigurowalny, w tym także co do miejsca położenia docku.

wtorek, 10 stycznia 2017

Poprawiamy Lumina DE z AUR

Sporo ostatnio o projekcie nowego środowiska graficznego o nazwie Lumina. Jest to projekt tworzony od jakiegoś czasu w ramach systemu TrueOS. Niech nikogo nie zmyli nazwa. TrueOS to nie jest nowy system, a jedynie nowa nazwa dla rozwijanego od 2005 r. PC-BSD. Sama Lumina powstała z potrzeby uniezależnienia się systemów BSD od środowisk ściślej związanych z linuksem w obawie, że dalsza integracja takich rozwiązań jak systemd, czy wayland ze środowiskami doprowadzi do co najmniej trudności, jeśli wręcz nie braku możliwości dalszego korzystania przez BSD ze środowisk znanych głównie z linuksów. Jednocześnie linux otrzymał nowe środowisko. Jest to kolejne, należące do nielicznej w sumie grupy środowisk opartych o Qt5. Środowisko też mieni się "lekkim" (samo siebie tak określa, ba nawet twierdzi, że jest ono "very lightweight"). Śmiem w to wątpić. Nie w tym jednak rzecz.
W AUR istnieją dwa PKGBUILDy, które pozwalają na instalację tego środowiska. Pierwszy z nich umożliwia instalację w wersji 1.1.0, drugi w wersji "git". Oba, niestety, kompilują środowisko bez wkompilowania weń plików lokalizujących. Pierwszy PKGBUILD nie tylko dostarcza już przestarzałej wersji środowiska, ale sam jest również przestarzały.
Jeśli ktoś zatem chciałby wypróbować sobie to środowisko, to zapraszam do skorzystania z załączonego PKGBUILDu, który w odróżnieniu do obu znajdujących się w AUR: 1) buduje ostatnią wersję "stabilną", czyli 1.2.0-p1, 2) buduje również pliki lokalizujące środowisko, 3) sam kod PKGBUILDu został nieco oczyszczony i pozbawiony zbędnych dodatków.
Z samego PKGBUILDu nie jestem do końca zadowolony, jednakże buduje poprawną paczkę, a samo środowisko działa poprawnie (z ograniczeniami, jakie w linuksie niesie w stosunku do BSD).

Osoby chcące zbudować Lumina DE, muszą pamiętać jednakże o jednej rzeczy. Jeśli używają aktualnej wersji systemu oraz tzw. czcionek Infinality, to Lumina nie skompiluje się, a jeśli została skompilowana przed zaktualizowaniem paczki harfbuzz zaprzestanie działać. Problem i jego możliwe rozwiązania już opisałem.

I jeszcze informacja dla użytkowników Manjaro. W Manjaro, Lumina DE jest w repozytoriach w binarnej postaci. Także i ta wersja nie jest kompilowana w sposób umożliwiający lokalizację.

Zmuszamy LO do pracy z kolorami systemowymi w Plasma 5

LibreOffice to oporny program do zintegrowania z Plasma 5. Kiedy uporamy się już niemal ze wszystkim, nadal okazać się może, że jego kolorystyka odstaje od tej, którą wybraliśmy sobie w systemie. I jakkolwiek problem jest dość słabo widoczny przy ustawieniach domyślnych (kolorystyka breeze), to w przypadku innych, czy to tworzonych we własnym zakresie, czy też pobranych z sieci, może drażnić.
Ustawienia systemowe Plasma 5 oferują pewne elementy, które winny integrować wygląd aplikacji spoza środowisk KF5/Qt5 z jej ustawieniami. Pośród nich znajdziemy oczywiście także i te, dotyczące ustawień kolorów systemowych. Okazuje się, że naturalny odruch, jakim jest zaznaczenie opcji Nałóż kolory na programy spoza Qt działa odwrotnie (przynajmniej w przypadku LO) do tego co sugeruje. Po odznaczeniu tej pozycji, LibreOffice przyjmuje systemową kolorystykę.

poniedziałek, 9 stycznia 2017

Niedziałające programy po aktualizacji harfbuzz

W sobotę na serwerach Archa zawitała aktualizacja harfbuzz i harfbuzz-icu do wersji 1.4.1. Objawy - są ciekawe, albowiem aktualizacja przechodzi bez żadnych problemów, działające programy nadal działają, aż do... ponownego uruchomienia. Wówczas największe oczy mogą mieć osoby korzystające z Plasma 5, albowiem przywita ich czarny ekran z wyświetlonym napisem: Couldn't start kdeinit5. Please check your installation.
Informacja, jak informacja - skoro startować nie może kdeinit5, to wydawałoby się, że coś jest z instalacją (bądź konfiguracją) Plasmy. Nic bardziej złudnego. Całą sprawę powoduje zakutalizowany harfbuzz, a w zasadzie to nie tyle on, co... dość powszechnie stosowane czcionki Infinality. To one, a w zasadzie freetype2-infinality jest niedostosowany do nowej wersji harfbuzz, co skutkuje brakiem możliwości wejścia do środowiska.
Jak się okazuje, problem dotyczy także innych aplikacji, jak VirtualBox, czy Lumina. Co ciekawe, nie dotyka LXQt, które uruchamia się prawidłowo, tym bardziej sugerując jakiś błąd Plasmy.

Wyjścia są dwa, z czego jednego nie polecam, ale o tym za chwilę. Przede wszystkim musimy się dostać w dowolny sposób do trybu konsolowego. Skoro już nas ekran taki jw. przywitał, to wciskamy: Ctrl+Alt+F2...8, logujemy się do swojego konta i:

1. Rozwiązanie pierwsze, niepolecane przeze mnie, to deaktualizacja harfbuzz. Możemy to zrobić na kilka sposobów najprościej skorzystać z narzędzia downgrade lub jeśli posiadamy w /var/cache/pacman/pkg wcześniejsze wersje harfbuzz instalacja wprost z dysku używając do tego wyłącznie pacmana.
W pierwszym przypadku należy wpisać:
downgrade harfbuzz harfbuzz-icu
a następnie wybrać z dostępnej listy ostatnią, wcześniejszą wersję (będzie ona oznaczona nr 2 w obu przpadkach).
W drugim przypadku należy wywołać:
pacman -U /var/cache/pacman/pkg/harfbuzz_pełna_nazwa_paczki
czyli najprościej wcisnąć, po słowie harfbuzz. To samo należy powtórzyć z harfbuzz-icu.
Wykorzystanie downgrade umożliwia jeszcze dość łatwe dodanie obu paczek do IgnorePkg, w drugim przypadku musimy to zrobić ręcznie, edytując plik /etc/pacman.conf.

Nie polecam jednakże tego rozwiązania, albowiem od harfbuzz zależne mogą być inne programy, które pojawią się w repozytorium, które będą skompilowane na podstawie nowej już wersji harfbuzz i problem z niedziałającymi programami się powtórzy, ale w odwrotną stronę.

2. Drugie rozwiązanie, to odinstalowanie paczek infinality oraz zainstalowanie ich systemowych odpowiedników. To rozwiązanie jest bezpieczne, aczkolwiek jego konsekwencją będą nieco gorzej renderowane czcionki ekranowe.
W pierwszej kolejności musimy znaleźć paczki "infinality". Najprościej zrobimy to pytając bazę pacmana:
pacman -Qs infinality
W odpowiedzi dostaniemy spis paczek zainstalowanych czy to z repozytorium Infinality (które kiedyś opisywałem) lub zbudowane z AUR.
Musimy dokonać odinstalowania tych paczek i zainstalowania ich systemowych odpowiedników. Czyli jeśli w odpowiedzi otrzymamy, że zainstalowane paczki to np. freetype2-infinality-ultimate i fontconfig-infinality-ultimate, to wykonujemy polecenie:
pacman -S freetype2 fontconfig
W jego wyniku dwukrotnie zostaniemy powiadomieni o tym, że próbujemy zainstalować w systemie paczki, które kolidują z paczkami infinality. Dwukrotnie zatem odpowiadamy twierdząco, a resztę wykona pacman.

Niestety próba instalacji infinality z AUR również się nie powiedzie, albowiem dla wersji, która jest tam budowana harfbuzz w systemie będzie zbyt nowy, a kompilacja po prostu nie powiedzie się.