1 / 8

Enhancing Debug Views with Pluggable Update Policies: A Prototype Agenda

In this session, we will recap our previous discussions on the design of a prototype for flexible view updates in debug contexts. We aim to refine our approach by introducing pluggable update policies that allow views to utilize generic interfaces and multiple policy handlers for various models. With our framework for managing these policies, we will explore new UI features enabling clients to create and switch policy sets during debugging. Key considerations include resolving conflicts between policy handlers and optimizing update triggers for better user experience.

jordan-rogers
Télécharger la présentation

Enhancing Debug Views with Pluggable Update Policies: A Prototype Agenda

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