Otter-Browser #137
Od jakiegoś czasu twórcy Otter-Browsera są zainteresowani forkiem qtwebkit rozwijanym przez Konstantina Tokareva. Projekt ma przywrócić blask zaniedbywanemu od jakiegoś czasu qtwebkitowi, spowodować, że w większym stopniu będzie respektował standardy, a także m.in. zapewni lepsze bezpieczeństwo. Jak na razie - wobec wydania oficjalnego występuje jeszcze kilka regresji. W zależności od indywidualnych potrzeb silnik taki jednym wystarczy, inni mogą go traktować wyłącznie w kategoriach eksperymentu i - przede wszystkim - włączyć się (choćby poprzez zgłaszanie uwag) w tworzenie nowoczesnej wersji qtwebkit. Właśnie ukazała się wersja TP3 (Technical Preview) qtwebkita Tokareva, na którą od dwu już wydań czekali twórcy Otter-Browsera, co spowodowało, że nie występowało wydanie tygodniowe #136 oraz lekkie spóźnienie wydania #137.
Zaprezentowany PKGBUILD buduje Otter-Browser zarówno z qtwebengine, jak i z qtwebkit. Tym qtwebkit, który znajduje się w systemie, a zatem - w niemal wszystkich przypadkach - będzie to tzw. wersja legacy, która jest dostępna w repozytoriach. Chcąc zbudować z qtwebkit TP3 musielibyśmy wpierw zbudować tę wersję i zainstalować ją w systemie (raczej zamiast, aniżeli obok dostarczanej w repozytoriach). Wersji qtwebkit Tokareva nie widzę w AUR, zatem jeśli ktoś się zdecyduje na budowę Otter-Browsera z tym silnikiem, to musi sobie we własnym zakresie ją zbudować, posługując się informacjami o zasadach budowy umieszczonymi przez jego twórcę oraz - najlepiej - PKGBUILDem qtwebkit znajdującym się w repozytorium. Użyteczne mogą być również migawki wydań, które również udostępnia twórca.
Jak na razie nie pokusiłem się o budowę nowego qtwebkita, zatem nie wiem na ile Otter-Browser budowany wg mojego PKGBUILDu radzi sobie z tym silnikiem. Instrukcje kierowane do makepkg przez skrypt są jednakże standardowe i powinny współpracować z qtwebkit niezależnie od tego jakiej jego wersji użyjemy.
Spośród dostrzeżonych w tym wydaniu błędów (testuję od chwili) zauważyłem istniejący od kilku wydań ponownie błąd związany z tym, że gdy w Otter-Browser nie wyłączymy (jest ona domyślna) opcji "pokaż ikonę w zasobniku systemowym", to po wyjściu z Ottera - co oczywiste - program jeszcze pozostaje w pamięci, a dostęp do niego jest możliwy właśnie z zasobnika systemowego, jednakże stamtąd nie możemy zamknąć programu. Opcja "Zamknij" nie wywołuje żadnych skutków.
Zaprezentowany PKGBUILD buduje Otter-Browser zarówno z qtwebengine, jak i z qtwebkit. Tym qtwebkit, który znajduje się w systemie, a zatem - w niemal wszystkich przypadkach - będzie to tzw. wersja legacy, która jest dostępna w repozytoriach. Chcąc zbudować z qtwebkit TP3 musielibyśmy wpierw zbudować tę wersję i zainstalować ją w systemie (raczej zamiast, aniżeli obok dostarczanej w repozytoriach). Wersji qtwebkit Tokareva nie widzę w AUR, zatem jeśli ktoś się zdecyduje na budowę Otter-Browsera z tym silnikiem, to musi sobie we własnym zakresie ją zbudować, posługując się informacjami o zasadach budowy umieszczonymi przez jego twórcę oraz - najlepiej - PKGBUILDem qtwebkit znajdującym się w repozytorium. Użyteczne mogą być również migawki wydań, które również udostępnia twórca.
Jak na razie nie pokusiłem się o budowę nowego qtwebkita, zatem nie wiem na ile Otter-Browser budowany wg mojego PKGBUILDu radzi sobie z tym silnikiem. Instrukcje kierowane do makepkg przez skrypt są jednakże standardowe i powinny współpracować z qtwebkit niezależnie od tego jakiej jego wersji użyjemy.
Spośród dostrzeżonych w tym wydaniu błędów (testuję od chwili) zauważyłem istniejący od kilku wydań ponownie błąd związany z tym, że gdy w Otter-Browser nie wyłączymy (jest ona domyślna) opcji "pokaż ikonę w zasobniku systemowym", to po wyjściu z Ottera - co oczywiste - program jeszcze pozostaje w pamięci, a dostęp do niego jest możliwy właśnie z zasobnika systemowego, jednakże stamtąd nie możemy zamknąć programu. Opcja "Zamknij" nie wywołuje żadnych skutków.
Komentarze
Prześlij komentarz