Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Plasma Active: Quick

W moim poprzednim wpisie (Plasma Active - nowy interfejs twórców KDE) opisałem ogólną koncepcję nowego interfejsu tworzonego przez deweloperów plasmy. Dzisiaj chciałbym sie skupić na jednym z jego podstawowych elementów - Plasma Quick

Plasma teraz

Każdy kto choć miał przelotną styczność z KDE widział jego zewnętrzny "przejaw" czyli pulpit plasmy oraz jego elementy. W zasadzie wszystkie częsci pulpitu KDE to właśnie plasmoidy. A co najważniejsze każdy z tych elementów, możemy niemal dowolnie zmieniać, przesuwać, czy zastąpić czymś innym. To wszystko decyduje o niemal nieograniczonych możliwościach dostosowania do własnych potrzeb. Coś o czym pozostałe środowiska mogą tylko pomarzyć.

Obecnie mamy dostępnych setki rożnego rodzaju plasmodiów, napiasnych przy pomocy różnorodnych języków programowania, począwszy od qt (c++) a na pythonie czy rubym skończywszy. Jednak co jest najciekawsze, elementy plasmy dostosowują się do urządzenia na którym działają w myśl zasady jeden pakiet - wiele interfejsów.

Plasma Quick

Plasma Quick ma na celu rozwinięcie i ulepszenie dotychczasowej koncepcji. Ma ją przede wszystkim cechować:

Wydajność

Stabilność

Możliwość użycia na wielu urządzeniach

Innowacyjny interfejs użytkownika

Elementem końcowym ma być plasma 2

Prosto do celu z Quick

Wraz z wersją KDE 4.6 plasma zyskała możliwość tworzenia nowych elementów za pomocą Qt Quick. Quick jest do ogólna nazwa dla QML. W skrócie jest to skryptowy język programowania, wykorzystujący możliwości Qt, którego głównym celem jest tworzenie atrakcyjnych wizualnie interfejsów użytkownika. Co najważniejsze ma być szybko, łatwo i wydajnie. Ile z tego to tylko marketingowa zagrywka a ile prawda, nie mnie oceniać. Jedno jest pewne deweloperzy plasmy chcą go wykorzystać w swoim projekcie.

Nudna robota

Aby osiągnąć założone cele w 100% wszystkie elementy plasmy muszą zostać przepisane przy użyciu QML. Jednak nie nastąpi to z dnia na dziej dlatego w okresie przejściowym będziemy mieli pewien mix elementów. Co jednak najważniejsze zarówno stare plasmoidy jak i nowe napisane w QML mogą koegzystować ze sobą niemal w sposób transparentny dla użytkownika. Dlatego unikniemy sytuacji z przejścia z KDE 3 na KDE 4, gdzie cały proces był co najmniej burzliwy.

No dobra a co będzie miał z tego typowy użytkownik PC ?

Ano może być tylko lepiej, skoro głównym celem deweloperów są urządzenia mobilne, jasnym jest, że całość będzie musiała działać płynnie, a przy okazji być atrakcyjna wizualnie.

Więcej informacjihttp://aseigo.blogspot.com/2011/04/plasma-active-quick.html 

Komentarze

0 nowych
nintyfan   11 #1 16.04.2011 09:59

Z tego, co wyczytałem, to libplasma2 ma być niekompatybilna z libplasma. Nie wydaje mi się, by wszystkie dotychczasowe plasmoidy działały.

QML jest chyba bardzo zbliżony do JavaScript. Warto odnotować, że Plasma także obsługuje plasmoidy napisane w JavaScripcie.

nintyfan   11 #2 16.04.2011 11:46

Muszę przyznać, że rezultaty użyte w Plasma Quick w związku z renderowaniem wszystkiego z użyciem akceleracji sprzętowej(niby takie 3D) są imponujące.

BenderBendingRodriguez   6 #3 16.04.2011 12:48

Dodałbym jeszcze że plasmidy w QML korzystają z przyspieszenia sprzętowego (OpenGL ES zdaje mi się) tzn. wyświetlanie jest wykonywane głównie przez kartę graficzną, niestety z tego co wiem to nie przepisano QGraphicsView żeby korzystało z QMLowego scene graphu.

lucas__   13 #4 16.04.2011 21:39

nintyfan

Masz rację, ale tylko w części, twórcy chcą stopniowo przepisywać wszystko w QML, tzn przez pewien czas będziemy mieli taki okres przejściowy gdzie plasmoidy w qml będą sobie bezproblemowo działać ze starymi. Ale gdy już większość zostanie przepisana to wtedy będziemy mówić o liblasma 2, niekompatybilna z liblasma - jak słusznie zauważyłeś

BenderBendingRodriguez

Zgadza się, ale z tego co czytałem na blogu Seigo mogą również działać bez użycia opengl, oczywiście wolniej. Co jednak nie zmienia faktu, że liblasma 2 będzie wymagała composite i odpowiedniej wersji opengl. (Jednak to zapewne okres co najmniej 2 lat zanim to w pełni nastąpi). Dla porównania GS wymaga composite już dziś czy Unity

nintyfan   11 #5 17.04.2011 11:56

Zespół KDE wykonał naprawdę niesamowitą pracę - system renderowania, który działa wydajnie i omija wszelkie bugi w sterownikach, jak i w sprzęcie, a do tego może korzystać z wielu backendów, m.in XRender. Chęć wymagania obsługi odpowiedniej wersji OpenGL może zaburzyć tę sielankę.

nintyfan   11 #6 17.04.2011 11:57

Wyżej pisałem raczej o KWin niż Plaśmie, ale i tak nadciągają chyba ciemne chmury. Plasma już dziś obsługuje efekty/animacje, i to wydajnie.