Pingwinaria Polska Grupa Użytkowników Linuxa

Transkrypt

1 Pingwinaria 2006 Polska Grupa Użytkowników Linuxa

2 Komitet Organizacyjny: Andrzej Boczek Agnieszka Bohosiewicz Krzysztof Leszczyński Konrad Wawruch Program i redakcja: Agnieszka Bohosiewicz Łukasz Bolikowski Krzysztof Leszczyński Konrad Wawruch Projekt okładki oraz pingwiny: Jan Bajtlik Sponsorzy: Zarząd Morskiego Portu Gdynia S. A. Patroni medialni: Wsparcie techniczne: ISBN: ISBN: Wydawca publikacji: Chewbacca Krzysztof Leszczyński

3 Drodzy uczestnicy, Media straszą ptasią grypą. Właściciele kanarków patrzą nieufnie gdy ich pupile kichną, zakrztuszone ziarenkiem prosa. Zatrwożone niewiasty odwracają wzrok na widok klucza ptactwa powracającego na wiosnę. Nikt nie jest bezpieczny. Szczególnie zagrożeni są użytkownicy Linuxa, gdyż pingwin, wbrew pozorom ptakiem jest [1]. W związku z zaistniałą sytuacją, Sztab Kryzysowy Polskiej Grupy Użytkowników Linuxa, dla niepoznaki zwany Komitetem Organizacyjnym, zarządził kwarantannę. Kwarantanna będzie miała miejsce w hotelu Damis, w Krynicy. Mamy nadzieję, że 4 dni odizolowania od czynników zewnętrznych uchroni wielbicieli Linuxa. Aby umilić czas kwarantanny, zaplanowano wiele ciekawych wykładów i prelekcji. Na przykład: Sebastian Zagrodzki opowie, w jaki sposób z miejsca odosobnienia można zadzwonić za darmo. Jacek Konieczny przedstawi sposoby chronienia się przed wirusami. Marcin Sochacki nauczy, jak za pomocą wyszukiwarki firmy Google sprawdzić skład kropli na katar. Krzysztof Leszczyński zdradzi tajemnicę, jak przelać pieniądze za większą porcję aspiryny. W trakcie trwania kwarantanny odbędzie się także konkurs Prezesa. Nagroda jest cenna i bardzo przydatna każdemu, szczególnie w miejscu odosobnienia. Na wszelki wypadek, zwolennicy frakcji bocianiej ( ) odizolowani bedą na osobnym piętrze. W trosce o dobre samopoczucie osób objętych kwarantanną, Sztab Kryzysowy zapewnia swobodny dostęp do chusteczek higienicznych i witaminy C++. W punkcie sanitarnym czekać na uczestników będą płyny odkażające, w przystępnych cenach i bez recepty. Życzymy dużo zdrowia, Sztab Kryzysowy PLUG [1]

4 Kolofon Wszystkie prace związane z przygotowaniem publikacji do druku zostały wykonane wyłącznie w systemie Linux. Skład został wykonany w systemie TEX z wykorzystaniem, opracowanego na potrzeby konferencji środowiska redakcyjnego, opartego na formacie M E X. Teksty referatów złożono krojem QuasiPalladio, opracowanym przez Bogusława Jackowskiego, Janusza Nowackiego i Piotra Strzelczyka na podstawie fontu Palladio, opracowanego przez Hermanna Zapfa i udostępnionego przez firmę URW++. Tytuły referatów złożono krojem Antykwa Toruńska, opracowanym przez Janusza Nowackiego na podstawie rysunków Zygfryda Gardzielewskiego. Autorem ilustracji jest Jan Bajtlik (ur. 1989). O rysowaniu mówi: Lubię rysować. Traktuję to jako zabawę. Poznawanie i odkrywanie sprawia mi przyjemność. Podchodzę do tego z dystansem. Mam dopiero 16 lat i wiem, że jeszcze czeka mnie bardzo dużo nauki i pracy. Wiąże nadzieję, że w przyszłości pójdę drogą artystyczną. Jest również autorem ilustracji w Tygodniku Powszechnym

5 obiad Program Pingwinariów czwartek, 30 marca Organizatorzy Rozpoczęcie kwarantanny Krzysztof Leszczyński Prawą ręką za lewy przelew Radek Kierner Projekt Looking Glass F kolacja RWO Tradycyjne, coroczne spotkanie założycielskie RWO.

