Przejdź do głównej zawartości

Posty

Firefox 64 i okna KDE

Użytkownicy KDE od dosyć dawna narzekają na to, że aplikacje oparte o Gtk mają własne okna dialogowe. Mniejsza o to, które są "lepsze", a które "gorsze". To kwestia pewnych przyzwyczajeń. Jeśli 99% aplikacji zachowuje się w określony sposób, to ciężko przestawia się na inne zachowanie pozostałego procenta aplikacji. Zwłaszcza, że są to często wykonywane operacje, które "wchodzą" użytkownikowi w krew.
Śpieszę zatem donieść, że przynajmniej Firefox w wersji 64 da się zmusić do używania natywnych okien KDE przy otwieraniu plików, czy też zapisywaniu pobieranych przez tę przeglądarkę treści. Ponoć prezentowana tu sztuczka działa również z niektórymi programami. Ponoć również, niektórym nie działa w ogóle (tu mam jednak wątpliwości, czy zostały spełnione wszystkie elementy, które umożliwiają takie zachowanie Firefox w Plasma).

Wpierw musimy odpowiednio przygotować nasz system, w którym muszą być zainstalowane następujące paczki:

firefox >=64.0xdg-desktop-por…
Najnowsze posty

POLAUR - paczki KDE z łatkami

Od dłuższego czasu w POLAUR, w repozytorium repo-refreshed umieszczam PKGBUILDy dla różnych składników oprogramowania pochodzącego od KDE z tzw. bugfiksami. W największej części są to te, które były zgłaszane w bugs.kde.org.
Stosowane są przeze mnie (i jeśli ktoś chciałby również się dołączyć, to również prosiłbym o ich stosowanie) następujące zasady: 1. Numeracja paczek
a. Paczki zawsze mają numer wersji (pkgver) takie jak paczka źródłowa, na którą patch jest nakładany.
b. Paczki różnią się wersją "realizacji" (pkgrel), przy czym numer ten jest zawsze wyższy niż wersja w repozytorium, ale zawsze też niższy od wersji, która w repozytorium może się pojawić (np. wskutek koniecznego jej przebudowania ze względu na zmiany innych elementów, tego wymagających). Kolejne wersje z patchami mają zawsze nowy numer pkgrel z zachowaniem powyższej zasady.
Przykład: jeśli paczka w repozytorium Archa ma numer np. 5.53.0-1, to pierwszy PKGBUILD z patchem będzie miał wersję 5.53.0-1.1, następny 5.…

Na prostej drodze do wysypania Manjaro

Do napisania dzisiejszego wpisu zainspirował mnie jeden z wątków na forum manjaro.pl. Otóż jeden z użytkowników Manjaro chciał zainstalować spotify, którego PKGBUILD dostępny jest w AUR. Akurat ta paczka powstaje przez przebudowanie udostępnianej przez Spotify paczki deb na paczkę Archa. Niestety od pewnego czasu spotify z udostępnionego PKGBUILDu gdyż wersja to 1.0.92.x, która nie jest już dłużej udostępniana przez Spotify. Obecnie udostępniane są 3 paczki, przy czym dla wspieranej architektury w Archu to wyłącznie 1.0.80.x oraz najnowsza 1.0.94.x. Instalacja zatem z takiego PKGBUILDu nie ma najmniejszych szans powodzenia.
Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma.
Inny forumowicz poleca zatem... dodanie repozytorium nexus do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify.
Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wniosku, ż…

A jak alias

Wielu użytkowników linuksa narzeka na straszliwą konieczność pracy w konsoli. Na to, że wszystko tu trzeba wpisywać itd. itp. i bez tego ani rusz, a polecenia konsolowe to katorga dla "normalnego" człowieka. I kto by spamiętał to wszystko.
Pomijam prawdziwość twierdzenia o konieczności wpisywania wszystkiego w konsoli. Obecne środowiska graficzne i programy dla nich, oferują spore możliwości praktycznie kompletnego pominięcia używania poleceń konsolowych. Niemniej jednak z różnych przyczyn może okazać się, że korzystanie z konsoli dla określonych zastosowań jest albo jedyną możliwością, albo po prostu bywa wygodniejsze.

Niemniej jednak sam zauważam, że niektóre polecenia są zbyt długie, by je spamiętać. Ot, choćby:
# reflector --verbose --country 'Poland' -l 5 -p http --sort rate --save /etc/pacman.d/mirrorlist Oszczędźmy naszą pamięć. Z pomocą przychodzi nam "alias", dzięki któremu w swoim środowisku możemy przyporządkować w zasadzie dowolne ciągi znaków p…

Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekaz…

Jak uniknąć problemów z Antergosem

Przyglądając się problemom, jakie dostarcza Antergos wielu użytkownikom od kilku lat, spróbuję zestawić w punktach kilka porad, które zminimalizują najczęściej występujące z nim kłopoty.

1. Usunięcie plików *-meta.
Niemal wszystkie instalacje (pierwsze) Antergosa odbywają się z użyciem tzw. meta paczek. To jeden ze sposobów instalacji zespołu większej ilości programów w Archu. Meta paczki nie zawierają żadnych binarek. Są to jedynie paczki niosące informacje o tym, że jakieś paczki mają zostać w systemie zainstalowane. Treść PKGBUILDów takich paczek zawiera w polu depends listę paczek do zainstalowania. Taka instalacja powoduje, że późniejsza próba odinstalowania jednej z paczek umieszczonych w depends pociągnąć za sobą może chęć odinstalowania "połowy" systemu, albo spotkamy się z informacją o tym, że odinstalowanie czegoś nie jest możliwe.

Rozwiązanie
Po zainstalowaniu Antergosa, przeszukujemy system pod kątem zainstalowanych paczek z "meta" w nazwie. Ich nazwy wyglą…

Przyciski OK i Anuluj aplikacji Gtk jak w Qt

Przyciski potwierdzenia lub wycofania się z jakiejś operacji (OK/Anuluj) w oknach dialogowych aplikacji zbudowanych w oparciu o Gtk są zamienione miejscami w stosunku do standardowych okien w środowiskach korzystających z Qt. Oprócz pewnego dyskomfortu, kwestii estetyki, przede wszystkim skutkuje to gorszą organizacją pracy. Na całe szczęście można to w prosty sposób zmienić.
Jeśli korzystamy z aplikacji zbudowanych na Gtk+2.x musimy dokonać edycji pliku ~/.gtkrc-2.0, jeśli korzystamy z aplikacji zbudowanych na Gtk+3.x edytujemy plik ~/.config/gtk-3.0/settings.ini, w obu przypadkach dodając linię: gtk-alternative-button-order = 1. To powinno wystarczyć, by we wszystkich aplikacjach wykorzystywanych w środowiskach zbudowanych na Qt (np. Plasma, LXQt, Lumina) miejsca przycisków OK oraz Anuluj były w tych samych miejscach.

Na podstawie porady z BBS Arch Linux.