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
|