Standard Widget Toolkit

Ten artykuł należy dopracować:

→ poprawić styl – powinien być encyklopedyczny,
Usunąć potoczne zwroty i zredagować polemikę.
Dokładniejsze informacje o tym, co należy poprawić, być może znajdują się w dyskusji tego artykułu.
Po wyeliminowaniu niedoskonałości należy usunąć szablon {{Dopracować}} z tego artykułu.

SWT (Standard Widget Toolkit) – biblioteka graficzna dla środowiska Java, stanowiąca 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.

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 bardziej wydajne 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 więcej niż Swing (Tree z możliwością dodawania kolumn, Expand Bar, komponenty C****, czyli zaimplementowane w SWT wersje standardowych komponentów)

Rozwiązanie ma również wady:

• Trzeba samemu zatroszczyć się o zwalnianie zasobów (metoda dispose())
• Rozwiązanie w większych projektach może 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 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ć (przepisywać) 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ą

Zobacz też

• AWT
• Swing
• JFace

Przypisy

Linki zewnętrzne

• Strona projektu (ang.)