6 śniadanie Program Pingwinariów piątek, 31 marca Jacek Konieczny Administrator kontra niechciana poczta F Piotr Książek, Andrzej Oszer OCaml programowanie funkcyjne na co dzień C Jakub Kulesza Plone na tle innych systemów CMS obiad Piotr Książek, Andrzej Oszer Eclipse, narzędzie dla programisty Marcin Sochacki Google jak znaleźć igłę w stogu siana Jakub Kulesza, Piotr Bolek Gentoo Linux powrót do źródeł kolacja Jakub Kulesza, Piotr Bolek Pyskówka dystrybucyjna Łukasz Jachowicz Karaoke

7 śniadanie Program Pingwinariów sobota, 1 kwietnia Kacper Kruszewski, Bartłomiej Zięba Open Adaptor C Sebastian Zagrodzki Darmowe telefony D Mariusz Janusz-Bielecki Stanowisko pomiarowe oparte na RTAI-Linuksie obiad HP HP Control Tower zarzadzanie i implementacja BladeSystem w srodowisku linuxowym Novell Xen and the Art of Virtualization F Grzegorz Jaśkiewicz Linux dla muzyka kolacja Organizatorzy Impreza

8 Program Pingwinariów niedziela, 2 kwietnia śniadanie Łukasz Klimek Implementacja własnych algorytmów kryptograficznych w OpenSSL Organizatorzy Ostatnia kontrola medyczna, zakończenie kwarantanny obiad, dla tych, którzy powiedzieli, że chcą

9 Prawą ręką za lewy przelew Krzysztof Leszczyński Polska Grupa Użytkowników Linuxa Streszczenie: Bardzo często drogie i skomplikowane systemy nie spełniają naszych oczekiwań lub za ich spełnienie każą słono dopłacać. Jeden z bardziej rozpowszechnionych programów księgowych potrafi wydrukować przelew, ale już trudniej jest wygenerować plik przelewu elektronicznego. Istnieje na rynku moduł, który to robi, ale jest drogi, zaś sposób jego użycia redefiniuje pojęcie user-friendliness w sposób, z którego Orwell byłby dumny. Przy pomocy powszechnie dostępnych narzędzi (sterownik postscriptowy Adobe, serwer cups, serwer poczty, skryptu w języku GhostScript) oraz małego programu, można stosunkowo łatwo i bezpiecznie wykonać przelew elektroniczny. Na przykładzie tego konkretnego rozwiązania zostanie zilustrowana ogólniejsza idea: w systemach opartych na GNU mamy do dyspozycji bardzo wiele gotowych klocków, z których czasami łatwo złożyć całkiem ciekawe narzędzie i nie zawsze warto płacić dużo pieniędzy za możliwość kliknięcia jednej ikonki kilka razy w miesiącu, podczas gdy bez płacenia musimy kliknąć w dwie (lub w żadną). Zmartwione szefostwo Instytucja, z którą współpracuję, posługuje się dosyć popularnym pakietem księgowym znanej firmy. Pakiet jest duży, wymaga silnego komputera, księgowość przeszła odpowiednie szkolenia. Wszystko jest ślicznie i zgodnie z ISO Pewnego dnia, Instytucja postanowiła nie nosić więcej do banku przelewów tylko wykonywać przelewy elektroniczne. Decyzja była tym bardziej słuszna, że każdy przelew tradycyjny kosztował 4zł. Przy kilkuset przelewach miesięcznie, generowane były całkiem spore koszty. Bank oczywiście miał swój własny pogląd na wygodę wykonywania przelewów. Przelewy można było robić pod warunkiem dzwonienia przez modem. Wg banku było to znaczącym sukcesem w sprawach bezpieczeństwa, gdyż w Internecie jak wszyscy wiedzą roi się wprost od pedofili i innych wrażych binladenów, zaś linia telefoniczna jest z założenia (wg Banku) bezpieczna. Modem i oprogramowanie do wykonywania bezpiecznych przelewów zakupiliśmy, gdyż było to tańsze niż kłócenie się z obsługą Banku. Kolejny problem powstał przy próbie wysłania przelewu. Bank wymagał pewnego formatu, który, na szczęście, był stosunkowo prosty. Był to CSV, znakami rozdzielającymi były przecinki. Przykład takiego pliku znajduje się na ilustracji 1. Do końca życia nie zrozumiem, dlaczego banki nie pozwalają w przelewach używać tak potrzebnego znaku

