[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[platform-debug-dev] [Fwd: Re: [cdt-dev] catchpoints design]
|
I'm cross-posting this to the platform mailing list since this is kind
of a general debug workflow issue....
Hi All,
In CDT we're discussing adding support for additional breakpoint types
which are supported by only some CDT-based debuggers. In order to
avoid cluttering the UI with irrelevant actions, we are discussing
whether and how to filter these breakpoint actions based on the active
debug session. I actually think that this problem also applies to JDT
and other debuggers, since for example in the Wind River product we get
regular complaints about "Add Java Exception Breakpoint" being present
in the Breakpoints view toolbar.
So my question to the platform team is:
1) Do you think that filtering breakpoint actions based on the active
debug context makes sense?
2) Do you think such a filtering mechanism should be standard and
supported by platform?
3) Do you think the File->New mechanism is appropriate for this
purpose as I suggested in the CDT discussion at
(http://wiki.eclipse.org/Talk:CDT:_Debug:_Catchpoints_support#File_-.3E_New).
-------- Original Message --------
Unfortunately this is why this feature is so problematic to me. IMO
there is already too much clutter in the debug UI and adding more
features without introducing a mechanism to control that clutter is
only making it worse.
I agree that because of the Eclispe breakpoint model the user has to be
able to create breakpoints before a debug session starts, however I
think it's acceptable to make the user dig a little deeper (though the
menus and dialog) in order to do it. With so much variety in debugger
capabilities, I think it's inevitable that the UI will need to filter
the immediately visible breakpoint actions based on the active debug
session.
In my last post on the design
discussion page I suggested imitating or just using the
File->New menu mechanism, which is context-sensitive, adaptive, and
powerful.
Cheers,
Pawel
John Cortell wrote:
The debugger should try to avoid that as much as possible,
but I don't see how that's always doable. What if an Eclipse
installation has two CDT debuggers in it. One supports catchpoints, one
doesn't. The user should be able to set a catchpoint before he launches
a debug session. How do you filter in that case? You don't know which
debugger the user is about to invoke.
Now, if the user only has one debugger installed, and it doesn't
support catchpoints, then I would expect that action to not be
available.
John
At 03:13 PM 4/14/2008, Pawel Piech wrote:
Would you want to see "Add Catchpoint" even
if your debugger doesn't support them?
-Pawel
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev