Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-debug-dev] Re: [jdt-debug-dev] Debug Work Items for 2.1 and Beyond

Darin Swanson wrote:
> 
> > Here are some of the issues we've come across when wrapping the
> > jdt debug model:
> >
> > 1. One issue that we have when wrappering the jdt debug model is
> > that we have no way to override the jdt menu contributions to the
> > launch and variable views (that we know of).  Specifically the
> > 'open on <x> type' menu items.  These show the underlying java source
> > code, which is not the language that the user is debugging.  I would
> > say that the solution would be to base the menu items on the current
> > debug target id, but I'm not sure if this is the solution.
> >
> 
> This is great as it might validate my work for today ;-).
> I reworked the "Open on" menu items to request the source element from the
> source locator for the launch.  So your source locator can be reused to just
> do the right thing?
> We only resort to searching the workspace if this fails.  See bugs:
> http://dev.eclipse.org/bugs/show_bug.cgi?id=5516
> http://dev.eclipse.org/bugs/show_bug.cgi?id=4084
> 
> Of course with actions that simply do not make sense in your context, you
> can remove the contribution from the XML.

The actions may not make sense in our context, however if the these
menu items had a 'java' icon next to them it may solve the problem.

The language is capable of calling java and vice versa, so our
debug wrappers act as the underlying java debug elements in the
instances where the user steps into and out of java code.  When
in the java code, we would want the user to have these menu items
present.


> > 2. Another issue that we have is that our program programmatically
> > sets underlying java breakpoints whenever the user sets a breakpoint
> > in their source code (which is in another language).  It would be
> > nice if these java breakpoints could be 'invisible' in the breakpoint
> > view by default.  Currently, the user has to set the 'show only
> > supported breakpoints' option.  It would be nice if there was a
> > visibility option and the breakpoint view would not show invisible
> > breakpoints by default (the user could override this, of course).
> 
> I believe this is covered in our concept of registering/not registering the
> breakpoint with the breakpoint manager?
> For example, we programmatically set breakpoints for the "Run to Line"
> functionality.  These are not registered (part of the api on the call to the
> debug model to create a line breakpoint) and therefore do
> not show up in the breakpoints view.
> 

The problem is that these breakpoints are not temporary and need to
be managed, persisted, etc.  This is the job of the breakpoint manager
right?


> >4.
> Could you please log a bug report for this issue?
> 

Entered as Bug # 22435


Thanks,

David


Back to the top