10 0A Krzysztof Leszczyński 110, ,389283, ,0," ", " ","Instytut Ziemniakalnictwa i Rzodkiewnictwa ul.~przaśna 3 Bereźnica W yżna", "Jan Nowak," 0, ,"Umów cywilno-prawnych za ","","","51" Rys. 1. Przykład pojedynczego wiersza pliku z przelewami dla banku Rys. 2. Druczek przelewu uzyskany z modułu drukującego przelewy tradycyjne jak przecinek. Format, zawierający cudzysłowy powinien na niego pozwalać. Nic z tego. Bezpieczny system bankowy uważa przecinek za znak rozdzielający nawet jeśli występuje wewnątrz cudzysłowów. Trzeba powiedzieć, że przynajmniej format był jasny i opisany w dokumencie, który Bank dostarczył. Plik z ilustracji 1 powinien zostać zakodowany w Windows z modyfikacją kodów 3 znaków. ISO-9001 najwyraźniej pozwala być bezmyślnie niezgodnym z innym ISO, na przykład z, daleko nie szukając, ISO , że o ISO (Unicode) nie wspomnę. Niemniej, okazało się, że wielki system nijak nie umie wytworzyć czegoś tak prostego jak raport tekstowy w zadanej postaci. System drukował przelewy na drukarkę i już. Kolejne dni minęły księgowości na próbie zmuszenia systemu do wypuszczenia przelewów w jakikolwiek zrozumiały sposób. Nie udało się. Podejrzewaliśmy naiwnie, że skoro wszystkie przelewy są trzymane w bazie danych, zaś baza jest w Microsoft SQL, to może da się wziąć dane bezpośrednio z bazy. Nie. System najwyraźniej używał terminu SQL jako synonimu drogiej i skomplikowanej technologii, za którą trzeba płacić. Dane były w jakimś wewnętrznym (niewątpliwie bardzo bezpiecznym) formacie. Zadzwoniliśmy do producenta. Pan przedstawiciel handlowy uspokoił nas stwierdzeniem, że istotnie, nie da się wydobyć tych przelewów. Można natomiast zakupić moduł, robiący pliki dla banku. Kosztować to będzie zł jednorazowo oraz dodatkowo abonament miesięczny. Wychodziło około 1000zł miesięcznie. Taniej niż płacić za każdy przelew, ale i tak nieakceptowalnie drogo program miał przecież wyłącznie produkować prosty plik tekstowy. W rozpaczy, Instytucja rozważała zatrudnienie (za mniej niż 1000zł) osoby, która te wszystkie wydrukowane przelewy będzie przepisywać.

