Community
Participate
Working Groups
Currently, the CDT Debug preference pages are very confusing. Nothing distinguishes between CDI-GDB preferences and DSF-GDB preferences. Also, the DSF-GDB options are under Debug->DSF->GDB but should probably be under C/C++->Debug->something I haven't check EDC, but it's preferences should also be part of such a unified debug preferences.
+1 Since we have a growing diversity of debuggers under the hood of CDT, we need to figure out how to present their collective preferences and avoid completely confusing the users. I would suggest that we organize the preferences like this: C/C++ Debug Standard Debugger Framework Debugger Types View Options GDB MI Debugger Services Framework (DSF) GDB Eclipse Debugger for C/C++ (EDC) Breakpoint Actions Source Lookup Disassembly Under the top-level Debug, we should give the user some explanation about what CDT debuggers are installed and have a link to the Run/Debug -> Launching -> Default Launchers preference page. At the same time we should standardize on the launcher names which are currently long and confusing.
(In reply to comment #1) The only issue I see with this approach (and mind you, I don't have a better alternative), is that we force the framework concept on users that would otherwise not need to know about it. A Freescale customer doesn't need or care to know that the debugger we've given them is DSF-based, and particularly EDC based. The product they get simply has "a debugger", and they couldn't care less if it's DSF, ABC, or XYZ based. So, we'd like to shield them from that. Through capabilities/activities, we can filter out preference pages that don't apply, but we can't easily rename or collapse pages. So, when they go looking for debugger preferences, they're going to have to drill into ... > Debugger Services Framework (DSF) > Eclipse Debugger for C/C++ (EDC) and that's going to cause some head scratching. We've had some recent threads on how new users are overwhelmed with the Eclipse IDE, and this is an example of how users get hit with an overly complex path/presentation to what they consider something very basic. We've chosen to make CDT a home for, frankly, a head-spinning assortment of debugger technologies. Fine. But we need to make sure vendors can expose just the technology they've chosen to adopt without burdening the end-user with extraneous concepts. It's not going to be easy, but we need to try.
(In reply to comment #2) > (In reply to comment #1) > The only issue I see with this approach (and mind you, I don't have a better > alternative), is that we force the framework concept on users that would > otherwise not need to know about it. > > A Freescale customer doesn't need or care to know that the debugger we've given > them is DSF-based, and particularly EDC based. The product they get simply has > "a debugger", and they couldn't care less if it's DSF, ABC, or XYZ based. So, > we'd like to shield them from that. I agree, this has been a problem for DSF from the start and we haven't been able to avoid having "DSF" in some places in the UI. My only suggestion (and this is what we've done in our product), is that in the product-specific preference pages put link directly to the DSF preferences, which are currently under Run/Debug -> DSF. This is hardly satisfying, so I'd love to find a better solution.
I think a better solution might be to create capabilities for DSF, CDI, DSF-GDB, and CDI-GDB. I created one for EDC so I could try this out for the other debugger integrations too.
Created attachment 163148 [details] reorg prefs This patch reorganizes and creates activities for the pref pages. There are five new activities: Core CDT Debug: "CDT Debug - C/C++ Development Tools" - C/C++ Debug, Breakpoint Actions, Common Source Lookup. This activity is enabled by default. CDI-GDB: "CDT CDI-GDB - GDB Debugging (Legacy)" : Debugger Types, MI Preferences. This activity is enabled when a CDI launch delegate is created. DSF-GDB: "CDT DSF-GDB - GDB Debugging" - DSF GDB Prefs, Tracepoint Actions. This activity is enabled when a DSF GDB launch delegate is created. DSF: "CDT-DSF Debug Services Framework" - DSF page (now View Performance). This activity is enabled when the DSF UI plug-in is loaded. EDC: "EDC - Eclipse Debugger for C/C++" - Snapshot page, Snapshot Album View. This activity is enabled when an EDC launch delegate is created. Other changes: Moved the DSF GDB page under C/C++ Debug Moved DSF Disassembly under C/C++ Debug Renamed DSF page to View Performance Once activities are enabled they remain enabled unless manually disabled by the user. The end result is that pref pages (except the DSF page) are grouped under C++ Debug and only visible if you are using the applicable framework/feature. For the disabled activities only the UI is hidden, all of the underlying pref setting information is undisturbed. What this means in practice is that a user of CDT will see none of the disabled pages until they launch a debug session, then they will only see the ones that apply. I think this is OK because none of the disabled pages are part of any common pre-debug workflow.
I also considered, but have not yet implemented, having the C/C++ debug pref pages appear under Run/Debug as well. Most people seem to look for them under C++ bug some go straight to Run/Debug.
Committed to HEAD.
I think this is a good start. However, when multiple activities are enabled, the preferences don't indicate if they will affect CDI only, or DSF-GDB only, etc. Although this may seem to not happen often because people will choose a single debugger, it actually does happen because when running an application, the CDI launch is used, so it's properties appear and remain there. Another problem is the actual Debug preference page. It contains CDI-specific preferences as well as (what I believe are) old Disassembly setting. I'm re-opening so we remember to continue to cleanup the preferences
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
