Udzielone Odpowiedzi
- Posty
Zanim uruchomisz ręcznie sieć wykonaj:
systemctl status NetworkManager
Sprawdź, czy masz w liniach „Loaded:’ wpisane, (m.in.) loaded cośtam oraz przede wszystkim, czy w linii „Active:” jest wpisane: active (running).
Swoją drogą, to ciekaw jestem dlaczego w Manjaro LXQT ożenili je z NetworkManager. Skoro to ma być „lekki” system, to powien być tam connman – zdecydowanie lżejsze rozwiązanie od NM i częściej spotykane w „lekkich” systemach.Czcionki i w przypadku Google Earth bodaj te z „java”. Może będzie lepiej. Oczywiście chodzi mi o natywną wersję, a nie żadne wine.
Po diabła instalujesz Google Earth przez wine? To się musi skończyć porażką (choć i taka wersja niby istnieje). W AUR masz google-earth (to jest wersja 7) oraz google-earth6 (wersja 6).
Jeśli tylko nie zachodzi absolutna potrzeba używania programu windowsowego przez wine, a już na pewno, gdy są natywne, linuksowe wersje, to z daleka od „aplikacja windows”+wine.
PS. Załóż wątek, to postaramy się odinstalować to nieszczęsne Earth.
PS2: Oprócz Discover, o którym wspomniał aquila, masz co najmniej 2 wygodne (tj. z GUI) menedżery oprogramowania w Manjaro. W wersjach opartych o Qt jest Octopi, w wersjach innych jest Pamac.
PS3: Cóż, niestety opisy programów w Archu i pochodnych są zawsze po angielsku.Hmm… a coś takiego: podnoszenie NetworkManager wykonałeś?
To powinno startować automatycznie przy starcie systemu i łączyć się ze zdefiniowaną siecią, jeśli ją znajdzie. Jedynie nową sieć musisz wówczas dodać. Sprawdź czy NM jest podniesiony jeszcze przed połączeniem z wykorzystaniem apletu, nmtui, czy czegokolwiek innego.Hmmm…. nawet zainstalowałem tego LXQT, ale i tak nie mam w Archu takiego apletu jak masz Ty w Manjaro. Spróbuję Ci zatem podać obejście. Może się uda.
Znów nmtui. Rozumiem, że połączenie masz już zdefiniowane, a zatem wybierasz Modyfikuj, na następnej karcie wybierasz swoje połączenie spośród widocznych jako WiFi, ponownie Modyfikuj i na ekranie, który Ci się zaznacz „Łączenie automatyczne” (nie pamiętam, ale to może wymagać uprawnień roota). Po dokonaniu tego wyboru sieć wifi tak zdefiniowana winna Ci się podnosić jeszcze przed startem środowiska.Nie distro niedopracowane, tylko – ewentualnie – nieskonfigurowane przez Ciebie.
Inna sprawa, że ilekroć próbowałem się z LXQT, tylekroć wylatywało bo czegoś nie dawało się skonfigurować tak, jakbym chciał. To jednak wciąż bardzo wczesna jeszcze wersja tego środowiska (0.10).Powinieneś tam mieć (Manjaro LXQT) networkmanager. W takiej sytuacji, pierwszą konfigurację zwykle robię przez konsolowe nmtui (to jest semigraficzny program do konfiguracji nm – bardzo prosty w użyciu). Może Ci jakoś to pomoże.
Raczej nie sterowniki, skoro w innej wersji jest karta wykrywana. Jeśli masz inxi, to łatwo sprawdzisz przez:
inxi -NnCóż, używałem Manjaro przez pewien czas stąd też dokładnie wiem, jakie są różnice. Te zasadnicze – w przypadku KDE – to:
– własne motywy graficzne,
– własne ustawienia w /etc/xdg,
– brak osoby, która ogarnia KDE.
Plasma 5 jest jeszcze bardziej wrażliwa na wadliwe tematy niż KDE4. Wadliwe tematy i ustawienia w /etc/xdg powodują wadliwą pracę Plasmy. Stąd m.in. bywają w Manjaro błędy, które nie występują tam, gdzie nie zostały one wprowadzone.
Zasadnicza jednakże różnica to jedna osoba: arojas. Sorry, ale w całym Manjaro nie ma ani jednej osoby, która ogarnia paczkowanie Plasmy. Praktycznie 100% paczek jest tych samych, które są w Archu. Niestety okres mrożenia paczek w testing nic im nie pomaga, bo nic z nimi nie jest robione. Testing w Manjaro zatem – w przypadku paczek Plasmy – nie daje nic.
Przy okazji – świetna Plasma jest również w KaOSie, ale to bardzo hardcore’owa dystrybucja.
No i zrobił się offtop :)Dokładnie, to instalacja dowolnego programu pociągnie te zależności, jakie ów program zawiera. Jeśli będzie to jakaś aplikacja składająca się na KDE Applications, to pociągnie za sobą jakieś zależności. W przypadku nowych aplikacji (tj. opartych na KF5) pociągnie te elementy frameworks, które przez paczkującego określone zostały jako jego zależności. W przypadku starych aplikacji (tj. tych, które należą jeszcze do KDE4) pociągnie najprawdopodobniej kdebase-lib i kdebase-runtime (oraz inne, które zostały przez paczkującego określone jako jego zależności). Podobnie z każdym, dowolnym programem, opartym na dowolnych zależnościach.
LXQT nie ma swojego menedżera okien. Jeśli się zdecydujesz na KWin to pociągnie to praktycznie całe KF5. Wówczas następne aplikacje oparte o KF5 nie będą prawie niczego już dociągać.
Samo LXQT również jest obecnie oparte (w części) na KF5, zatem i ono samo pociągnie ze sobą część frameworks.
Zawsze możesz próbować używać aplikacji opartych wyłącznie na Qt5. Niektóre aplikacje są budowane jako oparte o KF5 lub o samo Qt5. Te ostatnie nie pociągną żadnego elementu KDE.Inna sprawa, że jak pisze napcok – Plasma 5 daje się skonfigurować tak, że korzysta z zasobów komputera na poziomie bardzo zbliżonym do LXQT. Daje natomiast większą konfigurowalność i jest zdecydowanie pewniejsza jeśli chodzi o rozwój (po prostu zdecydowanie więcej osób pracuje nad KDE).
Dokładnie, to wersja z AUR nie odpowiada 0.86 Beta1 (gdyby ktoś chciał dokładnie tę wersję, to niech zgłosi – nie ma problemu z przygotowaniem PKGBUILDu bądź poinstruowaniem co należy zmienić w obecnym), a po prostu „master” z GITa. PKGBUILD zawiera kilka błędów oraz skrypty winny zostać uzupełnione o *.install.
Wg mnie (przynajmniej namcap tak twierdzi), pole depends winno wyglądać tak:
depends=('qt5-base' 'desktop-file-utils' 'mesa' 'hicolor-icon-theme')
Nadto winna zostać dodana pozycja:
install=$pkgname.install
a ów tajemniczy plik musi wówczas mieć nazwę: qtdirstat-git.install i następującą zawartość:post_install() { update-desktop-database -q gtk-update-icon-cache -q -t -f usr/share/icons/hicolor } post_upgrade() { post_install $1 } post_remove() { post_install $1 }Jeśli ktoś nie ma qtk-update-icon-cache w systemie, to może użyć xdg-icon-resource, które jest w xdg-utils.
Oczywiście nie uzurpuję sobie jeszcze prawa twierdzić, że tak zmienione skrypty na 100% są prawidłowe, jednakże przechodzą testy namcapa z wyjątkiem informacji, że biblioteka /usr/lib/libGL.so.1 nie jest używana przez qdirstat. Z drugiej strony zlikwidowanie zależności do mesa z pola depends również powoduje informację, że nie użyto takiej zależności w PKGBUILD, a jest ona wykorzystywana przez program. IMO – lepiej pozostawić jako zależność.Zrób jeszcze próbę startując którąkolwiek z przeglądarek w trybie prywatnym i/lub bez dodatków. Mi QupZilla się dzisiaj wywaliła na manjaro.pl gdy tylko spróbowałem uruchomić filmik z zapowiedzią Manjaro 15.12. Najpierw pokazało się szare okienko zamiast filmu i informacja o tym, że wystąpił błąd, potem przeglądarka zamroziła się na jakiś czas i wywaliła kompletnie.
Start z opcjami -ne -pb oraz -ne lub -pb (choć przeglądarka uruchamiana „normalnie” nie zgłasza żadnych dodatków) powodował, że wszystko pracowało poprawnie. Co ciekawe, teraz pracuje normalnie „w zwykłym trybie”.
Natomiast fakt – w qtwebkit jest coś skopane. Ponoć pojawili się jacyś chętni do reanimowania projektu, może zatem w końcu zostanie on doprowadzony do używalności. W sumie, to dobrze byłoby, gdyby chociaż jeden (qtwebkit bądź qtwebengine) silnik stał się używalny.Samo wejście na manjaro.pl – udaje się bez problemu. Wywala się na stronach, gdzie jest jakikolwiek filmik w flv. To jest jednak „dostępne” na wszystkich znanych mi przeglądarkach, które obsługiwane są przez silniki zbudowane na qt5 (niezależnie webkit, czy webengine). Niekiedy pomaga zmiana user agenta i wówczas już zaczyna być ok. Przynajmniej np. w QupZilli zmiana na… Operę 9.80 umożliwiła oglądanie flv. Na Mozilla 24 wywala się, na Chrome 24 – nie chce filmów odtwarzać :) (do wypróbowania zostało jeszcze Safari 6.0.6).
Za silnik odpowiada ten wpis w CMakeLists.txt:if (EnableQtwebengine) add_definitions(-DOTTER_ENABLE_QTWEBENGINE) set(otter_src ${otter_src} src/modules/backends/web/qtwebengine/QtWebEnginePage.cpp src/modules/backends/web/qtwebengine/QtWebEngineWebBackend.cpp src/modules/backends/web/qtwebengine/QtWebEngineWebWidget.cpp ) qt5_add_resources(otter_res src/modules/backends/web/qtwebengine/QtWebEngineResources.qrc ) endif (EnableQtwebengine) if (EnableQtwebkit) add_definitions(-DOTTER_ENABLE_QTWEBKIT) set(otter_src ${otter_src} src/modules/backends/web/qtwebkit/QtWebKitFtpListingNetworkReply.cpp src/modules/backends/web/qtwebkit/QtWebKitHistoryInterface.cpp src/modules/backends/web/qtwebkit/QtWebKitInspector.cpp src/modules/backends/web/qtwebkit/QtWebKitNetworkManager.cpp src/modules/backends/web/qtwebkit/QtWebKitPage.cpp src/modules/backends/web/qtwebkit/QtWebKitPluginFactory.cpp src/modules/backends/web/qtwebkit/QtWebKitPluginWidget.cpp src/modules/backends/web/qtwebkit/QtWebKitWebBackend.cpp src/modules/backends/web/qtwebkit/QtWebKitWebWidget.cpp src/modules/backends/web/qtwebkit/3rdparty/qtftp/qftp.cpp src/modules/backends/web/qtwebkit/3rdparty/qtftp/qurlinfo.cpp ) qt5_add_resources(otter_res src/modules/backends/web/qtwebkit/QtWebKitResources.qrc ) endif (EnableQtwebkit)zatem wyglądałoby tak, że w zależności od dokonanego wyboru albo buduje z modułami dla qtwebkit albo dla qtwebengine. Natomiast nawet gdy budujesz wersję z qtwebengine, to z jakiegoś powodu część kodu jest zaczerpywane z qtwebkit. Jak zbudujesz z zależnością wyłącznie do qt5-webengine i przeanalizujesz powstałą paczkę namcapem, to drze się, że qtwebkit został wykorzystany do budowy paczki, ale nie jest wpisany w zależnościach.
Z drugiej strony w Otterze zbudowanym na dzisiejszym PKGBUILDzie (bez zmian) możesz łatwo przełączyć silnik i przeglądarka zgłasza się właśnie z nim. Czy jest to wyłącznie „zewnętrzny” objaw działania, a w istocie dalej działa na qtwebengine – nie wiem (ja nie jestem programistą, ba nawet podstawowej informatyki w szkole nie miałem :)).
Emdek jest otwarty na wszelkie zgłoszenia błędów. O wielu wiedzą, ale czasu nie starcza, by to wszystko naprawiać (jak być może zauważyłeś bardzo mocno wydłużył się czas oczekiwania na wersję finalną). Szkoda, bo przy absolutnej stagnacji w Rekonq, dość archaicznym i co tu dużo mówić po prostu źle często działającym Konquerorze, chimerycznej Qupzilli z bardzo starymi już user agentami, które powodują że wiele stron nie jest w ogóle odtwarzanych – Otter mógłby się stać przeglądarką, która przynajmniej w środowiskach opartych o Qt5 mogłaby mieć duże znaczenie. A tak, to najlepsze przeglądarki dla środowisk opartych o Qt są oparte o Gtk :)