11 Prawą ręką za lewy przelew 0B [przelewy] comment = Pseudodrukarka drukuje przelewy do banku path = /var/spool/samba guest ok = No printable = Yes printing = lprng print command = /opt/przelewy/bin/przelewy.lp %s lpq command = /bin/echo -e "Przelewy is ready\nno entries" printer name = przelewy browseable = No Rys. 3. Przepisywanie przelewów Prosta konfiguracja pseudodrukarki pod Sambą System, po wykonaniu polecenia drukuj przelewy wyrzucał do systemu drukującego coś podobnego do ilustracji na rysunku 2. Gdyby się udało automatycznie przeczytać taki przelew, byłoby dobrze. Istniejące programy typu OCR niestety się nie nadają. Każdy proces OCR, dostępny popularnymi programami, zakłada współpracę z człowiekiem. Poza tym pomyłki w numerze konta mogłyby zostać niezauważone, a miałyby skutki gorzej niż opłakane. System chodzi pod Windows, ale od czego mamy Linuxa z Sambą! Samba umożliwia dosyć wygodne przechwytywanie wydruków; strumień bajtów z programu drukującego zostaje zapisany do pliku tymczasowego, po czym zostaje wykonany na nim program niekoniecznie drukujący. Pierwszym testowanym pomysłem było użycie sterownika o nazwie Line Printer by wszystko dostać w tekście. Eksperyment zakończył się porażką. Poza informacją o błędzie w aplikacji i zawieszeniem całego systemu księgowego, nie udało się uzyskać nic więcej. Należało się tego spodziewać narysowanie druczku przelewu wymaga od drukarki większych możliwości niż drukowanie plików ASCII. Kolejny pomysł, to skorzystanie z jednego z wielu dostępnych sterowników języka PostScript. Niestety, standardowe sterowniki Windows, oparte o GDI produkują dane do wydruku w sposób dosyć trudny do późniejszej analizy. Dość powiedzieć, że na ogół zwykły windowsowy Arial jest zwykłym Arialem dla liter łacińskich oraz podstawioną bitmapą dla liter polskich. Gdyby instytucja postanowiła zapłacić wynagrodzenie osobie o nazwisku Żółw, jego postać wydrukowana, wyglądałaby w powiększeniu jak.... Widać, że Ż oraz ł zostały zbudowane z bitmap, zaś ó oraz w są wzięte z fontu Arial. To zachowanie jest częściowo zrozumiałe, sterownik nie może zakładać, że fonty zawarte w drukarce mają znaki spoza alfabetu łacińskiego. Język PostScript miał być, w założeniu, bardzo przenośnym standardem. I rzeczywiście, wiele sterowników, w tym TEX-owy dvips lub sterowniki dostępne pod popularne dystrybucje Linuxa produkują PostScript, który może działać z niemal każdą drukarką postscriptową. W świecie Windows sprawa wygląda inaczej. Niemal każdy sterownik do drukarki produkuje coś, co wygląda na PostScript, ale jest nim tylko do pewnego stopnia. Na przykład zawiera rozszerzenia wspierane przez konkretny model. To oczywiście bardzo utrudnia automatyczną analizę takiego kodu.

12 0C Krzysztof Leszczyński Sterowniki Adobe Na szczęście firma Adobe, opiekun języka PostScript, wydała komplet sterowników na różne systemy i drukarki, które produkują poprawny PostScript. Konkretne pliki wynikowe są produkowane w oparciu o informacje w plikach PPD (PostScript Printer Definition). Nam zależało na zachowaniu jak największej ilości informacji logicznej w pliku PostScript, bez tłumaczenia jej na fizyczne obrazki, dlatego zdecydowaliśmy się użyć sterownika wraz z PPD od drukarki Adobe Distiller. Sugerowaną przez Adobe metodą produkcji plików PDF jest pędzenie ich z plików postscriptowych przy użyciu pakietu Adobe Distiller. Destylować można niemal każdy PostScript, ale jeśli, na przykład litery będą przedstawione jako obwiednie, a nie polecenia drukujące znaki, to wynikowy PDF, będzie obrazkowy, a nie tekstowy. Nie będzie można, z nim wykonać operacji kopiuj-wklej. Na szczęście w wypadku przelewów były znaki, a nie obrazki. Analizujemy plik PostScriptowy Postscript jest językiem podobnym do języka Forth. W książce [1] znajduje się jego wyczerpujący opis. Do celów referatu przedstawię kilka najważniejszych cech języka. Cała semantyka PostScripta jest utkana na pojęciu stosu. Argumenty procedur kładzie się kolejno na stosie, procedury zdejmują ze stosu odpowiednią liczbę argumentów, wykonują na nich operacje i kładą wynik z powrotem na stosie. Mnożenie 2 razy 2 zapisujemy jako 2 2 mul Procedury również definiujemy kładąc je na stosie, w dodatku każdą operację podstawową można przedefiniować, nawet mul. (mul) % Połóż na stosie napis "mul" {add 3 add} % Treść procedury: x + y + 3, gdzie x i y są argumentami def % operacja def Ostatnia operacja(def) oznacza zdejmij ze stosu symbol (mul) oraz ciało procedury i przypisz procedurę symbolowi. Wynik zmodyfikowanego działania 2 2 mul i metody jego obliczania są szeroko omówione w [2]. Wypisywanie tekstu jest realizowane przez procedurę show. show przyjmuje jeden argumentami łańcuch do wypisania, kształt, font, kolor, wielkość, orientacja przestrzenna napisu zależy od stanu. Kod moveto (Ala ma Asa) show wypisuje napis w odległości w położeniu (72 pkt, 72 pkt) od początku układu współrzędnych, czyli na ogół od lewego dolnego brzegu kartki. Jednym z parametrów stanu jest położenie kursora (72pkt,72pkt). Procedurę show można również przedefiniować. Zamiast rysować odpowiedni napis, może ona wypisywać zawartość napisu wraz z informacjami o położeniu. W ten sposób analiza kodu postscriptowego jest dokonywana samym PostScriptem i to niezależnie od tego jak bardzo byłby on zakodowany, osadzony w załącznikach do EPS-ów i obrócony. Odpowiednikiem funkcji print, znanej w większości języków jest funkcja, o krótkiej nazwie = (znak równości). Wystarczyłoby zatem show zastąpić prostą definicją /show {(BeginString) = currentpoint = = = (EndString) =} def Pierwszy = wypisywałby znacznik początku, kolejne dwa = = położenie (x, y)

