SWT (biblioteka)

Z Wikipedii

Ten artykuł wymaga dopracowania zgodnie z zaleceniami edycyjnymi.
Należy w nim poprawić: Usunąć potoczne zwroty i zredagować polemikę.
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ą zwykle szybsze w użyciu w porównaniu do rozwiązań konkurencyjnych (w zależności od zastosowań i systemu)
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 and 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
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ą