[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] [Fwd: Re: [cdt-dev] catchpoints design]
|
I think having a generic breakpoint creation wizard is a good idea. This
will ease some cluttering in the breakpoitn view toolbar. However, I
disagree hooking the wizard with the File -> New... menu. I think it is
too hidden and counter-intuitive. (Most users do not know that breakpoints
are markers tied to the file system.) The user will have a hard time
finding it or even discovering that it exists. I prefer having a generic
"Add" toolbar action in the breakpoints view. The action should bring up a
create breakpoint wizard. Problems with this approach is that the wizard
can also get cluttered with all the different breakpoint types. And the
user needs to perform more steps to add a breakpoint.
I also agree that breakpoint actions should be filtered in the breakpoints
view. In addition to filtering based on the current debug context, is it
possible to filter based on the editor content type. If the user is
working with a Java file, then the user will most likely try to add
Java-related breakpoints from the breakpoints view. If the user is working
with C/C++ files, then the user will likely want to add breakpoints related
to their C/C++ applications. This will allow the user to add breakpoints
without having a debug session started. Once a debug session is started,
then I think filtering based on the current debug context makes sense.
Thanks...
Samantha
Pawel Piech
<pawel.piech@wind
river.com> To
Sent by: "Eclipse Platform Debug component
platform-debug-de developers list."
v-bounces@eclipse <platform-debug-dev@xxxxxxxxxxx>
.org cc
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
15/04/2008 03:41 Subject
PM Re: [platform-debug-dev] [Fwd: Re:
[cdt-dev] catchpoints design]
Please respond to
"Eclipse Platform
Debug component
developers list."
<platform-debug-d
ev@xxxxxxxxxxx>
Darin Wright wrote:
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?
I agree that it would be nice to be able to filter the breakpoint
creation
actions based on some context. The problem here is deferred
breakpoint
creation. If the actions are filtered based on active debug context,
then
how can I create a breakpoint before a debug session starts (like a
Java
exception breakpoint) ?
The File->New menu always has an "Other..." entry which opens a wizard with
a categorized selection page. BTW, I don't think that active context needs
to be the only method for determining whether a given breakpoint action is
visible. For the CDT breakpoints we're discussing, there is a lot of
variability in support from different debuggers, even from different
targets. For more standard breakpoints types, it may be more appropriate
to filter based on active action sets.
2) Do you think such a filtering mechanism should be standard
and
supported by platform?
If we can find a good way to do this - yes.
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).
"File -> New" feels heavy for breakpoint creation. Generally this is
reserved for things that create new entities in the file system.
As a marker a breakpoint actually is in the file system :-)
I and most people in the discussion I think have the same concern. One
option is to just not use the New wizard framework and just copy it, but to
me that seems to go against the spirit of Eclipse... There are also some
real advantages to using the File-> New menu:
- The wizard interfaces and extension points are already in place.
- There is already a menu and a toolbar action for it.
- It's a familiar user workflow (even if it's not yet used in debugging).
- The File->New shortcut menu is empty in the Debug perspective, giving the
breakpoint actions a clean slate.
This is just a far-fetched idea at this point, but IMO clutter in the Debug
UI is a real pain point for Eclipse users, so I want to find some ways to
address it.
Cheers,
Pawel
Darin Wright
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
