SWT (biblioteka)
 |
Ten artykuł wymaga dopracowania zgodnie z zaleceniami edycyjnymi. Należy w nim poprawić: Usunąć potoczne zwroty i zredagować polemikę. Dokładniejsze informacje, co należy poprawić być może znajdziesz na stronie dyskusji tego artykułu. Po naprawieniu wszystkich błędów można usunąć tę wiadomość. |
SWT (The Standard Widget Toolkit) jest biblioteką graficzną dla środowiska Java, stanowiącą alternatywę dla standardowych bibliotek Javy: AWT i Swing. Biblioteka ta jest rozwijana na zasadach open source przez Fundację Eclipse. Ideą projektu jest, aby wygląd komponentów graficznych i ich zachowanie (standardowe skróty klawiaturowe, reakcje na działania myszy) było w pełni zgodne z komponentami typowymi dla danego systemu, a ich prędkość nie odbiegała od natywnego interfejsu. SWT jest wykorzystywana jako podstawowa biblioteka graficzna środowiska Eclipse.
[edytuj] Zalety i wady
W praktyce SWT to kod Java który za pomocą JNI otacza komponenty zdefiniowane na danej platformie i dostarcza interfejs wspólny dla różnych platform.
Rozwiązanie to ma zalety:
- Komponenty są szybsze w użyciu (i tak trzeba ocenić samemu)
- Po stworzeniu biblioteki SWT dla danej platformy, zwykle nie ma problemów ze zgodnością z nowymi wersjami systemu operacyjnego (np. SWT dla Win32 działa na Windows Vista, a Swing musi mieć od nowa napisany Look&Feel)
- SWT istnieje dla każdej znaczącej platformy i ma mniejsze wymagania niż Swing (zwłaszcza pamięciowe)
- SWT jest prostsze w użyciu niż Swing (dyskusyjne: np. nie wymaga stosowania MVC, ale trudno tworzyć własne skomplikowane komponenty w porównaniu do Swing)
- Aplikację korzystającą z SWT można skompilować do kodu natywnego (ułatwia to rozprowadzenie oprogramowania, ponieważ program ma mniejsze wymagania (bo nie uruchamia się JVM, jest w pełni natywny) i nie potrzebuje JRE, ale przeczy to idei Javy)
- Posiada kilka zaawansowanych komponentów[1] więcej niż Swing (Tray Icon (będzie też w J2SE 1.6),Tree z możliwością dodawania kolumn, Expand Bar, komponenty C****)
Rozwiązanie ma również wady:
- Trzeba samemu zatroszczyć się o zwalnianie zasobów (funkcja dispose())
- Rozwiązanie w większych projektach prowadzi do bałaganu, ponieważ SWT nie wymaga korzystania z MVC, po większości obiektów SWT nie można (nie powinno się) dziedziczyć więc trudno je rozbudować (dyskusyjne: JFace (czyste klasy w Javie, takie kreatorki) daje możliwość jeszcze prostszego tworzenia okien, tabel etc. będąc wyższą warstwą abstrakcji, jednocześnie nie ograniczając dostępu do SWT)
- Potrzeba do programu w Javie dla każdej platformy dostarczyć natywną bibliotekę SWT i ewentualne jej zależności (np. libCairo pod Linuksem)
- Trzeba od nowa portować wszystkie komponenty dla każdej nowej platformy (Swing jest rysowany, więc potrzeba tylko funkcji rysowania i nowej implementacji L&F, z drugiej strony wydaje się, że SWT szybciej powstaje na nowe platformy niż Swing się do nich adaptuje)
- SWT jest mocno uzależnione od platformy i próby wykonania niektórych
- Trudno rozbudować komponent SWT lub stworzyć własny
- SWT długo nie miało odpowiednika Rendererów i wciąż trudno tworzyć tabelki czy listy z zawartością graficzną
[edytuj] Zobacz też
[edytuj] Linki zewnętrzne
- [2] Strona projektu
