Plasma 5.7 i Qt 5.7 w Archu i co z tego wynika
Po dwu tygodniach testowania Plasma 5.7 Beta (5.6.95) (można się było z nią zapoznać z kde-unstable), dwa dni temu pojawiło się jej stabilne wydanie, które trafiło do repozytorium testing. Pewnie gdzie indziej przeczytacie sporo o nowościach środowiska, ale... osobiście uważam, że wystarczająca jest wizyta na stronie kde oraz przeglądnięcie erraty. Podzielę się zatem z Wami wrażeniami z korzystania z Plasmy w tej wersji. Od razu mówię - moja wersja jej wyglądu nie jest dostarczana ze środowiskiem. Dotychczasowe doświadczenia z Plasmą 5 wskazują na dość znaczne jej "przywiązanie" do tematu Breeze, którego używanie w istocie sprawia, że działa ona lepiej niż z różnymi tematami, motywami, a nawet zestawami ikon, które dostępne są w zarówno w repozytoriach różnych dystrybucji, w AUR, jak i na kde-look.org. Nie mówię już o próbach użycia tematów z KDE4, które wcześniej czy później skończy się pokazową wywrotką środowiska (w najgorszym przypadku), a na co dzień powoduje błędy, których gdzie indziej nie ma. Niestety nie ustrzeżemy się od nich, albowiem - niestety - wiele tematów udostępnianych przez swoich twórców jest deklarowanych jako zgodne z Plasma 5, podczas, gdy w istocie są one nadal skonstruowane dla KDE4. Jeśli zatem środowisko zachowuje się wadliwie, to w przypadku używania niestandardowych ustawień, tematów itp, jednej z pierwszych przyczyn należy poszukiwać właśnie tutaj.
Czego się zatem można spodziewać, oprócz tego o czym szeroko jest i będzie mowa? Pierwsze, co się narzuca, to brak możliwości korzystania z innego menedżera okien niż KWin. Niegdyś taka funkcjonalność została wprowadzona w KDE4, a wcześniej jeszcze - choć nie w tak prosty sposób - można było korzystać z niej nawet w KDE 3. Obecnie - bodaj ponownie mój ulubiony deweloper KDE - stwierdził, że nikt z tego nie korzysta, ludzi do rozwijania, czy nawet utrzymywania rozwiązania brak, a zatem i ta funkcjonalność została wyłącznona. Nie tylko próżno szukać zatem takich ustawień w systemsettings, ale nawet, gdy mamy zainstalowanego OpenBox obok Plasmy, nie będziemy mogli z rozwiązania KDE/OpenBox, jakie dostarczane jest wraz z paczką openbox skorzystać. Tzn. środowisko się uruchomi, jednakże cały panel będzie kompletnie nieużywalny.
Czy rozwiązanie w dobrym kierunku? Z punktu widzenia twórców rozwijających KDE na pewno tak. Pozbyli się kodu, o który nikt nie dba i nie ma ochoty tego rozwijać. Drugą zaletą z ich punktu widzenia jest to, że nie muszą już nawet próbować w jakikolwiek sposób zapewnić kompatybilność w przypadku działania Plasmy z alternatywnym wobec KWina menedżerem okien. Trzecia związana jest z Waylandem, z którym jak się wydaje, twórcy KDE łączą dość duże nadzieje, bo wciąż kod odpowiedzialny za współpracę Plasmy z Waylandem jest poprawiany, sporo też w tym zakresie informacji i tzw. szumu medialnego. Z Waylandem natomiast nie zadziała praktycznie żaden alternatywnie wykorzystywany w KDE do tej pory menedżer okien.
Nieco inaczej ma się sprawa z punktu widzenia użytkownika, szczególnie systemów instalowanych na notebookach. Nie łudźmy się - choć twórcy KDE mają zasługi w zakresie optymalizacji zapotrzebowania ich środowiska na zasoby komputera, to jednakże trudno uznać Plasmę za środowisko "lekkie" (cokolwiek by to nie znaczyło). Tutaj częściowym rozwiązaniem, które zmniejszało apetyt na energię, było właśnie używanie sesji KDE/OpenBox. W sumie nie miałbym nic przeciwko podjętemu krokowi, gdyby wraz z nim pojawiło się rozwiązanie, które się narzuca: proste przełączanie profilu w przypadku wykrycia zasilania bateryjnego. Oczywiście coś takiego w KDE jest i istnieje od lat, jednakże akurat te ustawienia (Zarządzanie energią) nie wyczerpują całego problemu. Wielu z nas, ustawia Plasmę z różnymi "zabawkami", "efektami", które powodują większe zapotrzebowanie na energię. Gdyby wprowadzić "profil zasilania", który automatycznie potrafi nie tylko przyciemniać, czy wyłączać ekran, sieci bezprzewodowe, ale również przełączać się na "suchy", pozbawiony wszelkich ficzerów wygląd, praca na bateriach trwała by dłużej. Gdyby, gdyby... Takiego rozwiązania nie ma, a zatem do dyspozycji mamy wyłącznie albo ustawianie całej sprawy "ręcznie" po zalogowaniu się (a najlepiej przed) do sesji zasilanej z baterii, albo stworzenie innego użytkownika, który dzieliłby jednakże to co niezbędne z użytkownikiem "prądowym".
Druga kwestia. Wayland. Cóż... Mimo wielu zapowiedzi, wielu filmików z uruchomioną sesją Plasmy w Waylandzie, istnieniem specjalnej dystrybucji Neon, możliwość tę należy skwitować krótkim: nie działa. Gdyby nie to, że bodaj trzy razy udało mi się ją uruchomić (dwa razy Neon i raz w moim Archu), to stwierdziłbym, że taka możliwość istnieje, jednakże nie na moim sprzęcie. Sprzęt - jak się okazuje - nie ma tu nic do rzeczy. O możliwości tej należy zatem zapomnieć i choć wyścig z Fedorą i zapowiadanym w niej Gnome 3 uruchamianym domyślnie w Waylandzie, choć Martin Graesslin dwoi się i troi, by zapewnić taką możliwość, to sądzę, że nie ujrzymy stabilnie działającej Plasmy "Wayland" co najmniej do wydania 5.9/10. KDE Frameworks 5.24 wiosny tu nie czynią (mam KF5.24RC1).
Tyle narzekania, cała reszta (u mnie) działa bardzo dobrze i stabilnie. Nawet zmiany w wyglądzie oceniam tym razem pozytywnie (szczególnie w modułach KCM). Znane mi są natomiast informacje o problemach, jakie występują w systemach ze sterownikami Intela oraz - niekiedy - własnościowymi NVidii. Pierwsze są związane z istniejącym błędem w sterowniku. Twórcy KDE praktycznie porzucili próby dostosowania swego środowiska do wadliwie działającego sterownika, zwłaszcza, że od miesięcy trwa sytuacja, że jak coś poprawili, to nowa wersja sterownika wprowadzała regresje. Znane są możliwości obejścia problemu, ale to temat na forum. Problemy związane z NVidią nie są przeze mnie śledzone. Prawdopodobnie wynikają jednak z wadliwych ustawień sterownika.
Nieco wcześniej, do repozytorium extra weszła nowa wersja Qt - 5.7. Co do zasady działa to stabilnie i niewiele jest programów, które wymagałyby przebudowania. Te, które pochodzą z repozytorium i wymagały przebudowania, zostały już przebudowane. Problem dotyczyć może wyłącznie aplikacji zbudowanych z AUR. Jeśli zatem napotkacie problem niedziałającego programu, najsensowniej wywołać go z konsoli. Gdy zobaczymy, że program nie widzi jakiejś biblioteki, której nazwa sugerować nam będzie, że należy ona do Qt5, to należy go przebudować. Niestety wraz z pojawieniem się Qt5.7, a w zasadzie z pojawieniem qtwebengine w tej wersji, korzystanie z jakiejkolwiek przeglądarki zbudowanej z wykorzystaniem tego silnika staje się mocno problematyczne. Stwierdzić w zasadzie należy, że możliwości takiej nie ma. Na całe szczęście, w oficjalnych repozytoriach nie ma dzisiaj przeglądarki opartej o qtwebengine 5.7, z wyjątkiem QupZilli 2.x, która jest w community-testing. I będzie tam pewnie długo, albowiem twórcy Qt zrzucają problem na Archa, pomimo tego, że nie jest to problem występujący wyłącznie w tej dystrybucji. Z przetestowanych, które używają Qt5.7 oraz udostępniających przeglądarki wykorzystujące qtwebengine, działa prawidłowo wyłącznie QupZilla w KaOS 16.06. Nigdzie indziej nie udało mi się znaleźć stabilnie działającej jakiejkolwiek przeglądarki wykorzystującej qtwebengine 5.7 (testowałem Otter-Browser, QupZillę, w tym również wersję rozwojową z GIT, Quill). Nawet zatem, gdy ktoś się zdecyduje na używanie repozytorium testing oraz używa QupZilli (bądź jakiejkolwiek innej), to polecam dodanie qupzilli do IgnorePkg, zaś w przypadku Otter-Browsera do wykorzystywania qtwebkit. Niestety - dobrze nie jest (w przypadku qupzilla-qt5), ale i tak lepiej.
Czego się zatem można spodziewać, oprócz tego o czym szeroko jest i będzie mowa? Pierwsze, co się narzuca, to brak możliwości korzystania z innego menedżera okien niż KWin. Niegdyś taka funkcjonalność została wprowadzona w KDE4, a wcześniej jeszcze - choć nie w tak prosty sposób - można było korzystać z niej nawet w KDE 3. Obecnie - bodaj ponownie mój ulubiony deweloper KDE - stwierdził, że nikt z tego nie korzysta, ludzi do rozwijania, czy nawet utrzymywania rozwiązania brak, a zatem i ta funkcjonalność została wyłącznona. Nie tylko próżno szukać zatem takich ustawień w systemsettings, ale nawet, gdy mamy zainstalowanego OpenBox obok Plasmy, nie będziemy mogli z rozwiązania KDE/OpenBox, jakie dostarczane jest wraz z paczką openbox skorzystać. Tzn. środowisko się uruchomi, jednakże cały panel będzie kompletnie nieużywalny.
Czy rozwiązanie w dobrym kierunku? Z punktu widzenia twórców rozwijających KDE na pewno tak. Pozbyli się kodu, o który nikt nie dba i nie ma ochoty tego rozwijać. Drugą zaletą z ich punktu widzenia jest to, że nie muszą już nawet próbować w jakikolwiek sposób zapewnić kompatybilność w przypadku działania Plasmy z alternatywnym wobec KWina menedżerem okien. Trzecia związana jest z Waylandem, z którym jak się wydaje, twórcy KDE łączą dość duże nadzieje, bo wciąż kod odpowiedzialny za współpracę Plasmy z Waylandem jest poprawiany, sporo też w tym zakresie informacji i tzw. szumu medialnego. Z Waylandem natomiast nie zadziała praktycznie żaden alternatywnie wykorzystywany w KDE do tej pory menedżer okien.
Nieco inaczej ma się sprawa z punktu widzenia użytkownika, szczególnie systemów instalowanych na notebookach. Nie łudźmy się - choć twórcy KDE mają zasługi w zakresie optymalizacji zapotrzebowania ich środowiska na zasoby komputera, to jednakże trudno uznać Plasmę za środowisko "lekkie" (cokolwiek by to nie znaczyło). Tutaj częściowym rozwiązaniem, które zmniejszało apetyt na energię, było właśnie używanie sesji KDE/OpenBox. W sumie nie miałbym nic przeciwko podjętemu krokowi, gdyby wraz z nim pojawiło się rozwiązanie, które się narzuca: proste przełączanie profilu w przypadku wykrycia zasilania bateryjnego. Oczywiście coś takiego w KDE jest i istnieje od lat, jednakże akurat te ustawienia (Zarządzanie energią) nie wyczerpują całego problemu. Wielu z nas, ustawia Plasmę z różnymi "zabawkami", "efektami", które powodują większe zapotrzebowanie na energię. Gdyby wprowadzić "profil zasilania", który automatycznie potrafi nie tylko przyciemniać, czy wyłączać ekran, sieci bezprzewodowe, ale również przełączać się na "suchy", pozbawiony wszelkich ficzerów wygląd, praca na bateriach trwała by dłużej. Gdyby, gdyby... Takiego rozwiązania nie ma, a zatem do dyspozycji mamy wyłącznie albo ustawianie całej sprawy "ręcznie" po zalogowaniu się (a najlepiej przed) do sesji zasilanej z baterii, albo stworzenie innego użytkownika, który dzieliłby jednakże to co niezbędne z użytkownikiem "prądowym".
Druga kwestia. Wayland. Cóż... Mimo wielu zapowiedzi, wielu filmików z uruchomioną sesją Plasmy w Waylandzie, istnieniem specjalnej dystrybucji Neon, możliwość tę należy skwitować krótkim: nie działa. Gdyby nie to, że bodaj trzy razy udało mi się ją uruchomić (dwa razy Neon i raz w moim Archu), to stwierdziłbym, że taka możliwość istnieje, jednakże nie na moim sprzęcie. Sprzęt - jak się okazuje - nie ma tu nic do rzeczy. O możliwości tej należy zatem zapomnieć i choć wyścig z Fedorą i zapowiadanym w niej Gnome 3 uruchamianym domyślnie w Waylandzie, choć Martin Graesslin dwoi się i troi, by zapewnić taką możliwość, to sądzę, że nie ujrzymy stabilnie działającej Plasmy "Wayland" co najmniej do wydania 5.9/10. KDE Frameworks 5.24 wiosny tu nie czynią (mam KF5.24RC1).
Tyle narzekania, cała reszta (u mnie) działa bardzo dobrze i stabilnie. Nawet zmiany w wyglądzie oceniam tym razem pozytywnie (szczególnie w modułach KCM). Znane mi są natomiast informacje o problemach, jakie występują w systemach ze sterownikami Intela oraz - niekiedy - własnościowymi NVidii. Pierwsze są związane z istniejącym błędem w sterowniku. Twórcy KDE praktycznie porzucili próby dostosowania swego środowiska do wadliwie działającego sterownika, zwłaszcza, że od miesięcy trwa sytuacja, że jak coś poprawili, to nowa wersja sterownika wprowadzała regresje. Znane są możliwości obejścia problemu, ale to temat na forum. Problemy związane z NVidią nie są przeze mnie śledzone. Prawdopodobnie wynikają jednak z wadliwych ustawień sterownika.
Nieco wcześniej, do repozytorium extra weszła nowa wersja Qt - 5.7. Co do zasady działa to stabilnie i niewiele jest programów, które wymagałyby przebudowania. Te, które pochodzą z repozytorium i wymagały przebudowania, zostały już przebudowane. Problem dotyczyć może wyłącznie aplikacji zbudowanych z AUR. Jeśli zatem napotkacie problem niedziałającego programu, najsensowniej wywołać go z konsoli. Gdy zobaczymy, że program nie widzi jakiejś biblioteki, której nazwa sugerować nam będzie, że należy ona do Qt5, to należy go przebudować. Niestety wraz z pojawieniem się Qt5.7, a w zasadzie z pojawieniem qtwebengine w tej wersji, korzystanie z jakiejkolwiek przeglądarki zbudowanej z wykorzystaniem tego silnika staje się mocno problematyczne. Stwierdzić w zasadzie należy, że możliwości takiej nie ma. Na całe szczęście, w oficjalnych repozytoriach nie ma dzisiaj przeglądarki opartej o qtwebengine 5.7, z wyjątkiem QupZilli 2.x, która jest w community-testing. I będzie tam pewnie długo, albowiem twórcy Qt zrzucają problem na Archa, pomimo tego, że nie jest to problem występujący wyłącznie w tej dystrybucji. Z przetestowanych, które używają Qt5.7 oraz udostępniających przeglądarki wykorzystujące qtwebengine, działa prawidłowo wyłącznie QupZilla w KaOS 16.06. Nigdzie indziej nie udało mi się znaleźć stabilnie działającej jakiejkolwiek przeglądarki wykorzystującej qtwebengine 5.7 (testowałem Otter-Browser, QupZillę, w tym również wersję rozwojową z GIT, Quill). Nawet zatem, gdy ktoś się zdecyduje na używanie repozytorium testing oraz używa QupZilli (bądź jakiejkolwiek innej), to polecam dodanie qupzilli do IgnorePkg, zaś w przypadku Otter-Browsera do wykorzystywania qtwebkit. Niestety - dobrze nie jest (w przypadku qupzilla-qt5), ale i tak lepiej.
Komentarze
Prześlij komentarz