Bugzilla – Full Text Bug Listing
| Summary: | Simple Target System Browser | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Ken Ryall <ken.ryall> | ||||||
| Component: | cdt-debug-edc | Assignee: | Ken Ryall <ken.ryall> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | Ken Ryall <ken.ryall> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | john.cortell | ||||||
| Version: | 7.0 | ||||||||
| Target Milestone: | 8.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 172158 [details]
Freescale System Browser
Ken, we've had something in our commercial product for a few years similar to what you're proposing (see attached screenshot). It doesn't meet all your criteria, but enough where it might have been a good starting point. Anyway, do you have a design document so we could analyze your design and see how it matches to ours, and see if and how we can help you expand the feature to cover any gaps?
*** cdt cvs genie on behalf of kryall *** Bug 317236 - Simple Target System Browser [*] AbstractFinalLaunchSequence.java 1.26 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc/src/org/eclipse/cdt/debug/edc/launch/AbstractFinalLaunchSequence.java?root=Tools_Project&r1=1.25&r2=1.26 [*] WindowsDebuggerUI.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.windows.ui/src/org/eclipse/cdt/debug/edc/internal/windows/ui/WindowsDebuggerUI.java?root=Tools_Project&r1=1.2&r2=1.3 [+] WindowsSystemView.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.windows.ui/src/org/eclipse/cdt/debug/edc/internal/windows/ui/WindowsSystemView.java?root=Tools_Project&revision=1.1&view=markup [+] system_view.png http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.windows.ui/icons/obj16/system_view.png?root=Tools_Project&revision=1.1&view=markup [*] MANIFEST.MF 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.windows.ui/META-INF/MANIFEST.MF?root=Tools_Project&r1=1.4&r2=1.5 [*] plugin.xml 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.windows.ui/plugin.xml?root=Tools_Project&r1=1.2&r2=1.3 [*] BaseExpressionTest.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/src/org/eclipse/cdt/debug/edc/debugger/tests/BaseExpressionTest.java?root=Tools_Project&r1=1.4&r2=1.5 [+] K9SystemViewTest.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/src/org/eclipse/cdt/debug/edc/system/tests/K9SystemViewTest.java?root=Tools_Project&revision=1.1&view=markup [+] K9SystemView.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/src/org/eclipse/cdt/debug/edc/system/tests/K9SystemView.java?root=Tools_Project&revision=1.1&view=markup [+] k9_view.png http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/icons/obj16/k9_view.png?root=Tools_Project&revision=1.1&view=markup [*] build.properties 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/build.properties?root=Tools_Project&r1=1.2&r2=1.3 [+] plugin.xml http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/plugin.xml?root=Tools_Project&revision=1.1&view=markup [*] AllEDCTests.java 1.10 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/src/org/eclipse/cdt/debug/edc/tests/AllEDCTests.java?root=Tools_Project&r1=1.9&r2=1.10 [*] MANIFEST.MF 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.tests/META-INF/MANIFEST.MF?root=Tools_Project&r1=1.4&r2=1.5 [+] SystemViewModel.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.ui/src/org/eclipse/cdt/debug/edc/internal/ui/views/SystemViewModel.java?root=Tools_Project&revision=1.1&view=markup [+] SystemDMContainer.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.ui/src/org/eclipse/cdt/debug/edc/internal/ui/views/SystemDMContainer.java?root=Tools_Project&revision=1.1&view=markup [+] SystemDataModel.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.ui/src/org/eclipse/cdt/debug/edc/internal/ui/views/SystemDataModel.java?root=Tools_Project&revision=1.1&view=markup [+] SystemView.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.ui/src/org/eclipse/cdt/debug/edc/internal/ui/views/SystemView.java?root=Tools_Project&revision=1.1&view=markup [+] TCFDataModel.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.ui/src/org/eclipse/cdt/debug/edc/internal/ui/views/TCFDataModel.java?root=Tools_Project&revision=1.1&view=markup [+] SystemVMContainer.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.ui/src/org/eclipse/cdt/debug/edc/internal/ui/views/SystemVMContainer.java?root=Tools_Project&revision=1.1&view=markup [+] SystemRefreshOptionsDialog.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc.ui/src/org/eclipse/cdt/debug/edc/internal/ui/views/SystemRefreshOptionsDialog.java?root=Tools_Project&revision=1.1&view=markup That looks nice, I didn't know you guys had anything like it. The view layout is conceptually, is not visually, similar to what I had in mind. The debug button in the toolbar is for Attach? I didn't think to do that but only stuck it in a contextual menu for now. The best way to preview what I've prototyped so far is to update the EDC sources from HEAD and open the K9 System View. It shows a mock set of OS data that should update every few seconds. A Windows system browser view is also included. It currently only shows processes but is built on top of a TCFDataModel that is designed to work with a TCF agent. It launches the EDC Windows debug agent to get the data. The key parts of this design are in the SystemViewModel and the SystemDataModel. The data model collects all the data about the OS that you want to display. The view model organizes the data into collections and hierarchies according to your needs. My goal was for the person hooking up this up to not have to learn much about the way the actual UI model works in the view. I'm embarrassed to say how much time it took me to get the flexible hierarchy part of the view working. I committed this to HEAD so people could try it out, not to proclaim mastery of the subject, so let me know how you think it compares to your view and what direction we should go. Yes. That's how you attach to a process/thread/??? (term depends on the OS). OK. I'll play around with it and get you some feedback. As for the flexible hierarchy, our view is not based on it. I'm not sure how mature it was at the point the development on our browser started, or perhaps it was purposely avoided (so we could spare ourselves that same embarrassment). :-) (In reply to comment #3) > That looks nice, I didn't know you guys had anything like it. The view layout > is conceptually, is not visually, similar to what I had in mind. The debug > button in the toolbar is for Attach? I didn't think to do that but only stuck > it in a contextual menu for now. > > The best way to preview what I've prototyped so far is to update the EDC > sources from HEAD and open the K9 System View. It shows a mock set of OS data > that should update every few seconds. > > A Windows system browser view is also included. It currently only shows > processes but is built on top of a TCFDataModel that is designed to work with a > TCF agent. It launches the EDC Windows debug agent to get the data. > > The key parts of this design are in the SystemViewModel and the > SystemDataModel. The data model collects all the data about the OS that you > want to display. The view model organizes the data into collections and > hierarchies according to your needs. My goal was for the person hooking up this > up to not have to learn much about the way the actual UI model works in the > view. I'm embarrassed to say how much time it took me to get the flexible > hierarchy part of the view working. > > I committed this to HEAD so people could try it out, not to proclaim mastery of > the subject, so let me know how you think it compares to your view and what > direction we should go. Ken, so conceptually, Freescale and Nokia went for the same thing, but the underlying design is pretty different. Our browser is a single view whose content is driven by the active debug context. If you're debugging a multicore system, e.g., and you have an RTOS running on a DSP core, and Linux running on an ARM core, depending on what's selected in the Debug view, the System Browser updates to show the relevant system information. Our view provides a built-in, but optional sheet (tab) in the browser for showing processes/tasks. A client can populate that via an API--it need not put up an GUI. But then it has the option to contribute any additional sheets it wants and make them as GUI-rich as needed. For additional sheets, the client provides the GUI and it is responsible for getting the information it needs from the active context. From what I can tell, your browser is based on having one view per system. Its focus is on presenting data generically in a table-tree viewer. The nice thing is that it takes care of the GUI for the client, but the downside is that it is limited to presenting the data in a pretty basic way. Given these fundamental differences, I don't know that we'll be looking to use the EDC system browser as-is. If you would like to see the EDC browser move more towards what we've designed, we could look at trying to enhance ours to meet your needs (e.g., adding another built-in sheet that exposes generic data based on on the platform's flexible hierarchy viewer, and support per-system views). Alternatively, we could look at adding the features I've mentioned to your browser, if you don't feel that doesn't blow the simplicity you were shooting for. (this is part of a batch change) The Eclipse CDT EDC (https://wiki.eclipse.org/CDT/cdt-debug-edc) is now obsolete and has not had any active development since 2011. Therefore the still open bugs are being marked as wontfix. The git repo for the project still exists for posterity at https://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git/ |
Created attachment 172154 [details] Initial effort As a developer I would like to see a view showing the state of my target operating system. It should show both an overview and more detailed information about OS objects (processes, threads, heaps, chunks, libraries etc.) I also want to be able to select a process and attach to it for a new debug session. Acceptance: A light-weight view that does not bring in other frameworks (ex. RSE). Operates without a debug session running. Uses the debug platform's flexible hierarchy UI model for performance. Supports auto refresh and selectable refresh interval. Simple data model and view model for easy adoption. Implementers should be able to fill in these models without learning about the UI details. Abstract implementation to enable target OS specific views (Windows System, Symbian OS Data etc.) Abstract implementation of a data model that populates itself from a TCF agent using the IProcess service.