Pitivi 0.94 – Lepiej, czy gorzej?

Pojawiło się kolejne wydanie pitivi, które przybliża nas do wersji 1.0.

Problem w tym, że 0.94 otrzymało kilka poprawek błędów, ale nadal jest to, moim zdaniem, wersja testowa, niedokończona, względem 0.15.2.
Już nawet nie chodzi o to, że uźytkownicy Debiana, czy Ubuntu mogą zapomnieć o szybkiej aktualizacji z wersji 0.93 (repo) do 0.94, ponieważ nowe wydanie opiera się o pakiety ges i gnonlin 1.4.0, a w vivid jak na razie posiada 1.2.

Można pobrać wersje „pełną” nowego wydania pitivi (ponad 200MB), ale i ona nie jest bez wad.

Twórcy Pitivi przystosowali wygląd programu do obecnego trendu panującego w gnome3, aby likwidować belkę programów na rzecz… niczego.

Kolejna sprawa to nie działające miniaturki materiałów, bo nie ma się zainstalowanego GnomeDesktop:

 

Zauważalnie widać też, że na linii czasu także miniaturki… niedomagają:

A oto ustawienia pitivi, dużo ich 😉

Dobrze, że działają efekty, ale nie zawsze pitivi dobrze je interpretuje.
Poniżej działający efekt:

Jednym z ciekawszych rzeczy i w miarę działających – przejścia:

Nie było mi dane ich sprawdzić w praktyce, czyli jak to wygląda po wyrenderowaniu materiału, bo jako tako działają chyba tylko w programie.

Pitivi 0.94 otrzymało kilka poprawek, ale i tak wiele jest do zrobienia.
Program bardzo łatwo się zawiesza, albo potrafi (co jest naprawdę trudne) zawiesić cały system jakimś wyciekiem pamięci. Wielokrotnie puszczenie „play” na podglądzie nie ukazuje rzeczywistego materiału, nad którym znajduje się znacznik. Podgląd materiału wielokrotnie nie potrafi także ukazać efektu przejścia, trzeba to robić ręcznie (przesuwając znacznik nad przejściem samemu). Panel renderowania potrafi wywalić błąd i zamknąć program. Renderowanie potrafi zawiesić się na przejściu. A opcja wytyczająca i scalająca blisko siebie materiały, raz działa, a czasami nie. Do tego jeszcze dołóżmy, że linia czasu zmienia swoją rozpiętość, po dodaniu długiego materiału, co denerwuje, kiedy składamy sobie filmik z bardzo krótkich skrawków. No i chyba najbardziej denerwujące, czyli kasujemy skrawek, puszczamy „play” na podglądzie, a tutaj okazuje się, że skasowaliśmy… nie wielką część tego co chcieliśmy wyciąć. Ponawiamy czynność i… ponownie ta sama melodia.
Można by się przyczepić do jeszcze kilku rzeczy, ale po co?

Ciszyć może ograniczenie użycia procesora podczas renderowania materiału, albo to że pobierając „pełną” wersję, większość osób może sobie wypróbować nowe Pitivi.
Mam nadzieję, że następne wydanie nie pojawi się dopiero na wrzesień w 2015 roku.

pitivi 0.93

Odpuściłem sobie testowanie pitivi 0.92, bo nie chciało mi się walczyć z ubuntu i zależnościami.

Ale z wydaniem 14.04 Ubuntu w repozytoriach pojawiło się pitivi 0.93, które zastępowało wydanie 0.15.2.
W przypadku Debiana, w jego repozytoriach pojawiło się: 0.91, 0.92, a obecnie 0.93 (z tej samego wydania korzysta Ubuntu).

pitivi 0.93

Ale tak jak pitivi 0.15, pozwalało podstawowych zmian na filmach, dodawać efekty, to jego stabilność i działanie było koszmarne.

