eclipse-ui-development

name	eclipse-ui-development
description	Guidance for SWT, JFace, commands, handlers, views, editors, dialogs, wizards, and Eclipse workbench UI integration.

Eclipse UI Development

Use this skill when working on tasks related to:

• SWT
• JFace
• Eclipse workbench UI
• commands and handlers
• menus and toolbar contributions
• views and editors
• dialogs and wizards
• preference pages
• selections and workbench integration
• UI responsiveness and thread-safety

Goal

Create UI changes that are consistent with the repository's existing Eclipse UI patterns and remain compatible with the minimum supported Eclipse target-platform and JDK.

Working Approach

1. Follow the repository's existing UI style

Before introducing a UI solution, determine what the repository already uses:

• SWT or JFace conventions
• commands and handlers
• e3 or e4 style workbench integration
• dialogs, wizards, editors, or views
• preference pages and settings storage
• actions vs commands
• existing layout and widget style

Prefer consistency with the current codebase over generic UI patterns.

2. Respect the UI thread

For UI-related changes:

• access widgets only from the UI thread
• avoid long-running work on the UI thread
• use background jobs or async patterns for expensive operations
• synchronize back to the UI safely when updating controls

Do not introduce UI freezes for tasks that may block on workspace, network, file system, or computation.

3. Use Eclipse workbench patterns

Prefer the workbench-native mechanisms already present in the repository, such as:

• commands and handlers instead of ad hoc listeners where appropriate
• view contributions and editor integration
• structured selection handling
• workbench services
• standard dialogs and message patterns
• preference pages integrated with existing settings flow

4. Keep UI state and behavior predictable

UI code should:

• initialize controls consistently
• avoid hidden side effects
• validate user input clearly
• provide actionable messages
• preserve expected workbench behavior
• avoid unnecessary modal interruptions

5. Reuse existing Eclipse UI components where possible

Prefer existing widgets, dialogs, label providers, content providers, field editors, viewers, and helper utilities already used in the repository before creating new abstractions.

6. Respect internationalization

If the project externalizes strings:

• do not hardcode user-facing UI text
• add or update the relevant messages or properties entries
• keep labels, tooltips, validation messages, and dialog text consistent with the repository's NLS pattern

7. Preserve stable UI identifiers and contributions

Unless explicitly requested, do not rename or break:

• command IDs
• handler IDs
• menu contribution IDs
• view IDs
• editor IDs
• preference page IDs
• action definitions
• key binding related identifiers

8. Accessibility and usability

When possible:

• use meaningful labels and messages
• avoid unclear abbreviations in visible text
• preserve keyboard navigation
• keep default selections and validation behavior sensible
• avoid unexpected focus changes

9. Be careful with lifecycle-sensitive UI code

For views, editors, dialogs, and wizards:

• respect creation and disposal lifecycle
• avoid leaking listeners, images, fonts, colors, or other resources
• dispose custom resources properly
• avoid assuming controls exist before creation or after disposal

UI Task Checklist

Before considering a UI task complete, check:

• UI access happens on the UI thread
• long-running work does not block the UI
• existing commands/handlers/workbench patterns are respected
• visible strings are externalized if required by the repository
• IDs and contributions remain stable
• resources are disposed properly
• validation and error messages are clear
• solution is compatible with the supported Eclipse and JDK baseline

Output Expectations

When proposing or implementing Eclipse UI changes, include relevant notes about:

• how the solution fits the repository's existing SWT/JFace/workbench patterns
• how UI thread safety and responsiveness are handled
• whether plugin.xml, messages/properties files, or preference metadata also need updates
• any lifecycle or compatibility risks introduced by the change