13 Prawą ręką za lewy przelew 0D 1 a4 % Ustawmy rozmiary papieru, żeby ustalić współrzędne 2 /M matrix currentmatrix def % zapamiętajmy transformację 3 /show {/show showlike } def 4 /ashow {/ashow showlike } def 5 /showlike { 6 (\n\nbeginstring) = 7 % pisz współrzędne początku napisu (bez transformacji) 8 [ currentpoint transform M itransform ] == 9 % Poniższa pętla wypisuje symbolicznie kolejne znaki niezależnie 10 % od ich położeń w wektorze kodowania znaku 11 exch dup 12 {currentfont /Encoding get exch get == } forall 13 % wykonaj oryginalną operację show lub ashow 14 exch systemdict exch get exec 15 % pisz współrzędne końca napisu 16 [ currentpoint transform M itransform ] == 17 (EndString\n) = 18 } def Rys. 4. Redefinicja operatorów show, xshow, ashow zwrócone przez funkcję currentpoint, kolejny właściwy napis i na końcu znacznik "EndString". Takie podejście ma 4 wady 1. znamy współrzędne początku napisu, ale nie jego końca; 2. współrzędne są w lokalnym układzie (który się może zmieniać z napisu na napis), a nie w układzie kartki. 3. nasza procedura nie zmienia położenia kursora po wypisaniu napisu, ponieważ go tak naprawdę nie rysuje; funkcja zachowuje się inaczej niż się tego spodziewa opis strony; 4. kodowanie napisów postscriptowych niekoniecznie musi przypominać ISO-* lub nawet ASCII. O ile pierwsze trzy wady są w miarę oczywiste, czwarta wyszła w praniu, gdyż okazało się, że sterownik stosuje losowe kodowania znaków; zapewne w celu lepszego upchania różnych egzotycznych znaków. Nawet przy takim utrudnieniu, poprawiona procedura przedstawiona na rysunku 4 wygląda całkiem prosto. I działa! Pozostaje nam tylko zinterpretować wynik działania. Znaczniki BeginString i EndString pozwalają skryptowi analizującemu pomijać różne napisy, które programy, sterowniki i interpretery potrafią po drodze wypisywać. Napis Opłata:, znajdujący się na dole formularza przelewowego zostanie przetworzony na ciąg 1 BeginString 2 [ ] 3 /O 4 /p 5 /lslash 6 /a 7 /t 8 /a 9 /colon 10 [ ] 11 EndString 12 Ten ciąg jest na tyle prosty, że napisanie w ulubionym języku parsera jest prostym zadaniem. Pozostaje pozaznaczać prostokątne obszary, w których występują interesujące nas napisy. Najlepiej zdefiniować wszystkie obszary, również te, w których