Pitivi 0.93 przynosi wiele poprawek i zmian (podobno).
Więc ja wyliczę to, co nadal nie działa lub jest zepsute:
— Brak miniaturek na liście materiałów.
— Po najechaniu na skalę czasu w osi czasu (tam gdzie tniemy i przesuwamy materiały) i pokręceniu kółkiem myszki – nic się nie dzieje. Wcześniej (w wersji 0.15) mogliśmy dzięki temu w szybki sposób „rozciągnąć” zakres czasowy, albo go „zwęzić”.
— Rozjeżdżanie się pociętych kawałków, kiedy jeden z nich przenosimy z końca na sam początek lub po prostu w inne miejsce.
— Po dokonaniu cięć w filmie i skasowaniu materiału nudnego lub nie potrzebnego tylko pierwszy kawałek ma podgląd klatek, zaś pozostałe kawałki tracą ten podgląd.
— Podczas renderowania czas pod podglądem się zmienia, ale podgląd pozostaje bez zmian.
— Po zmianie rozdzielczości materiału względem niego np. filmik to 800×600, a my ustawiamy renderowanie na 720p, efekt: pierwszy kawałek zostanie wyrenderowany poprawnie, zaś drugi i kolejne zostaną zniekształcone.
— Dodawanie napisu/tytułu:
— Po dodaniu napisu lokuje się on zawsze na końcu, a nie na początku.
— Po skasowaniu napisu jako materiału z osi czasu, jego edycja nie znika, nie można też dodać napisu ponownie.
— Po skasowaniu tytułu/napisu program nadal interpretuje go jako widoczny na osi czasu i renderuje, choć go wcale nie ma. Efekt: kilka sekund czarnego obrazu dodanego do filmu
— Ten sam materiał z napisem i bez, to różnica około 10MB.

pitivi 0.93

Co więc jest lepsze w 0.9x, a 0.15.2?
Stabilność, działanie (choć nie zawsze), poprawione opcje efektów.

0.9x nadal nie jest programem, którego można normalnie używać, a powodują to proste i prozaiczne błędy. Chyba, że ktoś się uprze, ale w innym przypadku… trzeba wybrać kdenlive lub openshot, ponieważ zależności ubuntu 14.04 sprawiają, że nie ma możliwości powrotu do starszej wersji pitivi, co zmusza nas do korzystania z programu, który jest całkowicie niedorobiony.

pitivi 0.93

Arch linux: przywracanie poprzedniej wersji danego programu/sterownika/elementu systemu

Arch linux to taka dystrybucja, która nie posiada oddzielonych elementów odnośnie kompilacji, od elementów składowych swoich odpowiedników w systemie.

Fajnie ukazuje to Ubuntu/Debian, Fedora, czy nawet openSuse i ich klony np. Mint. Mają one osobne paczki odnośnie działania w systemie, a pokrewne paczki zakończone np. -dev, -devel albo jeszcze inaczej.

Oznacza to, że kiedy chcemy coś w danej dystrybucji skompilować, zbudować ze źródeł nie zrobimy tego – ponieważ system nie potrzebnych plików. I kolejny raz odwołam się do Ubuntu, gdzie aby coś kompilować trzeba pobrać dość znaczną ilość danych (wielkość), ponieważ system nie ma wymaganych rzeczy, aby dany proces wykonać.

Arch linux nie poszedł tą drogą, a to oznacza że w systemie (a wymaga to AUR), wystarczy doinstalować niewielką ilość rzeczy i już możemy kompilować, budować paczki i instalować je w systemie.

I tu nawiąże do sytuacji, która spotkała mnie na kilka dni temu, aż do dzisiaj.
Przed świętami wykonałem aktualizację, którą robię w Archu nawet 2 do 3 razy dziennie, ponieważ pojawianie się aktualizacji nie jest ustalone. Przy aktualizacji został zaktualizowany  pakiet automake, który wymagany jest do kompilacji. A że ja kompiluje e17 ze svn, a więc fajnie że pojawiła się jego nowa wersja. Otwórz okazało się, że właśnie ten pakiet powoduje błąd kompilacji. Sprawia on, że nie można skompilować danych i zainstalować ich nowszą wersję.
Rozwiązanie?
Czekać na naprawę błędu, ale są święta i nie wiadomo kiedy ktoś to naprawi.

Innym rozwiązaniem jest powrót do poprzedniej wersji automake – tylko jak, jak w katalogu gdzie pobierane są wszystkie paczki są dwie nowe wersje?

I tu wielu z was postanowiłoby czekać na naprawę błędu, albo próbowałoby jakoś obejść problem.

Ja zrobiłem coś innego… po prostu wróciłem do poprzedniej wersji automake 🙂

Zapytacie: jak to zrobiłem, jeśli na serwerach jest już nowa wersja, a stara została skasowana?

