Standard Widget Toolkit

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

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.


Zalety i wady[edytuj | edytuj kod]

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 (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 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ć 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ż[edytuj | edytuj kod]

Linki zewnętrzne[edytuj | edytuj kod]

Przypisy