Commit Digest 112: 25 maja 2008

18 lipca 2008

• Marble otrzymuje mapy "temperatura" i "opady", oraz wtyczkę "gwiazdy".
• Więcej pracy nad "rozmytym wyszukiwaniem" w Digikam.
• Konqueror otrzymuje obsługę odtworzenia sesji po wystąpieniu błędu oraz zarządzania sesjami.
• Początek integracji rzeczy związanych z SVG z WebKit'a do KHTML.
• Więcej usprawnień w KHTML, z KJS/Frostbyte, wersja korzystająca z bytecode i innych usprawnień, przeniesione z powrotem do kdelibs.
• Początek implementacji API skryptowego JavaScript dla dokumentów PDF w Okular.
• Kontynuowana praca nad integracją KJots z Kontact, oraz tworzeniem/edytowaniem linków między wpisami w KJots.
• Więcej pracy nad motywem Amaroka 2.
• Różne usprawnienia w kvpnc.
• Więcej konfiguracji interfejsów użytkownika w KNetworkManager.
• Usprawnienia we wtyczce planisty wykorzystania łącza KTorrent.
• Obsługa, opcji drukowania CUPS w oknach drukowania KDE.
• Mailody przeniesione do kdereview.
• Wtyczka "OnlineSync" jest połączona z Akregatorem.
• Pierwszy commit nowego filtru MSWord-do-ODF dla KWord, oraz narzędzie kaligraficzne dla Karbon.
• KDevMon przeniesiony do KDE 4.
• Rozwój menedżera pakietów Shaman2 jest przeniesiony do KDE SVN (playground/sysadmin).
• PHP-Qt bindings przeniesione z playground/bindings do modułu kdebindings.

Bart Coppens pisze o kolejnej generacji systemie "kafelków" wprowadzonym ostatnio do Krity:

“Na początek trochę historii. Krita od zawsze posiadała tak zwany system "kafelków". Oznacza to, że obraz był dzielony na kwadraty 64x64 pikseli. Zamiast ładowania całości obrazu do pamięci można było przechowywać w niej tylko najczęściej używane części, a resztę danych odkładać na partycję wymiany.

Na przykład, jeśli rysujemy na dużym obrazku, przeważnie zmieniamy jedynie mały kawałek w danym momencie. Większość części wcale nie jest zmieniana i może zostać niewielkim kosztem odłożona na dysk.

Kolejnym przykładem jest cofanie zmian. Jeśli zaczynamy rysować, musimy przechowywać informacje o wcześniejszych stanach obrazu. Zwykle te informacje nie są potem potrzebne użytkownikowi, ale musimy je trzymać w razie nieprzewidzianego wypadku, kiedy jednak będą potrzebne. Informacje te także mogą być przechowywane na dysku, zamiast w pamięci.

Redukcja ilości wykorzystywanej pamięci jest niezwykle ważna, szczególnie na maszynach z niewielką ilością RAMu: jeśli nie przenieślibyśmy danych do przestrzeni wymiany to inne aplikacje użytkownika musiałby to zrobić, co nie zawsze jest pożądane.

Nasza specyficzna implementacja urządzeń rysujących doprowadziła do kilku interesujących przewag nad innymi aplikacjami, takimi jak GIMP. Niestety dla nas (i szczęśliwie dla GIMPa), nasz tytułowy backend był wystarczający by podołać zadaniom, więc nie unowocześnialiśmy go więcej. Jednak, kiedy ostatnio w GEGL zaszły duże zmiany, zaczęliśmy przegapiać niektóre fajne funkcje, które GIMP mógł łatwo zaimplementować (lub nawet już to zrobił). Aby się upewnić, że Krita też potrafi takie rzeczy, powoli przebudowywałem kod naszego starego backendu, tak aby był bardziej elastyczny.

Jedną z ważniejszych kwestii nad jaką pracowałem było poprawienie wydajności backendu odpowiedzialnego za "kafelkowanie" w środowiskach multi-threaded. Nasz stary kod nie najlepszy w tej kwestii. Po przepisaniu kodu mam nadzieję, że będzie on bardziej użyteczny w środowiskach multi-threaded. Do zrobienia ciągle pozostało trochę pracy, ale mam nadzieję, że z nowym kodem będzie to dość proste do zaimplementowania.

Kolejną nowością, która właśnie powstaje jest współdzielenie kafelków. Oznacza to, że wiele urządzeń rysujących może korzystać z jednego kafelka znajdującego się w pamięci. Wcześniej mieliśmy już podstawową implementację "domyslnego" kafelka.

