| RE: [cdt-dev] catchpoints design |
|
I like Pawel's idea to add context sensitive "New" to
the breakpoints view. I would even propose to make the breakpoint view
context sensitive. At least the "Show breakpoints supported by selected
target" should be extended to support the flexible hierarchy.
As for catchpoints, I think it should be the option 2
combined with "New".
Mikhail From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech Sent: Monday, April 14, 2008 9:37 PM To: CDT General developers list. Subject: Re: [cdt-dev] catchpoints design 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. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. |