czwartek, 31 marca 2016

Kate 16.03.80 przestaje funkcjonować po dzisiejszej aktualizacji

Jeśli ktoś dzisiaj zaktualizował system i jednocześnie ma:

  • włączone repozytorium [kde-unstable] i używa KDE-Applications 16.03.80,
  • włączone repozytorium [testing] (to akurat nie jest bardzo istotne tym razem),
  • używa kate/kwrite,
to może się spotkać z niemiłą niespodzianką w postaci braku możliwości uruchomienia co najmniej kate. Trzeba przebudować kate na podstawie dostarczonych do systemu libgit2 i kdetexteditor.
W tym celu musimy ściągnąć skrypty budujące kate:
yaourt -G extra/kate
extra, albowiem inaczej yaourt nie ściągnie.
Przechodzimy do katalogu kate i zmieniamy:

  • pkgver z 15.12.3 na 16.03.80,
  • pkgrel z 1 na 2,
  • w linii source wymieniamy "stable" na "unstable"
Zamykamy plik i wydajemy polecenia:

updpkgsums && makepkg -sirc
Od tej pory możemy się cieszyć działającym kate w wersji 16.03.80 (czyli 16.04 beta).

EDIT:
W repozytorium jest już dostępna wersja 16.03.80-2, która została przebudowana i problem opisany wyżej już nie występuje.

Poprawiamy Plasma 5.6 - Tuning środowiska cz. 1

Prawdopodobnie nie dla wszystkich ten wpis. Na pewno nie po to, by "małpować" rozwiązania. Jak to mawiają: u mnie działa. Do szewskiej pasji mnie to zwykle doprowadza, ale... no właśnie. U mnie zadziałało. Zatem zanim cokolwiek przeczytacie dalej - kwestia podstawowa: na czym działa.
Otóż od bodaj 2, czy 3 lat jestem w zasadzie zadowolonym właścicielem notebooka HP. Cienki, lekki. Tani. To ostatnie, biorąc pod uwagę mój stosunek do tego typu sprzętu od lat, jest dość ważne. Notebook ma być na tyle tani, by po 3-4 latach, gdy po prostu ducha wyzionie (technicznie, fizycznie, moralnie - niepotrzebne skreślić) nie bolało. Od kilku też lat jestem - przy moich potrzebach (nie jestem graczem, notebook potrzebuję do typowej pracy biurowej i niekiedy jakichś multimediów) - zwolennikiem platformy AMD. Nie trzymam się jej kurczowo, jednakże mój obecny notebook to AMD A6-4455M z wbudowaną (APU) weń grafiką AMD Radeon HD7500G. Od dłuższego też czasu buduję sobie pod niego kernele. Zwykle na pokładzie miewają BFQ, patch graysky'ego, który dostosowuje kernel (w zasadzie, to jego budowę) do określonego CPU (u mnie Piledriver). Od pewnego czasu też ma BLD i nie ma CK/BFS. Jeśli jest, bądź uda się dostosować, to ma UKSM. Nadto jest mocno "wycięty" z rzeczy, których nie mam, bądź nie stosuję. Środowisko to Plasma 5, gdzie nie bardzo ograniczam się w absolutnym minimaliźmie. Ma to co lubię, potrzebuję, chcę...
Zatem dalszy opis jest przede wszystkim dla osób korzystających z platformy AMD i Plasma 5. Właściciele komputerów opartych o Intela, o rozwiązania z NVidią, będą musieli znaleźć swoje optymalne rozwiązania.
U mnie poprawa działania (jedna z kilku, stąd część pierwsza w nagłówku) odbyła się tak:
1. W Ustawieniach Systemowych (systemsettings) znajdujemy Sprzęt a w nim Wyświetlanie i monitor.
2. Przechodzimy do Kompozytor
3. Zmieniamy/ustawiamy

  • Szybkość animacji: przesuwamy w stronę "Natychmiastowe" (ile chcemy),
  • Sposób skalowania: Szybki,
  • Silnik wyświetlania: OpenGL 3.1,
  • Interfejs OpenGL: EGL.
Być może trzeba się z tym jeszcze pobawić, oswoić, ale wobec odczuć w stosunku do "oryginału" jest według mnie bardziej responsywnie.
Każdy pewnie będzie musiał znaleźć sobie jakieś własne ustawienia, ale na pewno warto spróbować. Zanim jednak zaczniecie się bawić - dobra rada: zrobić sobie kopię katalogu ~/.config. 


Plasma 5 bez... OpenGL

Co do zasady Plasma 5 jest oparta o OpenGL. Co zatem zrobić, gdy nie można z niego skorzystać (np. nie udała się  aktualizacja sterowników własnościowych NVidia), bądź też gdybyśmy chcieli skorzystać z tego środowiska na niezbyt mocnych (by nie powiedzieć, na dzisiejsze warunki słabych) komputerach?
Z pomocą przychodzi obecne od Qt 5.6 QtQuick 2D Render, które winno umożliwić uruchomienie Plasma 5 (w wersji zbudowanej na Qt5.6, co nie jest równoznaczne z Plasmą 5.6) w trybie niewymagającym OpenGL.
Możemy to zrobić poprzez uruchomienie plasmashell ze zmienną systemową:
export QMLSCENE_DEVICE=softwarecontent
Jeśli potrzebne jest to nam na stałe, możemy taką zmienną dodać np. do pliku ~/.bashrc, ale lepiej umieścić ją w katalogu ~/.config/plasma-workspace/env/ w pliku o dowolnej nazwie, najlepiej zakończonej suffiksem ".sh". Plik winien mieć następującą zawartość:
#!/usr/bin/bash
export QMLSCENE_DEVICE=softwarecontent
Dla pewności nadajemy mu uprawnienia wykonywalne (choć Plasma 5 tego nie powinna potrzebować):
chmod +x nazwa_pliku.sh
Taki plik winien być automatycznie uruchamiany przed startem środowiska. Dla upewnienia sprawdzamy, czy w istocie plik jest uruchamiany przed plasmashell:
systemsettings->Uruchamianie i wyłączanie->Samoczynne uruchamianie
Tutaj sprawdzamy, czy nasz skrypt został prawidłowo dodany i czy włącza się przed startem środowiska.
Jeśli natomiast zajdzie jednorazowa potrzeba wystartowania Plasmy bez OpenGL, wówczas komendę startującą Plasmę poprzedzamy wyeksportowaniem wyżej wymienionej zmiennej.

Więcej: w blogu Davida Edmundsona.

Otter-Browser #117

Dość długo nie prezentowałem PKGBUILDów umożliwiających budowę wydań tygodniowych Otter-Browser. Działo się tak z dwu powodów. Otter budowany na QtWebEngine wymagał tej biblioteki w wersji Qt 5.6, ta zaś była w repozytorium testing. W przypadku Ottera budowanego na QtWebKit w zasadzie nic się nie działo, zatem budowa nowej wersji tygodniowej byłaby po prostu zbędną rozrywką.
Po opublikowaniu wydań #116 i #117 i po konsultacjach z zespołem twórców tej przeglądarki zdecydowałem się udostępniać wyłącznie PKGBUILD budowany w oparciu o qt5-webengine. Nie oznacza to, że Otter-Browser nie może działać w oparciu o qtwebkit. Po prostu takiego wydania, aż do odwołania u mnie nie znajdziecie. Jeśli jednak ktoś by bardzo chciał, to proszę zasygnalizować w komentarzach. Wówczas napiszę co trzeba zmienić.
Po zmiany jakie zaistniały ostatnio odsyłan na stronę domową przeglądarki. Jest ich sporo, choć niektóre dopiero w powijakach.
Teraz już tylko PKGBUILD (plik *.install nie ulega zmianie):
# Maintainer: boenki <boenki at gmx dot de>
# Maintainer: pavbaranov
# Contributor: sir_lucjan

pkgname=otter-browser-weekly
_pkgname=otter-browser
_pkgver=0.9.10
_weekver=117
pkgver=${_pkgver}.dev${_weekver}
_devver=${_pkgver}-dev${_weekver}
pkgrel=1
pkgdesc="Web browser controlled by user, not vice-versa"
arch=('i686' 'x86_64')
url="http://$_pkgname.org"
license=('GPL3')
depends=('qt5-multimedia' 'hicolor-icon-theme' 'desktop-file-utils' 'qt5-webengine')
makedepends=('cmake' 'qt5-tools')
optdepends=('gstreamer0.10-ugly-plugins' 'hunspell')
conflicts=('otter-browser-git' 'otter-browser' 'otter-browser*' 'otter-browser-beta*' 'otter-browser-webengine-weekly' 'otter-browser-webkit-weekly')
install=otter.install
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2")
md5sums=('73818126a9d0d4342ef01f6f2b3a179a')

