1 / 8

Eclipse Debug Views Update Policy

Eclipse Debug Views Update Policy. Agenda. Where we left off last time… Design of the Prototype Demo What next…. Where we left off last time…. Need to make view update more flexible Use of pluggable update policies View updates done by a generic interface.

jordan-rogers
Download Presentation

Eclipse Debug Views Update Policy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Eclipse Debug Views Update Policy

  2. Agenda • Where we left off last time… • Design of the Prototype • Demo • What next…

  3. Where we left off last time… • Need to make view update more flexible • Use of pluggable update policies • View updates done by a generic interface. • Update policies are contributed by extension point. • Views could have multiple policy handlers when multiple models are displayed. Multi-Targets View Static View Input Updater 1 Model A Updater 2 Update (elementA) Model B Updater 3 Update (elementB) Model C Updater 4 Update (elementC)

  4. Design of Prototype • Update policies are contributed via extension point. • Each policy has a policy handler. • Implements IUpdatePolicyHandler • The handler is responsible for handling a specific type of events (e.g. debug events, timer update, debug context changed) • The handler is generic and can work with any views or debug model • Policies are not tied to any model or view, just defining a policy handler for handling certain type of events.

  5. Design of Prototype • Platform provides: • An extension point for contributing update policies • A framework for managing these contributed policies (IUpdatePolicyManager and other related interfaces) • Abstract implementation to IUpdatePolicyHandler (AbstractUpdatePolicyHandler) • Abstract implementation that extends AbstractDebugView to support pluggable update policy in debug views (AbstractDebugViewExtension) • A generic set of update policies: • Debug context changed policy • Debug event policy • Delayed debug event policy • Timer Policy • Clients may define other update policies

  6. Design of Prototype • Clients may employ update policies by defining a policy set: • Clients may define more than one policy set per view • Platform provides UI to allow user to create new policy sets • Platform provides UI to allow user to switch policy sets while debugging

  7. Demotime…

  8. What next… • Migrated Variables View, Registers View and Expressions View • Still have the following to work on: • Could not quite get the Expressions View to work • Conflicts between policy handlers. • Need better communication between policy handlers • Have been focusing on “when” to update, need to look at “what” to update: • e.g. update what’s visible. • Can the design work with asynchronous tree viewer and flexible hierarchy? • Need to experiment with the Debug View • Need to experiment with the Memory View • Problems with allowing user to define customized policy sets on the fly.

More Related