Jak GIMP 2.9.8 z jasnego nieba
Nikt nie zna dnia ani godziny pojawienia się najnowszego wydania edytora graficznego GIMP. Podobnie i tym razem wiadomość o nowej wersji zaskoczyła tę cześć publiczności, która nie śledzi postępów i zmian w tym wiodącym projekcie opensource. Oczywiście pamiętajmy o tym, że seria 2.9.xx to niestabilne i deweloperskie wydania po drodze do wyczekiwanego od lat GIMPa 2.10.
Na początku bowiem warto zauważyć totalnie nowe podejście do edycji gradientów. Niestety, tylko tych „dla użytkownika” i pozostających do następnej edycji. Niemniej nie do przecenienia jest możliwość edytowania przejścia kolorów przejść „na żywo” i bezpośrednio na płótnie/obrazie. Punkty możemy dodawać, przesuwać, modyfikować wraz z barwami. Mało tego, mieszać możemy również barwy. Wszystko to powoduje, że nowe gradienty w GIMPie są po prostu wyśmienite.
Co może zadziwić wielu fotografów, to GIMP który doczekał się funkcji sprawdzającej i pokazującej prześwietlenia. Taką opcję znajdziemy w 2.9.8 i co więcej. Możemy również ustalić, jakim kolorem chcemy zaznaczyć powyższe niedopatrzenie.
Co więcej, w końcu doczekaliśmy się funkcji Paste in Place która robi to co wynika z jej nazwy. Wkleja dokładnie w to samo miejsce, z którego został skopiowany wycinek.
Ukłonem w stronę miłośników plików HGT będzie ich niemal poprawna obsługa przez GIMP 2.9.8. Nie jest to może to do końca to, czego oczekują fani NASA, ale jednak.
Pełną listę nowości znajdziemy pod tym adresem. Jest tego oczywiście o wiele więcej, niż można wspomnieć w ogólnym opisie. Całość finalnie sprowadza się do ustabilizowania wersji 2.10.
Gdy naszym systemem jest Ubuntu 16.04/17.04/17.10, Mint 18.xx lub pochodne, program w wersji rozwojowej zainstalujemy z następującego PPA:
sudo add-apt-repository ppa:otto-kesselgulasch/gimp-edge
sudo apt-get update
sudo apt-get install gimp
W Arch Linuksie i Manjaro:
yaourt -S gimp-git
9 komentarzy
Dodaj komentarz
Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.
W AUR gimp-git jest jeszcze w wersji 2.9.4.
Wersja 2.9.8 jest dostępna w paczce gimp-devel 😉
O tempora… Każda paczka *-git znajdująca się w AUR to tylko skrypt pozwalający na lokalne zbudowanie paczki. Wersja przy paczce *-git budowanej z AUR nie ma kompletnie znaczenia, bowiem jest ona generowana w trakcie budowy paczki. Budując dzisiaj (o 10:25) gimp-git z AUR otrzymujesz wersję: gimp-git 1:2.9.8.11.g6fee1a413f-1 (istotne to co między obiema “1”).
W przypadku gimp-devel, to wymaga on gegl i babl w wersjach, których jeszcze nie ma w repozytorium (obie są już oflagowane, ale być może są to zbyt wysokie wersje dla innego oprogramowania). Możesz spróbować przebudować je do wersji wymaganych przez gimp-devel lub użyć bebl-git i gegl-git
Jeśli w istocie GIMP 2.9.8 wymaga babl w minimalnej wersji 0.1.38, a gegl w minimalnej wersji 0.3.24, to gimp-git zbudowany na aktualnym PKGBUILDzie może działać nieprawidłowo, albowiem zostanie ona zbudowana z babl 0.1.30 (wersja w repozytorium jest wyższa niż wymagana w PKGBUILD, ale niższa niż w gimp-devel). Jeśli informacja podana przy gimp-devel jest prawidłowa, to wówczas musisz zrobić dokładnie to samo, co przy gimp-devel, by prawidłowo się zbudowało i działało.
GIMP-git masz jeszcze na chińskim serwerze społeczności Archa: archlinuxcn.org. Nie musisz niczego budować, a zależności też będą w odpowiednich wersjach (tu najczęściej też *-git).
Budując dzisiaj o 10:55.
gimp-git 1:2.9.4.1760.g2a7a53b384-1 (2017-08-28 03:45)
Zależności:
– gegl-git>=0.3.15 (budowany z AUR)
– babl>=0.1.27 (już zainstalowany)
Oczywiście tu również wykłada się na gegl i babl, bo nie znajduje ich w AUR w takiej wersji. Oddzielne zbudowanie babl-git i gegl-git załatwia sprawę, bo buduje je w aktualnych wersjach (mimo, że wyświetla informację, że są w starszych wersjach).
Nie chodziło mi o brak możliwości zainstalowania Gimp’a w najnowszej wersji, a jedynie zamieszanie dot. wersji paczek w AUR. Coś jak: “zaglądam i widzę 2.9.4 – logiczne, że nie instaluję bo miałem nowszą (2.9.6)”.
Nie mam pojęcia w jaki sposób mogłeś dzisiaj zbudować wersję 2.9.4.itd. budując gimp-git z AUR. Jest to dokładnie ta wersja, która figuruje w AUR, czyli z 2017-08-28 03:45. Za wskazanie źródła GIMP odpowiada 28 linia PKGBUILDu i jest tam odniesienie do linii master (czyli bieżącej) w git. Pobranie przez makepkg źródeł w tym przypadku (i w zasadzie w każdym przypadku git, svn, bzr itp.) polega na sklonowaniu aktualnego stanu repozytorium git; niekiedy może być jeszcze określona branch, tu tego nie ma zatem pobiera “główną” (master) linię rozwojową GIMPa. Numer wersji jest generowany w chwili budowania paczki i odnosi się zawsze do sklonowanego repozytorium GIT (tu akurat linia 37 PKGBUILDu). Nie istnieje zatem możliwość, aby Tobie pobrało się repozytorium z sierpnia 2017 r. a mi z grudnia 2017 r. Dokonując w tym samym momencie budowy paczek z git musimy otrzymać paczki w dokładnie takiej samej wersji. Prawdopodobnie odczytujesz zatem nie ten numer wersji, który powinieneś, albo gdzieś popełniasz błąd przy budowie paczki. Zwróć też uwagę, że gimp-git nie odpowiada wersji 2.9.8 – jest od niej (dzisiaj) nowszy o 3 wersje i ileś commitów.
Gwoli ścisłości – babl-git i gegl-git (zresztą jakikolwiek *-git) nigdy nie buduje paczki w “aktualnej” wersji, a zawsze w wersji rozwojowej. Chcąc mieć ich “aktualną” wersję musiałbyś przerobić ich PKGBUILDy znajdujące się w repozytorium Archa).
To zaś o czym piszesz z numeracją paczek z git w AUR (że nie jest logiczne) z logiką tak rozumianą nie ma nic wspólnego. To kwestia pewnej umowy: raz przygotowany PKGBUILD budujący coś z GIT (bzr, svn i in.) jest aktualny tak długo, jak długo umożliwia budowę paczki (nawiasem mówiąc w przypadku gimp-git włąśnie to powinno być dokonane). Nowa wersja ma się pojawić w AUR wyłącznie wówczas, gdy z jakiegoś powodu PKGBUILD wymaga zmian, choć często opiekunowie również “podbijają” taką wersję, gdy po prostu paczka wymaga przebudowania. Decydując się na posiadanie paczek z git sam użytkownik musi być na tyle świadomy co ma (i dlaczego), że coś takiego jak dbanie o okresowe przebudowanie takiej paczki jest dla niego oczywiste i logiczne. Numerkami – skoro to automatycznie generowane – nie należy się przejmować.
To teraz już wiem, że nie należy się przejmować numeracją, bo wyświetlało mi wersję 2.9.4 ale zbudowało tak jak napisałeś – wersję rozwojową. Popatrz proszę:
https://imgur.com/a/Nwu3v
Chyba, że źle odczytuję widoczną tu wersję lub jest to owa numeracja, która w tym przypadku nie ma znaczenia.
Co do świadomości jako usera – na czystym Archu siedzę od niedawna (wcześniej Manjaro) i przyznaję, że pewne rzeczy dzięki temu poznaję i uczę się (ot dzisiejsza sytuacja).
Mam zatem jeszcze pytanie: skoro gimp-git buduje najnowszą wersję, dlaczego nie używa babl-git i gegl-git do zbudowania paczki, tylko upiera się przy konkretnym numerze? Dobrze rozumiem, że chodzi o odniesienie do PKGBUILD o którym napisałeś? Przepraszam za głupie pytania, ale staram się to zrozumieć, skoro już zaistniała taka sytuacja.
Nie używaj do takich rzeczy jak GIMP yaourta (ani innego), chyba, że wiesz jak masz je “poukładane”.
To co pokazujesz w ogóle nie ma absolutnie nic wspólnego z wersją paczki gimp-git, jaką dzisiaj możesz zbudować. Jak na razie, to wyłącznie pobrało tzw. migawkę gimp-git z AUR i pokazało Ci w jakiej jest ona wersji. W tym momencie wyświetlana jest wersja odczytywana z pola pkgver (linia 7) w PKGBUILD i w przypadku budowy paczki z *-git nie ma to absolutnie najmniejszego znaczenia. Nowa wartość w tym polu pojawi się po wykonaniu instrukcji zawartej w instrukcji pkgver (linie 35-38). Jak do tej pory nawet ta instrukcja nie została wykonana, a zatem nic jeszcze nie wiesz o wersji, jaką Ci będzie budował. Wersja zbudowanej paczki pojawia się w nazwie pliku oraz w PKGBUILD. Budując przez yaourt (trochę to wada, zwłaszcza przy dużych paczkach, zwłaszcza właśnie takich, które wymagają korekt w PKGBUILD) zobaczysz tę wersję dwa razy, raz “przeleci” podczas wykonywania kodu, drugim razem, gdy będzie instalowana paczka.
Dalsze pytania nie są głupie, ale – albo są wynikiem jakiegoś nieporozumienia, albo wadliwego budowania.
Generalnie – kwestia czy i jakiej wersji minimalnej/maksymalnej dane oprogramowanie potrzebuje jako tzw. zależności wynika z… jego kodu 🙂 Zwykle o tych wersjach zależności dowiedzieć się można albo ze stron domowych danych programów, albo studiując część informacji, które są przekazywane podczas konfigurowania kompilacji. W przypadku gimp-git babl i gegl nie muszą być w wersjach z git, ale muszą być w wersjach wyższych niż te, które są obecnie dostępne w repozytoriach Archa. Na polski: nie zbudujesz obecnie wersji >=2.9.8 opierając się wyłącznie na tych wersjach paczek, które są dostępne w repozytoriach. Rozwiązania są następujące:
– nie ingerować w PKGBUILD, ale samemu dokonać skompilowania babl w wersji >= 0.1.38, a gegl w wersji >=0.3.24, ściągając PKGBUILDy tych paczek, a następnie je odpowiednio zmieniając i budując paczki lokalnie,
– również nie ingerować w PKGBUILD, ale “zainstalować” paczki babl-git i gegl-git z AUR,
– dokonać ingerencji w PKGBUILD gimp-git i doprowadzić go do porządku (bo teraz jest on wadliwy).
Dla GIMP-git obojętne jest, czy babl i gegl są minimalnych w wersjach, które są przez niego wymagane, czy są to wersje rozwojowe (czyli owe *-git, które będą “wyższe” niż wersje “stabilne”). Niestety ze względu na wadliwość PKGBUILDu gimp-git dostaje on “kota” i tak, czy inaczej będzie budować wadliwą wersję. Jedyna, którą się uda zbudować, to wpierw budując i instalując gegl-git oraz babl-git, a potem budując gimp-git (bo już się zadowoli). Będzie on jednak wówczas wykorzystywać gegl i babl w wersjach *-git, albowiem takie masz w systemie i w oparciu o takie zbudowałeś.
A teraz KUBEŁ ZIMNEJ WODY – jeśli nie jest dla Ciebie w jakikolwiek sposób konieczne używanie oprogramowania w wersjach rozwojowych (czyt. git), jeśli nie wiesz czy, jak i dlaczego wersja taka z dnia na dzień może przestać działać, oraz nie wiesz jak temu zaradzić, to… stroń od tego typu oprogramowania, a już na pewno od “gitowych” drabinek (choć niekiedy to konieczne), gdzie jedna aplikacja w wersji git jest budowana na innej też takiej itd, szczególnie jeśli te składniki, które są wykorzystywane do budowy aplikacji docelowej są jeszcze wykorzystywane przez inne oprogramowanie z repozytoriów. Inaczej bardzo szybko rozwalisz sobie system. Dla testowania tego typu rzeczy najlepsze są jednak appimage lub flatpaki, ewentualnie jakiś wirtualnie postawiony system (lub fizycznie, ale wyodrębniony od “produkcyjnego”). Niestety, ale z treści zadawanych przez Ciebie pytań mogę tylko tyle stwierdzić: zabawa w paczki “git” nie jest jeszcze dla Ciebie (bez obrazy – nie jest dla 99% użytkowników).
Gimp to prawdę mówiąc jedyna paczka w wersji rozwojowej, której używam. Oczywiście mam do tego poligon doświadczalny w postaci VM. Raz jeszcze dzięki za wytłumaczenie wszystkiego w przystępny sposób i cenne uwagi 🙂
Doinstaluj sobie repozytorium archlinuxcn (post z 25.09 pod gimp-git w AUR) i gimp-git ciągnij stamtąd. Jeśli chcesz – obojętne – gimp-git bądź gimp-devel poprawione i budujące się, to zapraszam na polskie forum Archa – masz stosowny wątek przypięty, gdzie zgłaszane są zapotrzebowania na PKGBUILDy.