Środowisko robocze od środka

Środowisko robocze udostępnia szeroki zestaw klas i interfejsów na potrzeby tworzenia złożonych interfejsów użytkownika. Na szczęście nie trzeba znać ich wszystkich, aby zrobić coś prostego. Na początek przedstawione zostaną pewne pojęcia wykorzystywane w interfejsie użytkownika środowiska roboczego oraz konstrukcje odpowiadających im struktur.

Platforma

Terminem środowisko robocze określa się potocznie "okno otwierane podczas uruchamiania platformy". Warto zbadać je nieco dokładniej i przyjrzeć się niektórym elementom wizualnym, które składają się na środowisko robocze.

Środowisko robocze z trzema widokami i jednym edytorem na stronie

W pozostałej części tego omówienia przez środowisko robocze określać się będzie okno środowiska roboczego (IWorkbenchWindow). Okno środowiska roboczego to okno najwyższego poziomu w środowisku roboczym. Stanowi ono ramę, w której umieszczone są: pasek menu, pasek narzędzi, wiersz statusu, pasek skrótów i strony. W ogólności nie ma potrzeby programowania okna środowiska roboczego. Wystarczy tylko wiedzieć, że ono istnieje.

Uwaga:  Można otwierać wiele okien środowisk roboczych, jednak każde takie okno stanowi odrębne środowisko edytorów i widoków, dlatego w dalszej części omawiane będzie pojedyncze okno środowiska roboczego.

Z punktu widzenia użytkownika środowisko robocze zawiera widoki i edytory. Poza nimi, tylko kilka innych klas jest używanych do zaimplementowania okna środowiska roboczego. 

Strona

Wewnątrz okna środowiska roboczego można znaleźć jedną stronę (IWorkbenchPage), która zawiera części. Strony to mechanizm implementacyjny służący do grupowania części. Najczęściej nie ma potrzeby programowania do poziomu strony, ale jest ona widoczna w kontekście programowania i debugowania.

Perspektywy

Perspektywy stanowią dodatkową warstwę organizacji w obrębie strony środowiska roboczego.   Perspektywa definiuje odpowiednią kolekcję widoków, ich układ oraz akcje dotyczące danej czynności użytkownika.  Użytkownicy mogą przełączać się między perspektywami w miarę wykonywania kolejnych czynności.    Z punktu widzenia implementacji aktywna perspektywa użytkownika decyduje o tym, które widoki są wyświetlane na stronie środowiska roboczego, jakie są ich pozycje i rozmiary.  Zmiany perspektywy nie mają wpływu na edytory.

Widoki i edytory

Widoki i edytory to części, w których wychodzi się poza szczegóły implementacji i wchodzi w obszar typowego programowania modułów dodatkowych. Podczas dodawania składnika wizualnego do środowiska roboczego trzeba zdecydować, czy chce się zaimplementować widok czy edytor. Jak to zrobić?

W każdej sytuacji widok lub edytor musi być zbudowany zgodnie z typowym cyklem życia.

W ramach tego cyklu życia obejmująca strona środowiska roboczego wyzwala zdarzenia powiadamiające o otwieraniu, aktywowaniu, dezaktywowaniu i zamykaniu widoków i edytorów.

Proste?  To może być proste. Na tym polega urok widoków i edytorów środowiska roboczego. Są one tylko pojemnikami na widgety i mogą być tak proste lub tak złożone, jak się chce. Najprostszy z widoków można było poznać wcześniej w przykładzie hello world. Warto przyjrzeć mu się ponownie, gdy wiadomo już więcej na ten temat.

   package org.eclipse.examples.helloworld;

   import org.eclipse.swt.widgets.Composite;
   import org.eclipse.swt.widgets.Label;
   import org.eclipse.swt.SWT;
   import org.eclipse.ui.part.ViewPart;

   public class HelloWorldView extends ViewPart {
      Label label;
      public HelloWorldView() {
      }
public void createPartControl(Composite parent) {
         label = new Label(parent, SWT.WRAP);
         label.setText("Hello World");
      }
      public void setFocus() {
         // Aktywuje widget. W przypadku etykiet nie ma to
         // większego sensu, ale przy bardziej złożonych zestawach widgetów
         // można określić, który widget ma zostać aktywowany.
      }
   }

Warto zauważyć, że nie ma potrzeby implementowania metody dispose(), ponieważ jedyna wykonywana czynność to utworzenie etykiety w metodzie createPartControl(parent). Gdyby zostały przydzielone zasoby interfejsu użytkownika, na przykład obrazy lub czcionki, musiałyby one zostać zutylizowane. Ponieważ rozszerzono klasę ViewPart, odziedziczono implementację "nie rób nic" metody dispose().