Aby nie zanudzić was napiszę tylko: wszedłem na stronę Archa, na automake. Po prawej mamy napis: Source Files / View Changes – wchodzimy do View Changes. Tam odnajdujemy linijkę odnośnie: skąd pobierana jest paczka do najnowszej wersji >> ftp://ftp.gnu.org/gnu/ – po przejściu na dane miejsce – odnajdujemy, w moim przypadku: automake. I tam w katalogu mamy prawie wszystkie wersje danego elementu systemu. To nie koniec… teraz pobieramy wcześniejszą wersję i rozpakowujemy daną paczkę w jakimś miejsce/katalogu. I teraz normalnie ją kompilujemy – tak jak mówi nam to plik instalacyjny. Po kompilacji starszej wersji automake (czyli 10.3) kompilacja elementów e17 przebiega bez problemu 🙂

Powyższy opis sposobu na powrót, lub przywrócenie poprzedniej wersji danego elementu systemu jest banalnie prosty – jeśli wykonamy go choć raz.

Wspominam o tym, ponieważ w Archu mamy trzy sposoby przywracania poprzednich wersji lub instalowania wcześniejszych wersji –pierwszą jest jeśli dość długo nie robimy czyszczenia katalogu z paczkami do instalacji w Archu – to w /var/cache/pacman/pkg mamy pokaźną kolekcję nowych i tych starych wersji wszystkiego co mamy w systemie.  Druga metoda to pobranie wersji z git, lub ręczna kompilacja nowej wersji (nie jest to może przywracanie), która może okazać się lepsza, choć instalując wersję z repo mamy niby to samo. Ale jeśli ktoś ma lxde i zainstaluje pakiet lxpanel z AUR (czyli git), przekona się że wersja skompilowana działa lepiej i posiada przezroczystość, która nie działa w pakiecie z repo. A trzecią metodą jest ta opisana powyżej… docieramy do wcześniejszej wersji danego elementu i pobieramy źródła, a później je kompilujemy i instalujemy 🙂

Dlatego Arch jest tak elastyczny… jak czegoś nie ma w repo, nie też tego w AUR, pobierz źródła i zainstaluj ręcznie – ponieważ system ci na to pozwala i nie ogranicza cię w tym temacie 😉 Jak robią to inne dystrybucje dla początkujących.

gnome-shell – belka programów i panel

Dawno temu jeszcze chyba za czasów gnome2 i początków gnome3 pytałem się, czy jest możliwość schowania belki programu pod panel w gnome.

I okazuje się, że jest na to rozwiązanie 🙂

Działa w gnome-shell, powodując schowanie się belki pod panel – całkowicie.
Jedyny minus to to, że znikają też przyciski zamykania okna, czy jego minimalizacji. No ale coś za coś 🙂 Po za tym, każdy program można zamknąć po przez menu i… zamknij 😉

Aby dokonać zmiany, będzie nam potrzebny: terminal i chęci.

I teraz… (po otwarciu terminala) wpisujemy/wklejamy:
sudo nano /usr/share/themes/Adwaita/metacity-1/metacity-theme-2.xml

Teraz znajdujemy wpis: <frame_geometry name=”max” has_title=”false”  parent=”normal” rounded_top_left=”false” rounded_top_right=”false”>
I go kasujemy go – do i z  </frame_geometry>.

I wklejmy w to miejsce:
<frame_geometry name="max" has_title="false"  parent="normal" rounded_top_left="false" rounded_top_right="false">
<distance name="left_width" value="0"/>
<distance name="right_width" value="0"/>
<distance name="left_titlebar_edge" value="0"/>
<distance name="right_titlebar_edge" value="0"/>
<distance name="title_vertical_pad" value="0"/>
<border name="title_border" left="10" right="10" top="1" bottom="1"/>
<border name="button_border" left="0" right="0" top="0" bottom="3"/>
<distance name="bottom_height" value="0"/>
</frame_geometry>

Zapisujemy plik 🙂

To samo robimy z: metacity-theme-3.xml
sudo nano /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml

Ważne!!
Aby sztuczka zadziałała, musimy mieć ustawione standardowe theme w gnome-shell czyli Adwaita – w innych theme nie odnalazłem podobnego kodu do podmiany, a więc nie wiem czy da się dany trik zastosować w innym wyglądzie.

Teraz wylogować się i zalogować się – a mając zmaksymalizowane okno, belka powinna wchodzić pod panel. Jak napisałem, mankamentem jest schowanie się też przycisków do minimalizacji i zamykania okna, ale w gnome-shell można to sobie zrekompensować albo skrótami klawiszy, albo po przez zamykanie po przez menu 🙂 Bardzo dobrze sprawdza się użycie kombinacji klawiszy…

ps. Okazuje się, że nie zawsze to działa, a więc w razie gdyby u was nie zadziałało, to nie piszcie o tym. To jest tylko i tak rozwiązanie częściowe.