Ticket #272 (closed enhancement: fixed)

Opened 4 years ago

Last modified 4 years ago

Package explorer could show aspect bindings

Reported by: stephan Owned by: stephan
Priority: major Milestone: OTDT_1.3.2
Component: otdt.pde.ui Version: 1.3.0M3
Keywords: Cc:

Description (last modified by stephan) (diff)

For OT/Equinox projects the package explorer could show all aspect bindings defined by the current bundle, similar to the Plug-in Dependencies container.

This would raise visibility of aspectBindings even more.

Preferrable, each aspect binding would be represented by a node of its own, with base bundle and team classes as its children (just like in the extension editor).

Attachments

AspectBindingsInPackageExplorer.png Download (96.7 KB) - added by stephan 4 years ago.

Change History

Changed 4 years ago by stephan

  • status changed from new to accepted
  • description modified (diff)

Changed 4 years ago by stephan

Changed 4 years ago by stephan

  • status changed from accepted to closed
  • resolution set to fixed
  • milestone changed from OTDT_2.0.0 to OTDT_1.3.2

This is what the new feature looks like as per the implementation in r22443:

It places one node "OT/Equinox Aspect Bindings" next to the classpath containers if the current project has aspect bindings.

Aspect bindings are grouped per base plugin (even if the plugin.xml specified several aspect bindings for the same base plugin).

Selecting a base plugin opens plugin.xml (should reveal the corresponding extension, not yet).

Selecting a team opens the team in the editor.

Changed 4 years ago by stephan

r22446 adds deep selection of a basePlugin element: reveal the corresponding extension element in the extension editor.

This required to intercept the model elements used by the extension editor (of type PluginElementNode, which are not normally accessible for clients of the extension editor - intercept their initialization instead). Relies on the internal role cache (via getAllRoles(Class)) - garbage collection should take care of unneeded roles, may want to keep an eye on whether this works.

Changed 4 years ago by stephan

r22471 brings two improvements of this feature, both issues regard the use case of closing and re-opening the extension editor:

  • fix usage of a foreign label provider: mujst connect/disconnect for correct widget disposal.
    This bug resulted in parts of the tree remaining empty due to a widget disposed error.
  • invoke selectReveal only for the correct node, despite old dangling roles (see also Eclipse bug 287852)
    This bug caused selection to fail after the extension editor had been closed and reopened.

Changed 4 years ago by stephan

Refreshing of the new tree nodes is implemented in r22503 using an IResourceChangeListener.

Note: See TracTickets for help on using tickets.