Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Gyrex/Concepts/Admin UI

Gyrex
Website
Download
Community
Mailing ListForumsIRCmattermost
Issues
OpenHelp WantedBug Day
Contribute
Browse SourceProject Set File

Admin UI Page

  • every page has to extend FilteredAdminPage or AdminPage
  • need a constructor which sets title (setTitle) and titletooltip (setTitleToolTip)
  • you have to override at least super methods activate() and createControl(final Composite parent) which returns a Control
  • new Composite in parent compsite can take all other composites, shells, widgets, ...
  • layout should be GridLayout
  • with Infobox possibility to set paragraphs and help text
  • for new horizontal arrangement create new composite with more columns
  • it is possible to create further classes, where composites and widgets are arranged
  • in createControl the classes have to be called or without further classes this is the place to arrange composites and widgets
  • order of declaration of widgets/more composites defines order of appearence
  • for clear code outsource code snippets for complex buildings such as the (filtered)trees or declaration of a few buttons in a row in methods
  • almost every swt widget can be used, such as buttons, labels, dialogs


Buttons

  • from swt package
  • with initialization assigned to parent composite
  • for clear code, it's better to have a method for creating a button where definition, initialization, text settings and LayoutData settings are placed
  • the added selectionListender needs a SelectionAdapter which on widgetSelected(SelectionEvent) calls a method with code presenting the functionality
  • depending on functionality they can be enabled or not (could be managed in separate method, too)
  • for separation use of labels
  • can open dialogs


Labels

  • from swt package
  • with initialization assigend to parent
  • without text good possibility for separating buttons
  • LayoutData is GridData with horizontalAllignment SWT.BEGINNING and verticalAllignment SWT.CENTER (in case of use for separation)


TreeViewer

  • gets data via setInput()
  • can have SlectionChangedListener(ISelectionChangedListener), OpenListener(IOpenListener)
  • ISelectionChangedListener has the selectionChanged(SelectionChangedEvent) method which has to be overriden
  • IOpenListener has the open(OpenEvent) method which has to be overriden
  • can be refreshed, that means to show new information getting from the viewer's model
  • has a comparator for sorting elements
  • with a LabelProvider the columns of the tree are filled with texts or labels


Dialogs

  • should extend either Infobox, NonBlockingMessageDialogs or NonBlockingStatusDialog
  • if they don't extend them they has to contain openNonBlocking(DialogCallback) method from NonBlockingStatusDialog or NonBlockingMessageDialog for proper lifecycle
  • can be opened by clicking a button who has to call the dialogs openNonBlocking(DialogCallback) method; the callback has to define what to do after closing the dialog by pressing "OK" (clicking "Cancel" has no further effect)
  • dialogs getting parent shell as parameter, should be set as a member variable in constructor where to create super instance with this parent
  • set title and shellStyle in constructor as well
  • override super methods createDialogArea(Composite), okPressed()
  • createDialogArea defines the arrangement of widgets like fields,buttons, checkButtons, radioButtons, ...
  • all widgets are from package admin.ui.internal.wizards
  • checkButtons and radioButtons can be created as a SelectionButtonDialogFieldGroup
  • for a single radio or check button use SelectionButtonDialogField
  • to validate values of fields use IDialogFieldListener, which has to be set for every StringDialogField
  • same as in createControl a new composite has to be created for the widgets
  • in most cases buttons in dialogs are to add or remove applications, logger or something else, because of this they are implemented in ListDialogFields; in customButtonPressed() you get the button, who was clicked and can call the appropriate method
  • ListDialogFields are from admin.ui.internal; has to have a IListAdapter (from admin.ui.internal, too) who provides the customButtonPressed() method
  • if an object has to be edited, just append it as a parameter when you call the dialog, then in the constructor assign it to member variables, in fields the existing values can be set to edit
  • okPressed() executes code after clicking the "OK" button at the dialog, super.okPressed() has to be called to close window
  • super.okPressed() return Window.OK code, clicking "Cancle" returns Window.CANCEL as default

Back to the top