Plasma Active 3 uruchomiona na tablecie Nexus 7

Plasma Active 3 uruchomiona na tablecie Nexus 7

przez -
14 492
Plasma Active
Deweloperzy KDE uruchomili interfejs Plasma Active 3 na tablecie Nexus 7. Jako podstawę użyto systemu Mer, który jest specjalnie zoptymalizowaną dystrybucją MeeGo, przystosowaną do pracy na urządzeniach mobilnych. Plasma Active posiada znakomitą integrację z nim, dzięki użytym technologiom webowym: HTML5, QML i JavaScript.

System działał w miarę stabilnie, jednakże nadal trzeba popracować nad pewnymi niedociągnięciami, które się pojawiły. Należy zaznaczyć, że wcześniej próbowano uruchomić na tym tablecie Ubuntu z Unity, ale jego obecna forma kompletnie nie nadaje się na urządzenia dotykowe, ze względu na brak optymalizacji pod nie.

Podobne artykuły

Plasma Active

przez -
10 562
  • marcinsud

    "próbowano uruchomić na tym tablecie Ubuntu z Unity, ale jego obecna forma kompletnie nie nadaje się na urządzenia dotykowe, ze względu na brak optymalizacji pod nie."

    I nie ma się czemu dziwić, bo unity zostało zrobione pod wygodną obsługę klawiaturą, a nie palcami. No, ale jakby nie było na dobre wyszło i w oficjalnym repo jest paczka z podstawową konfiguracją ubuntu desktop pod nexusa, więc jak ktoś chce eksperymentować to droga wolna.

  • Ubuntu na Nexus 7 jest oficjalnym wydaniem Canonical, ale nie po to aby używać Unity, jest to wydanie dla developerów, zrobili to aby testować na tym urządzaniu różne aspekty mobilności i zarządzania energią. http://go.nibyblog.pl/Svh4v2

  • marcinek

    Czy to znaczy, że można kompilować kod w C++ do natywnych binariów a nie do bytecode?

    • marcinek

      W sensie zamiast Javy.

    • mikolajs

      Chciałeś powiedzieć, że można używać C++ zamiast Javy? Można, chociaż zastanawiam się w jakim stopniu pisze się na to aplikację w JavaScript.

    • pijaczek

      Możesz jaśniej? Można pisać kod natywny w C++ na MeeGo, bo to normalny Linux. Ale to jest naturalne podobnie jak możesz pisać natywne programy w C++ na Androida i większość gier oraz wiele programów tak na Androida robi.

    • marcinsud

      W Androidzie też możesz kompilować do kodu natywnego (NDK), ale jest to niezalecane do całych programów. Problemem jest to, że ARMy są zgodne tylko w dół i trzeba później dostarczać x wersji tego samego, lub nie korzystać z dobroci najnowszych architektur. Masz też 'normalne' Qt na Androida jakbyś bardzo chciał unikać javy.

    • pijaczek

      Niezalecane jest z innego powodu (C wymaga większej wiedzy i łatwiej o błędy, wycieki pamięci itp. a Google woli mieć sprawne aplikacje w sklepie, a nie wysypujące się – twórcy większości aplikacji mobilnych to nie mistrzowie klawiatury).
      ARM są niezgodne tak jak i nie są zgodne procesory x86 – nie możesz użyć AVX na sprzęcie bez tych jednostek lub instrukcji SSE4 na procesorze go nie obsługującym, kod 64bitowy też na 32bitowym x86 nie uruchomisz. Jednak Google przygotowało fajne api runtime (cpufeatures), które możesz zapytać na jakim procesorze uruchomiłeś kod i z jakimi możliwościami i decydować który kod ma wykonać (instrukcje NEON, SSE itp.), co więcej NDK jest przystosowane do tego, żeby jeśli napiszesz dobrze kod automatycznie generować wersję na wszystkie obsługiwane platformy bez twojej interwencji automatycznie. Wystarczy, że ustawisz "APP_ABI := all", a skompiluje kod na armv6 (wiele programów odpuszcza już te procki – kod armv6 działa też na armv7), na armv7 (ten na armv6 nie zadziała, ale będzie lepiej zoptymalizowany dla v7), dla x86 i dla mips. W NDK dodatkowo masz kilka kompilatorów i możesz zdecydować spośród kilku wersji GCC lub CLANG (LLVM).

    • prof T'alent

      Chyba raczej chodzi o to, że w NDK nie masz wszystkich API do komunikacji ze sprzętem. Najlepiej co się w tym robi to obliczenia i obsługa OpenGL ES.

    • pijaczek

      Jak nie? Masz OpenSL ES do dzwięku, masz api do sensorów czy dotykowego ekranu, masz OpenGL ES do grafiki, masz OpenMAX AL do sprzętowego dekodowania dźwięku i obrazu… do pobierania obrazu z kamery jest większy problem, bo NDK samo nie dostarcza takiego API, ale masz OpenCV (stworzone API przez Intela popularne na PC, a obecnie pod nazwą Vision jest rozwijany w Khronos Group jako przyszły standard tej grupy obok flagowych OpenGL, CL itp.) dla Androida NDK, więc wielkiego problemu nie ma.
      Najgorzej to właśnie z tymi obliczeniami (niekoniecznie na CPU). Pod Javą w SDK masz RenderScript, a Google nie udostępniło jeszcze api NDK OpenCL.

      Niewiele sprzętu nie możesz obsługiwać pod NDK – przykładowo telefon, GPS (chociaż może jest jakaś biblioteka natywna gotowa do dołączenia do projektu NDK komunikująca się z Dalvikiem tylko po współrzędne GPS). Już bardziej można się denerwować na braki w dostępie do androidowego świata (korzystanie z ustawień, powiadomień, książki adresowej…), bo aplikacje NDK są oderwane od ekosystemu androidowego (idealnie pasuje NDK do gier, ale w innych sytuacjach może być to problem).

    • prof T'alent

      Dziękuję zatem :)
      Dawno tam nie zaglądałem, ale cieszy że się rozwija.

  • damek

    Fajnie byłoby zobaczyć GNOME Shell w akcji na takim tablecie…

  • ar.ba

    Czy QML to technologia webowa to bym się spierał. No i z wikipedii, nawet polskiej, wyczytałe, że MeeGo już właśnie jest dystrybucją optymalizowana na urządzenia mobilne.

    • prof T'alent

      Bo QML w żądnym stopniu nie jest webowe (XAML i GLADE też są? ;]). No chyba, że chodzi o to, że aplikacja może sobie ściągnąć widok z netu po http ;-)).