14 0E Krzysztof Leszczyński występują napisy nie niosące informacji, jak wymieniony napis Opłata:. Można to robić ręcznie, przy pomocy przeglądarki postscriptowej, na przykład programu gv, który pokazuje współrzędne kursora. Można również półautomatycznie. Należy w tym celu wyłapać przy pomocy odpowiednich redefinicji wszystkie operatory show, ashow, awidthshow i kilka pozostałych używanych do rysowania łańcuchów tekstowych na stronie. Każdemu można przypisać prostokąt na stronie, następnie obliczyć teoriomnogościową sumę zachodzących na siebie prostokątów. Otrzymana rodzina rozłącznych figur może posłużyć do przypisywania znalezionym tekstom konkretnych znaczeń. Tekst poza prostokątem oznacza błąd, co może posłużyć jako dodatkowy test. Podsumowanie Nad przedstawionym rozwiązaniem pracowaliśmy około 4 dni. Od tej pory dział księgowości wykonuje przelewy od 2 lat bez (odpukać) zgłaszania nam jakichkolwiek błędów. Ewidentne jest, że nie było sensu kupować drogiego rozwiązania. Oczywiście, może się zdarzyć, że oprogramowanie zacznie generować niepoprawne dane, ale również bardzo często widzimy ewidentne błędy w programach dużych firm, kto nie wierzy, niech przeczyta choćby Slashdota [3] z dowolnego miesiąca. Dalej będzie politycznie Czytelnicy, którzy mają dość polityki linuksowej mogą nie czytać dalej, będzie o naiwnej i nie mającej szans powodzenia inicjatywie ustawodawczej. Od wielu lat trwają starcia o patenty na oprogramowanie. Poglądy z grubsza kształtują się od żądań opublikowania źródeł wszystkiego z jednej strony do twierdzeń, że Linux oraz GPL są rakiem [4] z drugiej strony. W gorączce dyskusji, zapominamy często o innym aspekcie: danych. Większość programów, używanych w przemyśle trzyma nasze w zamkniętym formacie. Najbardziej znanym i jątrzącym przykładem jest ZUS-owski Płatnik. Przy umiejętnie skonstruowanej umowie, klient zostaje zakładnikiem producenta oprogramowania. Nie może zrezygnować z jego usług, gdyż swoje własne dane, często wiele lat krytycznie ważnych danych księgowych może być przetwarzane tylko pewnym konkretnym oprogramowaniem. Gdybym był posłem, wystąpiłbym z inicjatywą ustawodawczą nakazującą producentom przygotowanie obowiązkowej dokumentacji do używanych formatów przechowywania i protokołów wymiany danych sprzedawanego oprogramowania. Ponieważ posłem nie jestem, mogę sobie jedynie napisać referat na Pingwinaria. Literatura [1] PostScript Language Reference Manual Adobe Systems Incorporated, 1991 [2] Maszyna Trurla, z tomu Cyberiada Stanisław Lem, Wydawnictwo Literackie, [3] Slashdot News for nerds, stuff that matters [4] Slashdot: Ballmer Calls Linux A Cancer

15 Project Looking Glass: A Comprehensive Overview of the Technology Hideya Kawahara Paul Byrne Deron Johnson Radosław Kierner Project Looking Glass Sun Microsystems, Inc Introduction Project Looking Glass (LG3D) is an open source project to explore a richer user experience to the desktop and to applications, through 3D windowing and visualization capabilities. It exploits significantly improved 3D graphics rendering capability of today s PCs, which was not available when many of the foundations of today s desktop system were designed. This article covers Project Looking Glass overall design, main features, simple code examples, and quick review of LG3D effects and applications. It will provide you an understanding of LG3D s high level architecture and the APIs, as well as where further development contributions are needed. Because Project Looking Glass is a work in progress, the details specified in this article are subject to change. The APIs are not final but are continuously evolving. Suggestions for improvement are invited via the LG3D discussion forum.

16 10 Hideya Kawahara, Paul Byrne, Deron Johnson, Radosław Kierner 2. Background Screenshot 1. 2D and 3D Applications in LG3D LG3D breaks past two boundaries in the world of user experience design: the 2D-ness of current desktop environments, and the way in which these desktop environments evolve. At a very high level, the project focuses on providing a solid platform for the exploration of the 3D desktop environment. 3D window managers and applications with creative ideas are being implemented on top. We released the LG3D code to the whole community to explore every aspect of the technology rather than restricting access to a privileged few. We believe open development is an excellent model to pursue this exciting and vast opportunity. At the same time being a platform for the3d exploration, it is not just a research platform. In order to make it close to real-life deployment, the platform supports unmodified existing applications in a 3D space and an experimental 3D window manager with 3D windowing capabilities (Screenshot 1). At the moment, existing application integration is supported for Linux and Solaris x86 platforms. The platform for 3D application development is available for Linux, Solaris and Windows platforms. 3. High Level Design Goals The LG3D platform was developed from scratch while reflecting things we learned from its proof-of-concept demo implementation (the Phase 0 implementation of LG3D). The feedback from the proof-of-concept demo trial indicated that the following four aspects were keys of the success of the trial: (1) Existing 2D application integration, (2) Two-and-half-dimension user experience that keeps similarity with today s desktop environment while adding value leveraging 3D space, (3) Rich and natural user feedback, (4) Attention to visual representation.