build() {
  cd ${_pkgname}-${_devver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr" 
  make
}

package() {
  cd ${_pkgname}-${_devver}
  make DESTDIR=$pkgdir install
}

Plasma 5.6.1

Krótko. Pojawiło się pierwsze poprawkowe wydanie Plasmy z serii 5.6.x. Oczywiście nie niesie ze sobą żadnych nowości, a jedynie poprawia dostrzeżone błędy.
Spośród sygnalizowanych wcześniej przeze mnie wyeliminowano m.in. wadliwe wyświetlanie apletu "Pokaż pulpit" oraz ograniczono (niestety praktyka wykazuje, że nie zostały one wyeliminowane w 100%) wycieki pamięci. Proponowane przeze mnie zatem rozwiązania w cyklu Poprawiamy Plazmę 5.6.0 nie są już konieczne. Wszystkie zawarte tam łatki zostały uwzględnione w Plasma 5.6.1.
Niestety w dalszym ciągu start Plazmy może zakończyć się widokiem "czarnego ekranu". Prace w toku, ale nie w samym środowisku twórców KDE, a pośród deweloperów Qt. Mają one zostać usunięte w poprawkowym wydaniu Qt 5.6.1.

wtorek, 29 marca 2016

Zrozumieć niezrozumiałe: dd i... gdzie się podziały moje dane

W niektórych dystrybucjach jest prosto: ściągnij ISO, ściągnij unetbootin, uruchom unetbootin "nagraj" bootowalnego pendrive'a.  Prosto, szybko, skutecznie. Obraz ISO umieszcza się "obok" danych, które mamy na pendrive (jeśli starcza miejsca - jeśli nie - informuje o tym). Zwykle od unetbootina zaczynamy. Wieloplatformowy, intuicyjny, prosty w obsłudze i... polecany na wielu stronach z tymi najbardziej '"ludzkimi" dystrybucjami spod znaku pingwina. Nie wszystkie jednak dają się poprawnie nagrać przez unetbootin. Tak jest np. z Archem, Manjaro, Chakrą... Praktycznie każdą dystrybucją "archopodobną", czy archopochodną. Tutaj polecane jest konsolowe narzędzie dd. Niekiedy znajdziemy tajemnicze narzędzia GUI typu isousb, czy pochodzące z OpenSUSE lub Fedory podobne do niego. Wszystkie one stanowią wyłącznie nakładkę na dd.
Czytamy zatem, że należy wykonać:
dd if=ścieżka_do_iso of=/dev/sdX
To X, to jakaś literką symbolizująca napęd USB. I tyle. Gdzieniegdzie pojawi się jeszcze informacja, że działanie powyższe wykasuje wszystkie pliki na pendrive. Kto to czyta? Przyzwyczajenie jest drugą naturą człowieka. Rozum podpowiada: skoro mam 16GB pendrive'a i na nim zajęte jedynie 4GB, to na tym samym nośniku musi się zmieścić przecież np. 1GB dystrybucja. Oczywiście się zmieści. Zmieści się nawet taka 16GB. Zatem wklepujemy bezmyślnie w terminalu powyższe polecenie, a potem... Potem jest lament. Gdzie się podziały moje pliki, które tam przecież powinny zostać, bo miejsca na pendrive było pod dostatkiem. Nadto pendrive jest sformatowany w jakimś dziwnym formacie. Jest znacznie mniejszy niż 16GB. Nie daje się zapisać. Ba, nie daje się "normalnie" sformatować, by odzyskać utracone miejsce, nie mówiąc już o utraconych plikach.
Otóż dd to nie jest "zwykłe" narzędzie do kopiowania plików. Inaczej, pod linuksem wystarczyłoby cp (lub do przeniesienia mv). Inne systemy również mają swoje odpowiedniki. Po jakiego zatem diabła owe dd?
Nie będę się rozpisywać po co ono jest i jakie może mieć zastosowania. Przynajmniej nie tym razem. Konieczne jest natomiast uświadomienie sobie co powoduje jego zastosowanie w praktyce w odniesieniu do pliku ISO.
Trzeba zatem zrozumieć czym jest plik *.iso, czy też "obraz dysku".
Otóż najprościej mówiąc jest to cyfrowa kopia dysku CD bądź DVD umieszczona w jednym pliku. W czasach, gdy nośniki te były popularne, na nich otrzymywaliśmy różnego rodzaju systemy operacyjne, gry, cokolwiek... Wkładaliśmy do czytnika CD/DVD i... Dalej już było prosto. Jeśli był to dysk z zawartym tam systemem operacyjnym, który dawał się instalować (a najczęściej tak było), to dysk startował, a potem już tylko należało klikać "Dalej".
Problem  leży w tym, że taki dysk CD/DVD jest zestandaryzowany. Ma swój system plików. Ma swoją pojemność, która jest m.in. wynikiem owego systemu plików (w uproszczeniu). Całość natomiast zachowuje się w taki sposób, że gdy na nośniku DVD, którego standard przewiduje 4,4GB danych nagramy obraz o wielkości 300MB, to... Wówczas DVD będzie miało pojemność 300MB i ani bajta więcej. Ponad 4GB "pojemności" nie będzie już nigdy widoczne, a nośnik zostanie zapełniony w 100%. Gdzie zatem się podziało 4,1GB? Nigdzie.  Po prostu tego, dla obrazu, który ma 300MB nie ma. Obraz, to obraz. Nie może być mniejszy lub większy, albowiem zajmuje całość. Cokolwiek staje się zrozumiałe?
Wróćmy zatem do plików *.iso oraz pendrive.
Kiedy popularne stały się pendrive i to w wielkości, która umożliwiła na nich zapisanie plików obrazów, stwierdzono, że najprościej jest trzymać się standardu. Mamy zatem pendrive oraz obraz dysku. Taki sam, jaki był wgrywany na CD/DVD. Trzeba było jeszcze stworzyć narzędzie, które z naszego pendive zrobi "udawane" CD/DVD. I takim właśnie jest dd. Starsze zresztą od nagrywania obrazów ISO na pendrive.
Co zatem robi dd? Najprościej mówiąc - zgodnie zresztą z nazwą (dd = disk dupe, czyli duplikowanie dysku) - tworzy fizyczną kopię dysku, który jest kopiowany. Jeśli takim "dyskiem" jest jego obraz zawarty w pliku *.iso, to stworzy on na docelowym nośniku cyfrową kopię odpowiadającą obrazowi dysku zawartemu w ISO. Kopię dokładną. Bit w bit. Dlatego też jeśli obrazem dysku jest obraz CD bądź DVD, to po "wgraniu" go na pendrive, otrzymamy pendrive, który dla maszyn takich jak komputer wygląda tak samo jak CD, czy DVD. Ma taką samą strukturę, taki sam format plików i taką samą wielkość jak oryginał.
Teraz już nic dziwnego, że pendrive potraktowany przez dd przyjmuje fizyczną postać CD, czy DVD.
Musimy sobie jeszcze uświadomić tego konsekwencje. Otóż jeśli ów pendrive był sformatowany jako np. FAT32 (tak jak praktycznie 100% dostępnych w handlu), to po potraktowaniu go poleceniem dd otrzymamy pendrive, którego system plików nazywał się będzie ISO9660. Dlaczego? Bowiem jest to standard przyjęty przez międzynarodową instytucję standaryzującą. Użyte polecenie dd - w tym znaczeniu - jest równoważne usunięciu dotychczasowego systemu plików, wprowadzeniu nowego i sformatowaniu go do wielkości w bajtach odpowiadającej wielkości wgrywanego pliku ISO.
Czy można w takiej sytuacji odzyskać dane na pendrive "przypadkowo" utracone? W absolutnej większości przypadków nie. Przynajmniej nie "domowymi" sposobami. Zmianie uległa bowiem cała struktura dysku (pendrive'a), a nadto ta nowa struktura została zapisana danymi. Są wprawdzie instytucje, które podejmują się takich zabiegów jak odzyskanie danych potraktowanych w ten sposób, ale same nie ręczą za sukces, proces jest bardzo długi, a koszt jego olbrzymi dla "zwykłego użytkownika".
Cóż... "a nie mówiłem"? Trzeba najpierw czytać, zanim się coś na łapu capu zrobi.
Pozostaje jeden problem. Pendrive "potraktowany" przez dd "staje się" CD lub DVD. Standard ten nie przewidział jego fomatowania, stąd też proste pomysły typu użycie jakiegokolwiek narzędzia do fomatowania czy tworzenia partycji na dysku (jak np. gparted) na nic się nie zdadzą. Najpierw musimy komputer poinformować o tym, że udający CD/DVD pendrive nie jest takim nośnikiem. Musimy zatem wyzerować obszar pierwszych 512 bitów takiego pendrive. Zrobimy to tak:
# dd count=1 bs=512 if=/dev/zero of=/dev/sdX && sync
gdzie X jest literą pod jaką nasz system widzi napęd pendrive.
Potem już pójdzie prosto, albowiem taki dysk będzie dawał się sformatować pod wybrany przez nas system plików, w dowolnym, preferowanym przez nas programie.

Zob. też w moim starym wpisie oraz linkach w nim zawartych.

poniedziałek, 28 marca 2016

Poprawiamy Plasma 5.6: ograniczamy wycieki pamięci

Niestety nowe wydanie Plasmy ma tendencje do wycieków pamięci. Stosowne łatki, które proces ten ograniczają są już dostępne i winny zostać uwzględnione w Plasma 5.6.1. Dla niecierpliwych podaję jak to zmienić.
Odpowiedzialna paczka, to plasma-dekstop. To tutaj są wycieki. Poniżej podaję zbiór łatek, które ów wyciek ograniczą. Nie wyeliminują, a jedynie ograniczą. Zmiana jednak jest dość duża. Przynajmniej w przypadku mojej konfiguracji. Nie będę podawał nowego PKGBUILDu, a jedynie sposób, który zapoczątkowałem we wcześniejszym wpisie.
Ściągamy plasma-desktop i przechodzimy do ściągniętego katalogu:
yaourt -G plasma-desktop
Dokonujemy niezbędnych zmian:
Pole pkgrel - zmieniamy numer wersji np. na 2.
Pole sources - dopisujemy (nie wszystkie poniższe commity niwelują wycieki pamięci, ale są to wszystkie, jakie umożliwiają naprawę błędów do dzisiaj). Dodajemy:
commit027e9dc::"https://quickgit.kde.org/?p=plasma-desktop.git&a=commitdiff&h=027e9dc&o=plain"commitbc28403::"https://quickgit.kde.org/?p=plasma-desktop.git&a=commitdiff&h=bc28403&o=plain"commitfc9a550::"https://quickgit.kde.org/?p=plasma-desktop.git&a=commitdiff&h=fc9a550&o=plain" commit1db2c03::"https://quickgit.kde.org/?p=plasma-desktop.git&a=commitdiff&h=1db2c03&o=plain"
Dodajemy w sekcji prepare (po mkdir -p build):
cd ${pkgname}-${pkgver}
patch -Np -i "${srcdir}/commit027e9dc"
patch -Np -i "${srcdir}/commitbc28403"
patch -Np -i "${srcdir}/commitfc9a550"
patch -Np -i "${srcdir}/commit1db2c03" 
Dokonujemy aktualizacji sum dla źródeł:
updpkgsums
Budujemy i instalujemy paczkę:
makepkg -sirc 
Oczywiście warto sprawdzić PKGBUILD i zbudowaną paczkę przez namcap.

Poprawiamy Plasma 5.6: "pokaż pulpit" nie degraduje już paska zadań

Wprawdzie o Plasma 5.6 moje zdanie nie jest najlepsze, albowiem uważam, że wyszła ona nazbyt szybko (bo termin) i nie zostały w niej poprawione błędy, które były znane co najmniej od chwili wydania 5.5.95. W niektórych przypadkach, instalacja nowej wersji środowiska prowadziła do degradacji wcześniejszego pulpitu. Zamiast paska zadań (panel) pojawiało się coś, co kompletnie nie było użyteczne. Dzieje się tak wówczas, gdy do paska mamy dodany plazmoid "Pokaż pulpit" (Show Desktop). Okazuje się, że w planowanym za kilka dni wydaniu poprawkowym (5.6.1) ten błąd ma zostać usunięty. Stosowna łatka jest już dostępna i można ją nałożyć.

Poniżej stosuję m.in. yaourt, ale nikomu nie każę go stosować. Można użyć dowolnej nakładki (np. pacaur) na pacmana, która umożliwia łatwe ściągnięcie plików źródłowych, służących do budowy pakietów w Archu. Oczywiście można również zastosować narzędzie ALA, ale wg mnie jest to jak strzelanie z armaty do muchy. Można też ściągnąć pliki źródłowe ze strony packages Archa. Mniejsza o to jak ściągniecie, ważne, by otrzymać owe skrypty.

Błąd jest w kdeplasma-addons 5.6.0, zatem konieczne jest pobranie skryptów dla tych źródeł. Przechodzimy do wygodnego dla nas katalogu, w którym chcemy budować program. Pamiętajmy, by wcześniej taki katalog wyłączyć z indeksowania przez baloo, bo nie ma to najmniejszego sensu. Osobiście kompilacji dokonuję w katalogu ~/temp, ale może on mieć dowolną nazwę.
cd ~/temp && yaourt -G kdeplasma-addons && cd kdeplasma-addons
Jesteśmy zatem w katalogu, w którym znajdują się ściągnięte skrypty służące makepkg do budowy paczek dla Archa. W katalogu tym powinniśmy znaleźć dwa pliki: PKGBUILD oraz kdeplasma-addons.install. Drugiego w ogóle nie zmieniamy, pierwszy poddajemy edycji dowolnym edytorem. Nie będę tu przytaczał całego PKGBUILDa, opowiem tylko co i jak musimy zmienić.
Po pierwsze musimy dodać do źródeł łatkę. Znajdujemy zatem linię rozpoczynającą się od source i do istniejącego tam adresu dodajemy łatkę. Można to zrobić na wiele sposobów. Jednym z nich jest ściągnięcie do katalogu łatki z quickgit.kde.org za pomocą np. wgeta, albo przekopiowanie zawartości (pamiętajmy, że musi to być widok plain) do jakiegoś pliku. Ja preferuję pokazanie makepkg źródła, które ma zostać pobrane oraz wskazanie w jaki sposób ma to uczynić. Reszta będzie dziać się automatycznie. W tym przypadku nazwa, jaką nadamy łatce jest obojętna. Stosowny commit, który naprawił nam ShowDesktop znajduje się tutaj. Do pola source dodaję zatem:
nazwa_łatki::"adres_git&a=commitdiff&h=oznaczenie_commitu&o=plain"
Teraz pora na wytłumaczenie:
nazwa_łatki - Moja nazwa, sam ją nadaję. Ze względu na to, że jest to commit, to występuje jako plik tekstowy, który sam w sobie nie nosi żadnej nazwy. Sensownie jest nadać mu taką nazwę, która będzie będzie łatwo identyfikować łatkę, którą nakładamy. Ja preferuję dwa sposoby, albo oznaczam taką łatkę przez oznaczenie commitu, albo przez numer błędu, który naprawia, ze względu na to, że często kilka commitów naprawia jeden błąd, bądź jednym udaje się naprawić kilka, może nawet sensowniejszym pomysłem jest stosowanie jako nazwy łatki oznakowania commitu.
adres_git - Tu chyba wszystko jasne. Miejsce w repozytorium git, z którego pobierać będziemy łatkę. W przypadku, gdy stosujemy jako adresu quickgit, to adres ten przybierze postać: https://quickgit.kde.org/?p=nazwa_kodu.git. Owa tajemnicza nazwa_kodu to nadana przez twórców danemu elementowi KDE nazwa. W naszym przypadku będzie to kdeplasma-addons.
oznaczenie_commitu - Każdy commit (czyli po prostu fragment kodu) ma swoje oznaczenie. Na stronie https://quickgit.kde.org/?p=nazwa_kodu.gitznajdziemy po lewej stronie w shortlog. Interesujący nas dzisiaj commit nosi oznaczenie: e164ae7.
Pozostaje wytłumaczyć jeszcze dwie kwestie: a=commitdiff oraz o=plain. Obie odpowiadają za sposób w jaki pobierana ma być łatka. Pierwszy stwierdza, że ma to być plik "różnicowy", który po prostu wskazuje jakie elementy kodu mają być zastąpione przez nowe. Drugi stwierdza, że ma owa łatka zostać pobrana w czystym pliku tekstowym.
Nasz adres zatem, w tym przypadku, przybierze taką oto postać:
commit_e164ae7::"https://quickgit.kde.org/?p=kdeplasma-addons.git&a=commitdiff&h=e164ae7&o=plain"
Linię tę musimy dodać do pola source w PKGBUILD (pamiętajmy, musi ona zostać zamknięta w nawiasach.
Następnie odnajdujemy pozycję prepare w PKGBUILD i dodajemy tam polecenie nakładające łatkę (po mkdir -p build):
cd ${pkgname}-${pkgver}
patch -Np1 -i "${srcdir}/commit_e164ae7"
Cała sekcja prepare przymie zatem taką postać:
prepare{} (
coś
nasze polecenie z łatką)
Przydałoby się również naszej paczce zmienić numer pkgrel. Odnajdujemy w PKGBUILD taką pozycję i "podbijamy" o jeden numer w górę. W ten sposób, przy późniejszej aktualizacji systemu ujrzymy, że zbudowana przez nas paczka jest w wersji lokalnej "wyższej" niż paczka w repozytorium. Jeśli ostrzeżenie to zniknie, będzie to oznaczać, że albo pojawiła się paczka w takiej samej wersji w repozytorium, a wówczas warto sprawdzić jej PKGBUILD i zdecydować co robić dalej, albo paczka w wersji "wyższej" i nasza paczka zostanie zaktualizowana. W tym przypadku, gdy pojawi się paczka kdeplasma-addons-5.6.1-1.pkg.tar.xz to będzie ona uwzględniać przedstawioną tu łatkę.
Zamykamy plik i uaktualniamy sumy kontrolne dla makepkg:
updpkgsums
Teraz pozostaje sprawdzenie pliku PKGBUILD poleceniem:
namcap PKGBUILD
Jeśli wszystko przebiega prawidłowo, możemy przystąpić do budowy i instalacji paczki:
makepkg -s
Sprawdzamy, czy paczka została prawidłowo zbudowana:
namcap nasza_paczka 
Jeśli wszystko przebiegło prawidłowo, instalujemy zbudowaną paczkę:
sudo pacman -U nasza_paczka
Tym razem zatem opis, a nie podanie gotowego sposobu. Dajcie znać, czy jest on dla Was czytelny i czy prawidłowo się budują paczki.

środa, 23 marca 2016

Plasma 5.6 i Qt 5.6 wylądowały w Archu

Po wielu miesiącach opóźnienia w końcu ukazało się Qt 5.6. Myślę, że nie tylko użytkownicy czekali na tę wersję jak na Godota, albowiem przynieść ma ona znaczące zmiany dla programów opartych o Qt5. Pośród zmian, które niesie, umożliwi prawdopodobnie w końcu pojawienie się nowej wersji QupZilli (wersja master w GIT jest od dawna dostosowana do qtwebengine, ale włąśnie w wersji 5.6), nowy Otter Browser w wersji opartej o qtwebengine również wymaga tej wesji frameworka. Z ciekawych informacji - Qt5.6 jest wydaniem o przedłużonym wsparciu, które ma być z nami obecne przez najbliższe trzy lata. Czy to oznacza, że na Plasmę 6 będziemy czekać do roku 2020? Czas okaże, ale nie jest to wykluczone. Jak na razie zresztą inne problemy trapią Plasmę 5. A propos - na nowe wydanie Qt5 czekali również twócy KDE. Oprócz różnych optymalizacji, wersja ta bowiem miała umożliwić usunięcie kilku dolegliwości trapiących od miesięcy to środowisko.
Czy to się stało?
Odpowiem behawiorystycznie. Plasma 5.6 - jak na razie (wraz z testami Qt5.6RC oraz Plasma 5.5.95) zachowuje się dobrze. Dobrze - nie znaczy idealnie. Po wstępnych problemach, wynikających m.in. ze zmianą paczkowania (inne zależności niezbędne do poszczególnym składnikom Plasmy), środowisko umieszczone obecnie w repozytorium testing jest stabilne. Przynajmniej z mojego doświadczenia. Plasma jest bowiem - jak to wielokrotnie już pisałem - bardzo wrażliwa na przeróżne aspekty konfiguracji.
O zmianach przeczytacie pewnie tu i ówdzie. Pełny katalog zmian dostępny jest natomiast w zwyczajowym miejscu na portalu KDE. Warto również zaznajomić się z tzw. erratą wydania. Zmian, poprawek - mnóstwo. Interesujące dla użytkownika jest jednakże to, co widzą, z czego korzystają.
O jednym należy pamiętać. Pomimo tego, że lista dokonanych zmian jest olbrzymia, nie oznacza to wcale, że wszystkie dostrzeżone i sygnalizowane błędy w wydaniu zostaną usunięte. Wynika to m.in. z przyjętego cyklu wydawniczego w KDE (od czasów KDE4). Jest on zbliżony do tego, z czym mamy do czynienia w LibreOffice. Nowe wydania (KF5, Plasma 5, Applications) pojawiają się w określonym, z góry wiadomym, cyklu wydawniczym. Framework jest zamrażane w pierwszą sobotę miesiąca, a wydawane tydzień później, Plasma oparta na danym KF jest zamrażana w czwartek po wydaniu KF, w dwa tygodnie później pojawia się beta, a za następne dwa tygodnie wydanie stabilne. Aplikacje pojawiają się trzy razy do roku w kwietniu, sierpniu i grudniu (bodaj trzeci tydzień). Jest to ustawione w sposób sztywny. W okresie od zamrożenia do wydania, poprawiane są - co do zasady - jedynie błędy owego "stanu zamrożenia" (i niewiele więcej, jeśli się uda, co wynika m.in. z faktu, że niektóre błędy usuwane są nie w samej Plaźmie, a w Frameworks). Nie oznacza to, że twórcy KDE są niechętni do naprawiania błędów. Są naprawiane także między wydaniami i niekiedy dają się nakładać zanim jeszcze nastąpi wydanie poprawkowe, czy nowe "duże". Niemniej jednak rozwój KDE zbliżony jest do modelu ciągłego, tyle, że ze sztywno ustawionymi datami wydań. Odmiennie to wygląda w tych programach (środowiskach), które nowe wydania ukazują, gdy (przynajmniej co do zasady) zrealizują jakiś postawiony przed programistami cel. Każde rozwiązanie ma swoje wady i zalety. Piszę o tym jedynie, by każdy mógł zrozumieć, że nowe wydanie Plasmy raczej nigdy nie dokona naprawy wszystkich błędów dostrzeżonych od poprzedniego wydania. Pozytywne dla nas jest natomiast to, że błędy są systematycznie naprawiane i - co do zasady - każde następne wydanie likwiduje jakąś część poprzednich.

Poniżej mój, kompletnie prywatny, zestaw wrażeń nowej Plasmy. Nie mam ochoty powtarzać po innych, tego co łatwo dostępne.

PLUSY:

Cieszy powrót apletu pogody. Inna sprawa, że przyroda nie znosi próżni i w międzyczasie pojawiły się bodaj trzy, niezależnie oferowane aplety pogodowe przygotowane dla Plasma 5. Różnica między nimi głównie polega na udostępnianych serwisach pogodowych (nie liczę kwestii wyglądu, jednemu będzie się podobać jedno, innemu drugie rozwiązanie). Obecne w Plasma 5 korzysta z niemieckiego serwisu pogodowego, co od razu widać, albowiem miasto, w którym przyszło mi mieszkać nosi złowrogą nazwę Krakau. Pozostała część apletu jest spolszczona, ale Krakau, Braslau itp. razi. Wiem, to nie jest kwestia związana z Plasmą, a zależna od serwisu, z którego aplet korzysta. Szkoda tylko, że dostępny jest wyłącznie jeden. "Konkurencja" korzysta z serwisu norweskiego, Yahoo bądź OpenWeather.
Podoba mi się, że usprawnione zostały animacje. Przejścia są jakby płynniejsze, ładniejsze. To jednak kwestia odczucia.
W sumie niewiele więcej zauważyłem.

OBOJĘTNE:

"Usprawnieniem" którym się twórcy chwalą ma być animacja operacji wykonywanych w danym programie widoczna w "Zarządzaniu zadaniami" (task manager, a dla większości z nas po prostu to co widoczne na panelu). Cóż. Po pierwsze owa animacja dostępna jest wyłącznie w stanadrowym "Zarządzcy zadań". Po przełączeniu choćby na "Przełącznik zadań z ikonami" - nic już nie będzie widoczne. "Usprawnienie" ma niby zwiększać łatwość pracy w trybie wielozadaniowym. Czy aby na pewno? Śmiem wątpić, zwłaszcza, że od dawna tego typu informacje (np. o postępie kopiowania plików) dostępne są w "Informacjach" lokujących się w tacce systemowej. Nie zauważam zatem użyteczności.
Dwa następne, którymi się chwalą twórcy, to usprawnienie zarządzania kolorystyką środowiska, które ma teraz przekładać się na inne programy. Przyznam, że ani tego nie rozumiem, ani nie dostrzegłem w praktyce. Fakt - moje środowisko jest sporo zmienione w stosunku do oryginalnej Breeze, czy Breeze Dark, albowiem ze względu na odmienne gusta kolorystyczne nie jestem w stanie znieść ani paryskiego błękitu na bladoszarawoniebieskawym, ani na czarnym. Drugi to usprawnienie odtwarzacza multimedialnego, którego to usprawnienia... również nie widzę. Stary i ślepy być może już jestem.

MINUSY:

Cóż, czasy są takie, że wszystko ulegać ma uproszczeniu. Wprawdzie Plasma 5 wyłamuje się od tego wzorca i wciąż daje nam możliwości dalekiej i praktycznie swobodnej ingerencji w praktycznie każdy aspekt swego wyglądu i zachowania, jednakże niektóre elementy są likwidowane. W bieżącym wydaniu została zlikwidowana możliwość dostosowywania "Wystroju pulpitu" według własnych upodobań z poziomu "Ustawień systemowych". Oczywiście w dalszym ciągu można zmieniać owe wystroje, w tym pobierać z kde-look.org, jednakże nie ma już możliwości dostosowania takiego wystroju według własnego gustu. Jesteśmy zatem zdani na elementy wystroju w wersji takiej, jakiej dostarczył jego twórca. Jeśli zatem wszystko się nam podoba, ale nie podoba wystrój "zegara analogowego", to nie ma już możliwości zmiany. Oczywiście również możliwości  zapisania tak zmienionego wystroju. Biorąc pod uwagę, że wiele wystrojów było zmianami dokonanymi przez użytkowników właśnie poprzez dokonanie zmieszania wystrojów, dodania własnej kolorystyki (to jeszcze jest możliwe), "własnego" zestawu ikon itd., to prawdopodobieństwo, że w kde-look.org będziemy widzieć nowe zestawy tego typu jest raczej mizerne. Szkoda, bo przypomina mi to podejście znane z innych środowisk, w których mogę używać wyłącznie predefiniowanego wystroju. Jeśli mi się nie podoba, to mogę zmienić środowisko lub samemu napisać nowy wystrój. Twórca tego "usprawnienia" tłumaczył to faktem, że rozwiązanie jest rzadko wykorzystywane (ale skąd czerpał statystykę - nie mam pojęcia, prawdopodobnie z własnego doświadczenia), a przez to niepotrzebne. Miało też dublować inne rozwiązania, ale tu już nie wiadomo jakie (fakt, że część powielała np. możliwość zmian ikon, czy kolorystyki). Zauważył, że najczęściej zmieniane są w poszczególnych wystrojach wystrój panelu oraz zegar analogowy. Najczęściej poprzez dodanie transparentnego tła. Miało się zatem pojawić rozwiązanie, które umożliwi zmianę samego panela, czy zegara cyfrowego, m.in. poprzez dodanie do nich efektu transparentności, ale nie zauważam, by cokolwiek się pojawiło. W sumie jeśli byłoby to zrealizowane, to nie miałbym większych uwag. Dzisiaj jednak mamy do czynienia z taką sytuacją, że jedno rozwiązanie zostało usunięte, a w zamian nie pojawiło się nic.
Druga kwestia, to regresja w aplecie "Pokaż pulpit". Jego umieszczenie w najbardziej naturalnym miejscu, czyli na panelu, powoduje, że praktycznie wszystkie inne umieszczone na nim elementy (jak np. tacka systemowa) znikają. Sam "Pokaż pulpit" też się nie pojawia.
Trzecia sprawa, to... znikające elementy. No może nie wiele, ale dzisiaj dopadła mnie przypadłość zniknięcia z menu polecenia "Zablokuj elementy interfejsu". Otworzyłem do edycji, by sprawdzić, czy w końcu "Pokaż pulpit" działa prawidłowo i... możliwość  ponownego zablokowania - zniknęła raz na zawsze. Gwoli ścisłości - jest. To znaczy - niby jest. Jest bowiem w dalszym ciągu obecna z menu edycji ustawień panelu. Problem w tym, że... nie działa.
Niemal ostatnia sprawa, to rozrastanie się apetytu na RAM procesu plasmashell. O ile "startowe" wartości (przynajmniej u mnie) są bardzo niskie, porównywalne ze środowiskami, które uchodzą za "lekkie" (cokolwiek by to nie znaczyło), to po pewnym czasie używania środowiska, wartość ta rośnie. Dwu, trzykrotnie... Prawdopodobnie jest to związane z określonymi aplikacjami, jednakże pewności nie ma. Na pewno jedną z takich aplikacji jest Kadu 3.0, którego uruchomienie powoduje, że zapotrzebowanie na RAM przez plasmashell, ze startowego ok. 100MB, po 2-3 godzinach uruchomionej aplikacji rozrośnie się około 2,5-3 krotnie. Niestety samo zamknięcie aplikacji nie pomoże. Niezmiernie trudno też stwierdzić czy i co pozostało w pamięci, albowiem swój apetyt zwiększył jedynie podstawowy proces, czyli plasmashell.
Kolejna kwestia, jest już w niewielkim stopniu związana z samym środowiskiem, bądź nowym Qt5. Po zainstalowaniu ich, niektóre aplikacje przestają działać poprawnie. Ja spotkałem się z dwoma (lub trzema). Pierwszą z nich była QupZilla, która po instalacji Qt5.6RC bardzo często samoistnie zamykała się. Rozwiązaniem - nie do końca jeszcze prawidłowym - okazało się zbudowanie aplikacji w wersji głównej (master) z GIT. Tu jest dostępny kod przyszłej QupZilli 2.0, która oparta ma jest o qtwebengine w wersji co najmniej 5.6. Niestety samo qtwebengine 5.6 też dalekie od oryginału, a ze względu na to, że swoje źródło ma w blinku sprzed kilku miesięcy, to niektóre serwisy (np. gmail.com) sygnalizują, że przeglądarka jest zbyt stara (mała zmiana w stosunku do qtwebkita, który był uważany za jeszcze starszą przeglądarkę). Qupzilla-git działa w miarę sprawnie i przyjemnie, z jednym zastrzeżeniem - qtwebengine, to blink, a zatem w stosunku do qtwebkit większe zapotrzebowanie na RAM. Pozytywne informacje są trzy: nie zaobserwowałem wycieków pamięci, których doświadczałem w QupZilli do wydania 1.8.9 włącznie (nie zawsze, niemniej jednak bywały), więcej treści jest widocznych i... przede wszystkim, to przedpremierowe jeszcze wydanie działa.
Drugą aplikacją była Clementine w wersji zbudowanej na Qt5. Jeśli pamiętam, to również i ją musiałem przebudować na Qt5.6. Działa bez zarzutów, choć nie jest to jeszcze wydanie oficjalne.
Trzecią aplikacją jest KTP, czyli telepathy-kde. Używam, bo wygodne i zintegrowane ze środowiskiem. Niemniej jednak obecnie używać się nie da. Działa wszystko, tylko... okno rozmowy pozostaje w kolorze swego obramowania i po prostu go nie ma. W okresie testowania Qt5.6RC/Plasma 5.5.95 błąd ten pojawił się i zniknął. Niekiedy dopiero drugie, czy trzecie otwarcie okna powodowało, że okno rozmowy stawało się widoczne. Obecnie nic takiego się nie dzieje. Samo przepakowanie programu na Qt5.6/Plasma 5.6 nie dało nic. Podobnie jak budowa wersji 15.12.70 nic tu nie zmieniła. Nawet przebudowanie telepathy-kde-text-ui z użyciem patcha budującego je na qtwebengine (a nie jak do tej pory na qtwebkit) nie przyniosło spodziewanego efektu.
Niestety niektórzy mogą się spodziewać również długiego okresu wstawania Plasmy 5.6. Błąd prawdopodobnie tkwi w kded, a w zasadzie w samym Qt5.6 i jest obserwowalny co najmniej od Qt5.6RC. Teoretycznie istnieje zbiór patchy, które błąd ten mają naprawić, jednakże ze względu na niezbadaną jego naturę, jak na razie twórcy Qt nie zdecydowali się na ich włączenie do Qt. Nie zdecydowali się również opiekunowie Qt5 w Archu. Osobiście błąd ten niekiedy obserwuję. Nie jest zatem tak, by pojawiał się on przy każdym starcie środowiska. Kiedy znika ekran startowy pojawia się czarny ekran jedynie z kursorem. Niekiedy okazuje się, że proces plasmashell jest uruchomiony, ale jakby nie mógł wystartować. Przy okazji zużywa sporo zasobów CPU (ok. 100% jednego rdzenia). Innym razem w ogóle nawet plasmashell nie jest aktywowana. Co ciekawe, nie wydaje się to być właściwe wyłącznie dla Plasma 5.6/Qt5.6, albowiem i wcześniej niekiedy czegoś takiego doświadczałem. W okresie testowania poradziłem sobie przez kompilację kilku komponentów Plasmy w wersjach już planowanej Plasmy 5.6 (a nie 5.5.95) i co do zasady problem wydawał się zniknąć. Jeśli się z czymś takim spotkacie, to niekiedy prostackim rozwiązaniem okazuje się restart SDDM (ja akutat jego obecnie używam). Jest dość łatwe, albowiem najczęściej na owym czasnym ekranie dostępny jest np. krunner (Alt+F2) bądź możliwe jest przejście do trybu konsolowego (np. Alt+Ctrl+F2).
Jeśli ktoś doświadcza natomiast jakichś artefaktów na ekranie, to pomocnym może się okazać aktywacja DRI3 bądź użycie KWina w trybie OpenGL ES.
Reszta błędów związanych z wadliwym wyświetlaniem na niektórych układach Intela (nie mam takiego GPU) składana jest na karb wadliwych sterowników i rozwiązania są tu niezmienne od początku istnienia Plasmy. Zmiana metody akceleracji Xów na UXA winna pomóc, choć z lektury BBS Archa nie wynika, by za każdym razem okazywała się panaceum na te problemy.

Na koniec Plasma 5 i Wayland. No jest lepiej. Uruchomienie nie sypie już niesamowitą ilością błędów, jednakże w dalszym ciągu - przynajmniej na moim sprzęcie - używanie tego zestawu jest niemożliwe. Po pierwsze... czarny ekran, który znany jest również z sesji kwin_x11. Obecnie przynajmniej udaje się mimo to uruchomić krunnera i za jego pomocą wywołać np. konsole. Niestety obszar widoczny jest jedynie jakby częścią obszaru, który "widzi" KWin do spółki z Waylandem. Z testowania wersji Plasma 5 na Waylandzie pochodzącej z Neona wiem, że musi to być jakieś specyficzne ustawienie mojego systemu. Inna sprawa, że obraz testowy z Neona trudno zakwalifikować w kategoriach "używalny", a zatem Plasma 5 i Wayland - jak dla mnie - pozostają jeszcze melodią dalekiej przyszłości.

I to w zasadzie tyle, subiektywnego przeglądu Plasmy i Qt, obu w wersjach 5.6.

ERRATA:
Okazuje się, że za brak możliwości wyświetlania okna rozmowy w Telepathy KDE odpowiada wtyczka telepathy-hanging-git, która teoretycznie jest niezbędna do uruchomienia komunikacji zgodnej z protokołem Google Talk. Jest ona dostępna w AUR i od dawna się nie buduje, jednakże ci, którzy mają ją zainstalowaną uprzednio spotkają się właśnie z informacją o zbyt starych modułach, która głównie przejawia się w niewyświetlaniu okna rozmowy. Usunięcie tej paczki oraz biblioteki, na której jest oparta, czyli libhangish-git przywróci funkcjonalność Telepathy KDE. Mój błąd, że tego nie sprawdziłem, ale szczerze zapomniałem już o tym, że miałem ją zainstalowaną. Bez tej wtyczki (i biblioteki) Hangouts działają, zatem nic się nie traci.

poniedziałek, 21 marca 2016

KShutDown 3.99 Beta 1

KShutDown to małe, sympatyczne narzędzie graficzne dla środowiska KDE, które umożliwia m.in. wyłączenie komputera w określonym czasie. Wersja, która dostępna jest w Archu jest ostatnią wersją stabilną, czyli 3.2. Jest to wersja budowana z użyciem bibliotek KDE4 i przeznaczona dla tego środowiska. Od października ub.r. dostępna jest natomiast wersja oznaczona jako 3.99 Beta 1, która m.in. umożliwia jej zbudowanie w oparciu o KF5, a zatem będzie działać (i działa) w Plasma 5. Skoro nie istnieją skrypty w AUR umożliwiające budowę tej wersji, to poniżej podaję zawartość niezbędnych plików, umożliwiających budowę aplikacji. Istnieje również możliwość budowy tej aplikacji w oparciu wyłącznie o Qt5, a zatem będzie ona działać (bez zbędnego ciągnięcia za sobą bibliotek KF5) również np. w LXQT, czy innych środowiskach opartych o Qt5. Tej wersji jednak jeszcze nie budowałem.
PKGBUILD:
pkgname=kshutdown
pkgver=3.99beta
pkgrel=1
pkgdesc='Shutdown Utility for KDE'
arch=('i686' 'x86_64')
url='http://kshutdown.sourceforge.net/'
license=('GPL')
depends=('knotifyconfig' 'kidletime' 'hicolor-icon-theme')
makedepends=('cmake' 'gcc-libs' 'automoc4' 'xdg-utils')
install="$pkgname.install"
source=("http://downloads.sourceforge.net/$pkgname/$pkgname-source-$pkgver.zip")
sha256sums=('f73c5c6cec5ec4e427452ae190fda4a337d6290d7b15f32a33749f633fd822cc')

build() {
  mkdir build
  cd build
  cmake "../$pkgname-$pkgver" \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DKS_KF5=true
}

package() {
  make -C build DESTDIR="$pkgdir" install
}
kshutdown.install

post_install() {
  xdg-icon-resource forceupdate --theme hicolor &> /dev/null
}

post_upgrade() {
  post_install
}

post_remove() {
  post_install
}

Plasma 5. Część 2 - Pogromca mitów. Baloo.

Mit pierwszy: wyłącz baloo bo inaczej... No właśnie, w zasadzie nie wiadomo co inaczej. Przyjmuję, że lampa się z sufitu urwie skutkiem obciążenia systemu i samego komputera owym baloo.
Czym jest baloo? Programem indeksującym pliki, który umożliwia komponentom Plasmy i niektórym aplikacjom wyszukiwanie plików według różnych kryteriów. Między innymi po ich zawartości. Baloo jest zatem bezużyteczne dla wszystkich programów, które z niego nie korzystają. Nie tylko programów nie zbudowanych w oparciu o KF5, ale również i tych, w których funkcja ta podczas kompilowania została wyłączona. Wydaje się również, że nie będzie ono miało znaczenia we wszelkich programach, które wewnętrznie indeksują pliki mechanizmami wbudowanymi w ten program.
Można zatem w istocie wyłączyć baloo.
balooctl disable
W takiej sytuacji przydałoby się również przebudować programy wykorzystujące baloo, tak by z niego nie korzystały. Takimi są np. dolphin, czy gwenview. Takim  jest również plasma-desktop. Niegdyś w AUR istniały wersje "light" niektórych komponentów KDE, które budowały je właśnie jako wolne od zależności do baloo. Obecnie już ich nie ma. Pozostawiam to rozwiązanie zatem wyłącznie osobom, które dokładnie wiedzą jak to zrobić i przede wszystkim, którym chce się kilka razy w miesiącu bawić w kompilowanie ze źródeł kilku paczek. Same ocenić sobie muszą, czy to się opłaca.
Według mnie nie. Wolę zabrać się za okiełznanie baloo.
W istocie jego ustawienia, szczególnie przy pierwszym uruchomieniu środowiska, powodują, że praktycznie wszystko co chcemy na nim  wykonać ślamazarzy się okropnie. Zastanówmy się zatem, czy narzędziu temu nie można jakoś pomóc. Niestety graficzne narzędzia, ustawiające mechanizm indeksowania nie są bardzo rozbudowane i niewiele nam powiedzą o tym, co jest indeksowane.  Obecnie ustawieniami baloo możemy sterować wyłącznie na trzy sposoby:
  • za pomocą modułu KCM pod nazwą "Wyszukiwanie",
  • za pomocą konsolowego narzędzia balooctl,
  • ręcznie edytując jego pliki konfiguracyjne.
Nie istnieją narzędzia opisywane na wiki Archa jak kcm_baloo_advanced, czy baloo_file_cleaner (o tym jeszcze później). Pierwsze jest przeznaczone wyłącznie dla Baloo istniejącego w wersji przeznaczonej dla KDE4, drugie odeszło w mrokach dziejów, kiedy Baloo stało się frameworkiem, a nie aplikacją.
Zanim dokonamy jakichś zmian musimy się zastanowić co indeksuje Baloo i co chcemy by indeksował. Zanim się dowiemy jak to zrobić uświadomić musimy sobie, że jest to program, który działa w tle systemu w sposób ciągły. Oznacza to, że za każdym razem, gdy zostanie dokonana jakaś zmiana w katalogu i wobec plików, które ma śledzić, program zostanie aktywowany i przeprowadzona zostanie indeksacja. Oznacza to, że system będzie bardziej obciążony zawsze wówczas, gdy zmuszony zostanie do indeksowania katalogów o często zmieniającej się zawartości. Jeśli zatem ktoś z Was ma katalog, w którym buduje programy ze źródeł, to zobowiązanie Baloo do jego indeksowania jest według mnie czystą stratą zasobów komputera. Także te katalogi, z których zawartości korzystamy zwykle z użyciem innych programów, które czy to same mają własne narzędzia indeksujące (np. digikam, amarok), jest według mnie bez sensu. Każdy z Was jednak musi ocenić sobie sam co ma być indeksowane.
Zanim przejdę do narzędzi graficznych, kilka słów o konsolowych. Szybciej bowiem odpowiedzą nam na interesujące pytania.
Podstawowym jest oczywiście balooctl wraz ze opcjami. Dla nas interesujące będzie skorzystanie z:
balooctl config ls <ustawienie>
Polecenie to zwróci nam informacje o konkretnym ustawieniu programu indeksującego. Parametr <ustawienie> przybrać może jedną z następujących wartości:
  • hidden - dowiemy się, czy Baloo indeksuje ukryte pliki i katalogi,
  • contentIndexing - dowiemy się czy Baloo indeksuje zawartość plików (a nie tylko nazwy),
  • includeFolders - otrzymamy spis katalogów indeksowanych przez Baloo (będzie to katalog nadrzędny),
  • excludeFolders - otrzymamy spis katalogów, których Baloo nie indeksuje,
  • excludeFilters - Spis filtrów używanych do wykluczania plików
  • excludeMimetypes - Spis typów mime używanych do wykluczania plików  
Domyślne ustawienia są takie, że Baloo indeksuje wyłącznie katalog danego użytkownika, który uruchomił Plasmę. Nie indeksuje jednakże żadnego katalogu, ani pliku ukrytego. Także nie wszystkie kategorie plików są automatycznie indeksowane. Dla przykładu większość plików służących jedynie do pisania kodu, czy użytecznych w procesie kompilacji jest pomijanych. Niemniej jednak nie wszystkie.
Zanim zatem rozpoczniemy używanie środowiska z Baloo sensownie jest dokonać wykluczenia wszystkich plików i katalogów, których nie chcemy indeksować. Musimy również pamiętać o tym, że Plasma (tak jak niegdyś KDE4) jest bardzo wrażliwa na wadliwe ustawienia. Jeśli zatem kiedyś dodaliśmy jakiś katalog do listy wyszukiwania, a obecnie go nie mamy, to Baloo będzie próbowało znaleźć coś, czego nie ma. Nie muszę chyba mówić, że przełoży się to na znaczne zużycie zasobów.
Konfigurując Baloo (pomijam ręczną edycję plików konfiguracyjnych) mamy dwie możliwości: tekstową i graficzną. Ta ostatnia jednakże jest bardzo skromna. Jest ona dostępna w "Ustawieniach systemowych". Odnajdujemy tu "Przestrzeń robocza" i pod pozycją "Wyszukiwanie" znajdujemy ustawienia Baloo z dwoma zakładkami: "Wyszukiwarka Plasmy" oraz "Wyszukiwanie plików". Pierwszą odpowiada za definiowanie tych typów plików, które mają być indeksowane, druga oferuje wybór wyłącznie negatywny, czyli wyklucza z indeksowania te katalogi, których nie chcemy indeksować. Sami musimy rozstrzygnąć co chcemy indeksować, a czego nie. Podpowiedź znajdziecie powyżej. Osobiście nie indeksuję katalogu, w którym kompiluję różne programy. Nie ma to najmniejszego sensu, gdyż powstające tu pliki traktuję wyłącznie tymczasowo, a interesująca jest dla mnie paczka, która powstaje i jest instalowana w systemie. Nie indeksuję również katalogu, do którego pobierane domyślnie są materiały z zewnątrz. Najczęściej i tak lądują one w innym miejscu na dysku i zajmuję się tym bezpośrednio po pobraniu. Po co zatem to indeksować? Wyłączam również katalogi, które często zmieniam i które - zwykle - są indeksowane przez jakieś inne programy. Są to katalogi, w których umieszczam pliki z muzyką, czy filmami. Także pliki graficzne z katalogu Obrazy, ze względu na ich indeksowanie w programie do przeglądania zdjęć (np. DigiKam) są przeze mnie wyłączane z indeksacji. Gwenview używam raczej do podglądu obrazków ad hoc, zatem nie muszę mu udostępniać tego katalogu. Co innego, gdy pliki graficzne stanowią część mojej pracy i wówczas najczęściej umieszczane są w katalogu Dokumenty wraz z innymi materiałami, które są z nimi związane.
Powyższych zmian możemy również dokonać w konsoli, poprzez użycie:
balooctl config <odpowiednie_polecenie> <parametr>
Poleceniami są:

  • add - możemy dodać coś do indeksowania
  • rm lub remove - tu wyłączamy coś z ineksowania
  • set - w zasadzie występujące jedynie z hidden i służące do zmiany indeksowania plików i katalogów ukrytych
Parametrami pierwszych dwu poleceń są natomiast:

  •  includeFolders           Spis katalogów, które Baloo indeksuje                                                                 
  •  excludeFolders           Spis katalogów, których Baloo nigdy nie zaindeksuje                                                   
  •  excludeFilters           Spis filtrów używanych do wykluczania plików                                                          
  •  excludeMimetypes         Spis typów mime używanych do wykluczania plików 
Zanim dokonamy zmian, warto jest wstrzymać, bądź unieruchomić baloo:
balooctl suspend (wznawiamy przez balooctl start)
lub
balooctl disable  (wznawiamy przez balooctl enable && balooctl start, jeśli pierwsze polecenie nie wystartuje baloo)
Najlepiej jest opisane tu ustawienia dokonać jeszcze przed pierwszym startem środowiska, w konsoli. Jeśli jednakże ktoś już wystartował je, to sensownie jest wstrzymać baloo, usunąć pliki w ~/.local/share/baloo, następnie dokonać optymalizacji, uruchomić baloo i... odczekać chwilę, nie pracując w środowisku. Baloo dokona jego indeksacji w sposób, który nie jest mu utrudniany (wszak indeksowanie wciąż zmieniających się plików nigdy nie będzie łatwe dla jakiegokolwiek narzędzia).
W moim przypadku, zrealizowanie tych zaleceń powoduje, że baloo zużywa bardzo mało RAM i nie zaobserwowałem jeszcze, by zużyło w dający się zauważyć sposób zasobów CPU.

Co w QuickQit piszczy - Kooka

Pod hasłem "Co w QuickGit piszy" będę prezentował różne nowości, które pojawiają się w ramach prach nad szeroko pojętym środowiskiem graficznym oraz aplikacjami rozwijanymi pod auspicjami KDE. Serwis quickgit.kde.org jest takim właśnie miejscem, gdzie prosto i łatwo zebrane mamy różne źródła oprogramowania, które związane są z KDE. Na pierwszy rzut Kooka.
Pamiętacie taki programik? Kiedyś w czasach KDE3 stanowił on bodaj jedyne narzędzie umożliwiające skanowanie zbudowane specjalnie dla tego środowiska. Ba, oferował on coś znacznie więcej, albowiem zeskanowany obraz (bądź jakikolwiek, znajdujący się na dysku), można było poddać obróbce, w tym popularnemu w tamtych czasach OCR. W czasach KDE4/Qt4 nie cieszył się on popularnością. Wersja oparta o KDE3/Qt3 umarła gdzieś w mrokach dziejów, zaś nowa wersja, oparta o biblioteki KDE4 i Qt4 nigdy nie ukazała się w wersji umożliwiającej na niej pracę. Zamiast tego, KDE4 oferowało znacznie okrojone narzędzie umożliwiające skanowanie, jakim jest skanlite. OCR? Kto jeszcze pamięta ten sposób obróbki dokumentów tekstowych (głównie). Powierzchnia dyskowa stała się tańsza, pojawiły się chmury, jeśli zatem zachodzi konieczność przechowywania jakichś dokumentów to robimy to w formatach graficznych bądź pdf, djvu itp. Narzędzie OCR, które związane byłoby z KDE4 nie było oferowane. Wprawdzie istniał projekt Cuneiform-Qt4 dodawany do jakiejś rosyjskiej dystrybucji, ale dzisiaj nawet kodu próżno szukać. Istniały też dwie, niezależne od KDE nakładki graficzne na silniki OCR: YAGF i GImageReader. Żadne jednakże nie wykorzystywało mechanizmów KDE4 i ze środowiskiem tym dość słabo się integrowało. Przynajmniej wizualnie.
Zdziwiłem się zatem dość mocno, kiedy kilka miesięcy temu zauważyłem pośród projektów rozwijanych dla nowej już odsłony KDE, opartą o KF5, reanimowaną Kooka. Początkowo w ogóle nie nadawała się ona do użytku. Wraz z rewizją 1014 udało mi się jednak zbudować program, który uruchamia się i działa. 
Mamy tę samą funkcjonalność, którą oferowała Kooka w wersji dla KDE3. Program zatem pozwala nie tylko skanować, ale również przeprowadzać OCR, a także tworzy i kataloguje stworzone przez siebie dokumenty. Korzysta z trzech silników: gocr, ocrad oraz kadmos. Ten ostani jest komercyjnym, zamkniętym oprogramowaniem (o ile wiem) i nie jest dostępny w Archu. Pozostałe są. Niestety nie potrafi wykorzystać np. tesseract, który - jak się wydaje - najlepiej ze wszystkich silników OCR dostępnych dla linuksa potrafi rozpoznać polski język. Może z czasem się i to uda, zwałszcza, że jest on popularniejszy od pozostałych.
Poniżej PKGBUILD i plik *.install umożliwiający budowę tej aplikacji. Proszę wziąć pod uwagę, że nie jest to jeszcze wersja wydana. Jeśli jednak chcielibyśmy pomóc w jej rozwoju, choćby zgłaszając zaobserwowane błędy, to warto się chyba włączyć.
PKGBUILD
# Maintainer: pavbaranov

pkgname=kooka-frameworks-git
pkgver=r1014.0bea61e
pkgrel=1
pkgdesc="A Lite image scanning application. KF5 Frameworks branch (GIT version)"
arch=('i686' 'x86_64')
url="http://www.kde.org/applications/graphics/skanlite"
license=('GPL')
depends=('kdelibs4support' 'sane' 'hicolor-icon-theme' 'libpaper')
makedepends=('cmake' 'git' 'extra-cmake-modules' 'python' 'kdoctools')
optdepends=('ocrad' 'gocr')
conflicts=('kooka')
provides=('kooka')
source=('git://anongit.kde.org/kooka#branch=frameworks')
install=kooka.install
sha1sums=('SKIP')
_gitname="kooka"

pkgver() {
  cd "${_gitname}"
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

prepare() {
  rm -fr build
  mkdir -p build
}

build() { 
  cd build
  cmake ../kooka \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DLIB_INSTALL_DIR=lib \
    -DKDE_INSTALL_USE_QT_SYS_PATHS=ON
  make
}

package() {
  make -C build DESTDIR="${pkgdir}" install
}
kooka.install
post_install() {
xdg-icon-resource forceupdate --theme hicolor &> /dev/null
update-desktop-database -q
update-mime-database usr/share/mime &> /dev/null
}

post_upgrade() {
post_install
}

post_remove() {
post_install

piątek, 18 marca 2016

Plasma 5. Część 1 - Wstęp

Pomimo faktu, że Plasma 5 istnieje z nami już blisko 2 lata, to w dalszym ciągu jest - przynajmniej jeśli chodzi o dokumentację - tym gorszym krewnym KDE4. O ile w przypadku KDE4 znalezienie (i to nawet w początkowym okresie jego istnienia) odpowiednich porad było stosunkowo proste, tak w przypadku Plasma 5 stan ten jest bardzo odległy od doskonałego. Najczęściej próbujemy stosować pomysły, których nauczyliśmy się eksploatując KDE4 do nowego środowiska. Niekoniecznie musi się to udać. Istniejące dla Archa poradniki na wiki są natomiast swoistą mieszanką informacji o Plasma 5 oraz KDE4. Bezrefleksyjnie stosując się do nich szybko możemy sobie zniszczyć środowisko niż coś poprawić.
Postanowiłem zatem podzielić się z Wami kilkoma refleksjami z używania tego środowiska. Towarzyszy mi ono od początku grudnia 2014 i jakieś doświadczenia już zdążyłem zdobyć. Nie aspiruję jednakże do tego, że rozwiążę w tych poradnikach wszystkie problemy, z jakimi można się napotkać podczas pracy z Plasmą 5. Proszę pamiętać, że wiele kwestii związanych jest ze sprzętem, na którym mamy postawionego jakiegoś linuksa z tym środowiskiem. Osobiście od kilku lat pozostaję wierny prostym układom od AMD, stąd też dzielić się z Wami mogę wiedzą przede wszystkim dotyczącą takiego sprzętu.
Zanim przejdę do omawiania poszczególnych kwestii związanych z Plasmą, chciałbym napisać kilka słów o różnych "słabościach" tego środowiska, które są tu i ówdzie głoszone światu. Najczęściej przez osoby u których zawitało ono na bardzo krótko.
Jak każde środowisko, tak i Plasma 5 nie jest idealna. Można rzec - nie jest dla każdego. Przede wszystkim jej olbrzymia konfigurowalność - praktycznie niespotykana w innych środowiskach - zachęca do eksperymentów. Problem w tym, że łatwo w nich pobłądzić. Jeśli zatem jesteś świeżym użytkownikiem Plasmy 5, to najpierw na niej popracuj, a dopiero potem dostosuj ją do siebie.
Wokół tego środowiska narosło mnóstwo mitów. Te najbardziej popularne, to ogromna zasobożerność, włączenie do niej rozwiązań technicznych, które nikomu do niczego nie są potrzebne i należy je jak najszybciej wyłączyć (akonadi, baloo), albowiem w przeciwnym przypadku Plasma będzie zajmować się wyłącznie samą sobą niepozostawiając miejsca dla innych programów, konfiguracja jej jest koszmarem itd. itp.
Zanim postaram się przedstawić kilka sztuczek, które wydają mi się użyteczne, postaram się powalczyć z mitami Plasmy. To w następnym tekście.

środa, 2 marca 2016

Otter-Browser wydanie tygodniowe #113

Ukazało się właśnie 113 wydanie tygodniowe Otter-Browser. Z rzeczy istotnych dla budujących paczkę w Archu, Manjaro i pochodnych, najważniejsza jest taka, że wersja działająca w oparciu o QtWebEngine musi zostać zbudowana na Qt5.6. Tak zbudowana aplikacja nie wymaga też QtWebKit. Do dzisiaj nie została wydana stabilna wersja Qt5.6 (winna zostać upubliczniona jutro). W repozytorium kde-unstable Archa jest od kilku dni dostępne Qt5.6RC1, jednakże jego instalacja wraz ze środowiskiem Plasma 5 pochodzącym z repozytoriów Archa powoduje, że środowisko to staje się absolutnie niestabilne i generalnie są problemy z jego uruchomieniem. Istnieje prawdopodobieństwo, że także LXQT ma takie same problemy. Dopóki zatem Qt5.6 nie pojawi się w repozytoriach (choćby testowych) Archa, PKGBUILD będzie umożliwiał stworzenie wyłącznie paczki opartej o QtWebKit.
PKGBUILD:
# Maintainer: boenki <boenki at gmx dot de>
# Maintainer: pavbaranov
# Contributor: sir_lucjan

pkgname=otter-browser-weekly
_pkgname=otter-browser
_pkgver=0.9.10
_weekver=113
pkgver=${_pkgver}.dev${_weekver}
_devver=${_pkgver}-dev${_weekver}
pkgrel=1
pkgdesc="Web browser controlled by user, not vice-versa"
arch=('i686' 'x86_64')
url="http://$_pkgname.org"
license=('GPL3')
depends=('qt5-webengine' 'qt5-multimedia' 'hicolor-icon-theme' 'desktop-file-utils' 'qt5-webkit' 'qt5-script')
makedepends=('cmake' 'qt5-tools')
optdepends=('gstreamer0.10-ugly-plugins' 'hunspell')
conflicts=('otter-browser-git' 'otter-browser' 'otter-browser*' 'otter-browser-beta*' 'otter-browser-webengine-weekly' 'otter-browser-webkit-weekly')
install=otter.install
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2")
md5sums=('505e25025112e3246d526e2e7f5c2a1e')

build() {
  cd ${_pkgname}-${_devver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr" 
# -DEnableQtwebengine=ON
  make
}

package() {
  cd ${_pkgname}-${_devver}
  make DESTDIR=$pkgdir install
}
Jeśli jednak ktoś z Was chciałby zrobić paczkę w oparciu o Qt5.6RC1, to musi po pierwsze uruchomić repozytoria testing oraz kde-unstable oraz znieść znak # sprzed linii -DEnableQtwebengine=ON w PKGBUILDzie. Ma to sens wyłącznie wówczas jeśli Wasze środowisko nie jest oparte o Qt5 i - prawdopodobnie - nie używacie również aplikacji opartych o Qt5.
 

Testowy obraz Plasma 5 działający na Waylandzie

Od jakiegoś czasu Wayland budzi emocje. Już nie pamiętam ile lat zapowiadany jest jako następca Xów w linuksie. Wciąż się nie może zadomowić i chyba nie uczyni tego w najbliższym czasie, choć plany ze strony Fedory są w tym zakresie, hmm... imponujące. Za taki stan rzeczy prawdopodobnie odpowiada fakt, że stosunkowo jeszcze niewiele środowisk działa pod Waylandem. Mamy dwa (przynajmniej mi znane) środowiska, budowane wyłącznie dla Waylanda, które teoretycznie winny dawać się uruchomić, czyli Hawaii oraz Papyros. Niestety nie są one jeszcze wystarczająco dojrzałe do codziennej pracy. W porównaniu z rozwijanymi od lat środowiskami, jak Gnome (różnych wersji), czy KDE (również różnych wersji), brakuje im sporo narzędzi, które korzystanie ze środowiska czynią bardziej komfortowym. Bardzo też różnie bywa ze stabilnością. Mamy też trzy, a w zasadzie trzy i pół środowiska, które teoretycznie winny dawać się uruchomić także pod Waylandem. Są to Gnome 3, Enlightenment (bodaj od wersji 19) oraz Plasma 5. Owa połówka to LXQT o ile działa z KWinem jako menedżerem okien. Nie testowałem Gnome 3, ale uruchomienie Plasmy 5 w sesji Waylanda to absolutna loteria, kończąca się najczęściej wysypem olbrzymiej ilości o błędach. Enlightenment (fakt wersja 19) niby udało mi się uruchomić, ale stabilność działania była żadna. Nie próbowałem  LXQT bowiem jego sesja Waylanda jest pochodną KF5, wyszedłem zatem - być może z niesłusznego - założenia, że skoro Plasma nie działa, to i LXQT również. Oprócz wyżej wymienionych są jeszcze różne menedżery okien, ale korzystanie z nich również nie należy do przyjemności. Pozostaje domyślny kompozytor Weston. Czy jednak praca w nim jest wygodna? Mam tu pewne zastrzeżenia. Być może dla osób przyzwyczajonych do różnego rodzaju *BOX.
A jednak Wayland kusi i nęci. Choćby by zobaczyć go w praktycznym działaniu.
Po tym długim wstępie, czas na krótką informację. Znany z Kubuntu, a obecnie z projektu Neon, Jonathan Riddell udostępnił właśnie obraz ISO systemu opartego o Plasma 5, który natywnie działa w sesji Waylanda. Jak przystało na Riddella, obraz jest oparty o rozwiązania pochodne od systemów z Canonicalem w tle, czyli Ubuntu, Kubuntu i Neon, do których został dołączony KWin zbudowany bezpośrednio ze źródeł z GIT. Uruchomienie wymaga podania użytkownika systemu, którym jest ubuntu, hasło dla niego jest puste.

wtorek, 1 marca 2016

Poprawiamy wygląd LibreOffice

Wygląd LibreOffice jest - jaki jest. Jednym się podoba, innym nie. Nie chodzi mi w tym momencie o ogólnie przyjęty interfejs tego pakietu, a wyłącznie o dostosowanie go do środowiska, w którym jest uruchamiany.
Prawdopodobnie mało kto pamięta, że LibreOffice daje cztery możliwości ustawień, które powodować mają upodobnienie się wyglądu do środowiska, w którym przyszło mu pracować. Odpowiada za to parametr SAL_USE_VCLPLUGIN. Obecnie dostępne są następujące ustawienia:

  • gen - można powiedzieć "wygląd źródłowy", bez upodabniania się do czegokolwiek - jest on nieco podobny do aplikacji pisanych w java,
  • gtk - to wygląd, który ma upodabniać interfejs do środowisk opartych na Gtk+ 2.x,
  • gtk3 - wygląd upodobniający interfejs do środowisk opartych o Gtk+ 3.x,
  • kde4 - wygląd upodobniający interfejs do środowiska KDE4, a szerzej - opartych o Qt4 i prawdopodobnie Qt5.
Niektóre dystrybucje próbują ów wygląd predefiniować. Tak jest również, gdy pobierzemy paczki deb, czy rpm bezpośrednio ze strony projektu, w których parametr powyższy ustawiony jest na gtk. W innych dystrybucjach, takich jak choćby Arch Linux pozostawiono to użytkownikowi i poniekąd samemu programowi. Jeśli bowiem nie zostanie ustawiony żaden parametr, to program sam próbuje zidentyfikować środowisko i przybrać najbardziej odpowiedni dla niego wygląd. 
Niestety ustawienia - szczególnie w przypadku używania Plasma 5 (i prawdopodobnie również LXQT) - są dość dalekie od, przynajmniej mojego, poczucia estetyki. Możemy zatem spróbować coś zmienić.
Proponuję najpierw uruchomienie testowo jakiejś aplikacji, która wchodzi w skład pakietu. W poniższych przykładach będzie to Writer (lowriter). Mechanizm jest prosty, wydajemy w konsoli polecenie:
SAL_USE_VCLPLUGIN=<nazwa> lowriter
I sprawdzamy jak nam się teraz podoba wystrój programu. W miejscu <nazwa> wpisujemy jedną z przytoczonych wyżej możliwości: gen, gtk, gtk3, kde4.
Jeśli któryś z wystrojów podoba nam się bardziej, możemy dokonać na stałe wprowadzenia go jako parametru uruchamiania LibreOffice. Możliwości jest kilka.

W przypadku, gdy w systemie mamy jedno środowisko, wówczas warto jest zmienić wpis w /etc/profile.d/libreoffice-<wersja>.sh/csh. Owe <wersja> to albo fresh, gdy używamy najnowszych wydań LibreOffice, bądź still, gdy używamy bardziej stabilnych wersji. Obecnie fresh to seria 5.x, a still 4.x. Plik ten składa się z czterech ustawień, zwykle poprzedzonych znakiem #, które mają postać:
# to force a certain look'n feel
#export SAL_USE_VCLPLUGIN=gen 
#export SAL_USE_VCLPLUGIN=kde4 
#export SAL_USE_VCLPLUGIN=gtk 
#export SAL_USE_VCLPLUGIN=gtk3
 W celu ustawienia tego, który nas interesuje usuwamy znak # sprzed odpowiedniej linii. Ustawienie w tym miejscu wyglądu LibreOffice funkcjonuje w całym systemie, dla wszystkich środowisk i wszystkich użytkowników.

Jeśli w systemie mamy więcej środowisk lub też pracuje na nim kilka osób o odmiennych upodobaniach, możemy dokonać podobnego ustawienia w pliku konfigurującym powłokę dla danego użytkownika. W moim przypadku jest to bash, zatem plik konfiguracyjny to ~/.bashrc. W pliku tym dodajemy linijkę:
export SAL_USE_VCLPLUGIN=<nazwa>
gdzie <nazwa> to oczywiście wybrane przez nas ustawienie. Nowy wygląd będzie dostępny już po wydaniu polecenia:
source ~/.bashrc
i będzie on dostępny wyłącznie dla użytkownika, który dokonał zmian, ale dla wszystkich środowisk, jakich używa.

Jeśli używamy kilku środowisk, to najrozsądniejsze wydaje się napisanie skryptów, które będą uruchamiane wraz ze startem systemu. Dla basha przyjmie on postać:
#!/bin/bash
export SAL_USE_VCLPLUGIN=<nazwa>
gdzie znów nazwa, to wybrany przez nas parametr zmiennej środowiskowej. Taki plik zapisujemy pod dowolną nazwą i nadajemy mu uprawnienia wykonywalne, choćby za pomocą chmod i umieszczamy taki plik w katalogu, który odpowiada za autostart wraz z danym środowiskiem. W przypadku Plasma 5 oraz nazwy nadanej plikowi jako lo-plasma.sh będzie to:
chmod +x ~/.config/plasma-workspace/env/lo-plasma.sh
Plik bowiem musimy umieścić w ~/.config/plasma-workspace/env.