Niestety to podejście nie okazało się zbyt wydajne i nie nadawało się do zastosowania w Krita. Nowy, przepisany kod pozwala na współdzielenie danych kafelka przez kilka narzędzi rysujących.”

Percy Camilo Triveño Aucahuasi opowiada o tym jak został opiekunem KColorEdit:

“Zostałem opiekunem KColorEdit na prośbę Artura Rataja - poprzedniego opiekuna. Aktualnie w projekcie zakończone są następujące zadania:

• portowanie do KDE 4
• wykorzystanie podejścia Model/Widok do wyświetlania kolorów
• dodanie nowych funkcji, takich jak przenoszenie elementów
• poprawki w oknie wczytywania
• poprawki wszystkich błędów z wersji poprzednich

Wszystkie z tych poprawek omawiałem z Arturem i dotychczas był on moim przewodnikiem. Zawsze wysyłałem Arturowi zrzuty ekranu i raporty z aktualnym stanem KColorEdit, a on opowiadał mi co sądzi o zmianach.

Moim celem jest stworzenie użytecznej aplikacji do edycji i tworzenia palet kolorów.

Wprawdzie jest wiele narzędzi, które mają taką funkcjonalność, ale wiele z nich nie jest Wolnym Oprogramowaniem. W GNOME jest Agave, który pomaga w niektórych zadaniach. Wiele edytorów grafiki takich jak Krita, GIMP czy Kolourpaint ma widżety lub okna dialogowe do zarządzania paletą kolorów, ale w KColorEdit zadanie to jest znacznie ułatwione, a wszystkie z tych edytorów potrafią zaimportować pliki stworzone przez KColorEdit.

Aktualnie w KColorEdit można dokonywać tych samych operacji co w poprzednich wersjach, a nawet więcej: można dodawać komentarze do palety kolorów, przenosić elementy, dodawać do palety nazwy, zarządzać dwoma widokami palety i wiele więcej.

W najbliższej przyszłości chciałbym się upewnić, że KColorEdit ma wszystkie funkcje jakie znajdują się w innych narzędziach do tworzenia palety kolorów. Cały czas mam zamiar przesyłać sprawozdania ze zmian Arturowi.

Pod względem technicznym chciałbym, aby KColorEdit zyskał następujące funkcje:

• pobieranie koloru z obrazka, pulpitu i gradientu
• dodawanie linii kolorów do palety: jeśli wybiorę linię jakiejś przestrzeni kolorów, aplikacja automatycznie doda do aplety wszystkie kolory z tej linii. Nie wiem jak bardzo jesteście zorientowani w temacie, ale uwierzcie mi na słowo, że jest to bardzo przydatne.
• tworzenie prezentacji palety, w której będzie można zdefiniować jak dana paleta ma być wyświetlana (poza standardowymi widokami)
• mechanizm Cofnij/Ponów
  
  

Pracowałem nad tą aplikacją około 5 miesięcy i mam kilka komentarzy na jej temat:

• Ta aplikacja (i nie tylko ta) byłaby o wiele łatwiejsza w utrzymaniu, gdyby istniało ujednolicone API odpowiadające za wybór kolorów. Dla przykładu KColorDialog ma tylko osadzony jeden widżet, o wiele łatwiej byłoby gdyby ten widżet był czymś na podobieństwo klasy KColorSelector. Krótko mówiąc powinniśmy zdefiniować ujednolicony interfejs dla wyboru kolorów. Bez tego musiałem po prostu kopiować kod z KColorDialog i KOffice.
• Nie ma klasy "KColor", która opierałaby się na QColor i dodawała własne akcje takie jak pobieranie jasności kolory, konwersję pomiędzy przestrzeniami kolorów, itp. Wydaje mi się, że istenieje klasa "KColor", ale znajduje się w module playground i przez to nie mogłem z niej skorzystać.
• KColorCollection nie obsługuje komentarzy, tylko jedno pole opisu.
• Byłoby fajnie, gdyby wszystkie rzeczy dotyczące palety kolorów korzystały z podejścia Model/Widok. KColorCells i KColorCollection nie korzystają.

Nie widzę także sensu istnienia aplikacji KColorChooser, ponieważ KColorEdit może ją bez problemu zastąpić a nawet ma o wiele większą funkcjonalność. Pisałem w tej sprawie na listę mailingową kde-core-devel, ale nie uzyskałem jeszcze odpowiedzi.

”

Skomentuj ten artykuł na forum KDE »

Ten artykuł jest tłumaczeniem 112 numeru tygodnika KDE Commit Digest.