17 Project Looking Glass: A Comprehensive Overview of the Technology 11 We also learned that 3D desktop UI is completely new area and requires lots of further experiments. Taking account of all of these, we defined the following design goals for the refined implementation: High productivity to support aggressive 3D exploration Solid platform for use in future products High performance and scalability Powerful 3D capability support Existing 2D application integration Framework to support two-and-half-dimension window manager Rich set of componentized libraries Rich user feedback based on animation Support for visual designer oriented tool chain 4. Design Approach In order to achieve the design goals described in the previous section, the following features have been, or to be, supported: Java Technology-based APIs and Implementation Built on Top of Java 3D Technology Model Loader Integration Client-server Scene Graph Server-side Behavior Execution Generic Event System Event Adapter and Animation Components Componentized Scene Manager Existing Application Integration Abstraction Layer Swing Integration for 2D Widget Set Support 4.1 Java Technology-based APIs and Implementation Java technology is the primary development language because of the productivity gains it brings, its language safety features, and the rich set of supporting APIs it provides. These benefits promote more aggressive exploration of the new 3D desktop frontier. Also, thanks to serious commercial use in the server space, its performance has been improved significantly. Our proof-of-concept demo proved that its performance has little concern for our use. Although currently only Java APIs are provided, in the future, C++ bindings will also be provided so that existing native applications can access the features of the LG3D platform. 4.2 Built on Top of Java 3D Technology The LG3D API and implementation leverage the Java 3D technology. In addition, LG3D provides additional features including a component architecture and an animation system in order to simplify writing rich user-experience applications. Java 3D is a matured Java based technology for high-quality, scalable, platform-independent 3D rendering, initially introduced in The Java 3D

18 12 Hideya Kawahara, Paul Byrne, Deron Johnson, Radosław Kierner API provides a set of object-oriented interfaces that support a simple, high-level programming model that can be used to build, render, and control the behavior of 3D objects and visual environments. At the same time, it fully takes advantage of hardware 3D rendering acceleration when available. Being built of top of it, the platform can leverages all the above favorable features. In addition, we can leverage all the accumulated resources including tutorials, books and libraries, like 3D model loaders. This helps the platform to be productive development environment at the same time being solid and highly scalable. Although the platform is built on Java 3D, a decision has been made to expose a subset of the Java 3D API to the client side. Features that complicates implementation has been removed. All the methods deal with type double have also been removed or replaced with float versions. This leaves possibilities to run the same client application program in a resource limited environment like a set top box or car navigation system in future. 4.3 Model Loader Integration Support for model loaders is considered a key feature of LG3D technology, as it brings visual designers into the development loop. A special LG3D component named ModelLoader has been introduced for that purpose. It provides a simple yet powerful mechanism to load a 3D model from a file and bring it into the LG3D environment. It supports many formats using the Java 3D s model loader mechanism. 4.4 Client-server Scene Graph The client-server scene graph allows multiple processes to share the same virtual 3D universe. This technology also allows the platform to execute an LG3D-aware 3D application in a separate process (even on a remote machine), while it displays a 3D user interface integrated within the single virtual universe with which the user interacts. Like the X client-server model, this enables clean isolation among applications and the platform. This feature is still in an early stage of development, and is not fully implemented. Note that Client-server here does not imply client and server machines connected through a network but rather processes typically running on the same machine. A client is an application that issues requests to render its user interface. Typically, the machine runs a single server that receives rendering requests from clients and constructs the screen image. 4.5 Server-side Behavior Execution Animation typically operates on a scene graph per frame. A mechanism to execute animation on the server side is provided, so that client and server do not need to communicate per frame. The client specifies types of animation with parameters, such as duration. The platform provides several predefined animations. In addition, animation can be realized by leveraging animation support in model loaders. With those features, the limitations imposed by server-side behavior (e.g. difficulty of client-specific behavior installation) is not considered critical. This feature is not fully implemented at this moment.

19 Project Looking Glass: A Comprehensive Overview of the Technology Generic Event System Rich user feedback and componentization of the library were two key requirements for the platform. In order to implement rich user feedback, lots of state and event information need to be passed across the system, which can result in tying up platform components too tightly if we solely relay on method invocation. An asynchronous generic event system is supported at the platform level in order to decompose library features into smaller pieces that interacts each other in a loosely coupled fashion. 4.7 Event Adapter and Animation Components Based on the feedback from the proof-of-concept demo trial, rich user feedback was identified one of the key feature to focus. The most frequently exercised call path to implement user feedback is receiving pointing device event and performing animation, like scaling up a button when the mouse moves onto it. The platform introduced abstraction interfaces called EventAdapter and Action. These disengage the event receiver code and the animation implementation. This enabled a rich set of components those can be hook up together to achieve a customized feedback with less coding. Details of the API are discussed in Section 6.3. In future, an event driven animation system with simple behavior composition will be introduced. It will allow developers to hook up the components without coding. 4.8 Componentized Scene Manager The Scene Manager takes over the role of window manager for a 3D scene, since typical LG3D-aware 3D application user interfaces have unique shapes not limited to a window shape. The Scene Manager interacts with the user and applications. It implements management policy for applications running in the environment and is responsible for arranging those in the 3D space. In order to stimulate many ideas, an initial framework for componentized Scene Manager technology has been provided. In the implementation, attention has been paid to two-and-a-half dimension as well as full three dimension experiences under the same abstraction. The following list shows the key Scene Manager components: Application Container, Background, Global Lights, and Taskbar (Figure 1). Efforts has been paid to support two-and-half-dimension as well as full 3D experiences under the same abstraction. 4.9 Existing App Integration Abstraction Layer In order to make LG3D available on different type of underlying platform, an abstraction layer for existing application integration has also been implemented. The abstraction layer can be roughly divided into two major areas: the Foundation Window System (FWS) module, and the Native Window representation module. The FWS module provides the integration with the underlying window system, including application visual capture and event delivery integration. The module includes a set of interfaces for implementation of different kind of plug-ins for a native window system. Currently there are two implementations, the X11 version and the AWT version. The X11 integration allows X applications to be run and displayed within the LG3D

20 14 Hideya Kawahara, Paul Byrne, Deron Johnson, Radosław Kierner Figure 1. Major Components of Scene Manager platform. The AWT version allows the platform to run LG3D on operating systems that support required Java platform and Java 3D extension versions (such as Solaris and Windows), but without support for native application integration. The Native Window representation module sits on top of the FWS, and provides abstracted representation of the native window application s visual aspects in the 3D space Swing Integration for 2D Widget Support Based on the experience of LG3D application development using the preliminary API, and strong requests from the community, it became more clear that a mechanism to allow developers to use Java s Swing API is significantly important. Even while developing a 3D application, sometimes 2D UI components makes sense. Examples include a file dialog window and text input output fields. Instead of introducing a whole new set of APIs, LG3D provides a mechanism to incorporate Swing widget into its 3D environment. A special LG3D component named SwingNode has been introduced for that purpose. It is a LG3D node to which developers can attach Swing s JPanel. Developers can constract a Jpanelusing the regular Swing API, attach it to a SwingNode, then attach the SwingNode to 3D application s scene graph. In this way, the 2D Jpanel appears in LG3D s 3D space and the 3D application can perform operations using 3D coordinates, just like a regular LG3D component. 5. High Level Architecture The LG3D platform s high-level architecture is illustrated in Figure 2. It consists two major parts: the X11 integration and the LG3D-aware application support mechanism. The right side of the figure shows the X11 integration mechanism. An unmodified X Client Application communicates with the X Server, which is enhanced with the X Client Capture and other functionalities. This enhanced X Server captures the client s visual representation and sends it to the LG3D Display Server, which manages rendering of the 3D space, using the Java 3D platform. All of the enhancements are bing integrated into the X.org s X server and will be available by default.