Community
Participate
Working Groups
I'd like to propose some ideas for how we can streamline the Memory view workflow while minimizing UI clutter. The initial patch is only prototype quality for the purpose of demonstrating the proposed concepts.
Created attachment 110569 [details] Memory view, before and after screenshot - before and after patch
Created attachment 110571 [details] memory view workflow - before and after patch
Created attachment 110572 [details] patch
additional ideas not included in patch: - bookmarks: Allow the user to bookmark their favorite addresses. - linking/synchronized scrolling: The dual panes have been removed in this patch. If this is an important feature, can we devise a new system to fulfill the requirement? Link/synchronize between entire memory view instances? Or enhance the content providers to allow multiple types of data (hex next to ASCII) within a single rendering? - new tab: I find it somewhat troubling that the "New Tab" tab displays blank content. Perhaps a preference should specify a default rendering? But, how would a user switch to a different rendering with minimal clicks?
Hey Ted, The workflow comparison is really helpful. I have been doing some thinking about your Memory View workflow changes proposal and here are my thoughts: 1) This proposal is making the Memory View looking a lot like its original state when it was first contributed to the platform. We originally had a single pane, displaying memory in hex format. We had a second view called the Rendering View which displays memory in other formats. The feedback we gathered at that time was that the views were taking up a lot of real estate. We were requested to bundle the two views into one. Hence, we got a view with two panes. Separating the view in two panes was an effort to de-couple different ways of rendering memory, thereby allowing the user to see memory in various combination of renderings easily. Question 1: What are the reasons for removing the second rendering pane? Quesiton 2: How can the user see different renderings of the same memory block at the same time easily? 2) I have received numerous requests for a "Go To Address" bar. The "Go To Address" bar allows the user to create new memory blocks or go to certain address easily, without having to go through modal dialogs. As discussed in our call, we should looking creating an optional attribute/delegate in the memory rendering binding to allow clients to customize how the "Go To Address" bar will look like. My concern here is the blank "New Rendering" tab, and the inconsistencies in creating a new memory block. This is my understanding of how it works: 2a) If the user does not have any rendering in the memory view, the user goes to the "Go To Address" bar to create a new memory block, and create a new rendering from the pane. 2b) To create another memory block/rendering, the user must navigate to the "New Rendering" tab, so that we know that the user is trying to create a new memory monitor. The "New Rendering" tab is blank at initially, making it confusing for the user. I think the general problem is that because the "Go To Address" bar is global in the view, its meaning of whether we should add a new memory block, or simply reposition an existing rendering is ambiguous. Similar to the "Go To Address" bar in the standard renderings, perhaps, we can add a drop-down menu in the "Go To Address" bar to allow the user to tell us whether we should create a new rendering or simply reposition an existing rendering? 3) Removal of the Memory Monitors Pane. The Memory Monitors Pane was introduced to help the user manage their memory monitors. It allows the user to see the current memory monitors. It also allows the model to group memory monitors. e.g. models can group memory monitors by address space. Without the Memory Monitors Pane, we are taking away this memory block management capabilities. In addition, it does not allow the user to remove a memory block easily. From an implementation point of view, we cannot tell for sure when we can remove the memory blocks from the memory block manager. Question 3: What are your reasons for removing the memory monitors pane? Is it because of real-estate? Question 4: How can the user remove a memory block? Question 5: How can the user see renderings from the same memory blocks easily? My biggest concern with this proposal is that we have removed many features from the Memory View. We need to think how they would affect existing debug adapters and find ways to replace some of these features. Thanks.... Samantha
hi Samantha, 1.1) We've received continuous feedback about this feature being confusing. Your summary of memory view history is appreciated. My patch strips out much of the user interface we'd like to hide, but the goal is refinement rather than removal of functionality. 1.2) I've been experimenting with allowing the user to split a rendering tab (as opposed to multiple RenderingViewPanes). Rather than using a view toolbar item to enable split pane mode for the entire view, a context menu item within the rendering allows the rendering to be split (replaced by a two pane container). As an added benefit, the user is able to create multiple rendering combinations. For example: Tab 1: Hex Tab 2: Hex & ASCII Tab 3: ASCII Tab 4: Integer & Hex 2) I'll post a patch with the described enhancement. Should I post to 214956? 3.3, 3.4, 3.5) Real estate utilization is one catalyst in our desire to hide the monitors pane, but additionally I question whether the user should be responsible for maintaining this list. As a feature to satisfy the 20% case, memory bookmarks might be helpful, but for typical use, what are the benefits of a user managed list? Viewing the same block in multiple views or renderings should be possible without this pane. For example, the user could enter the same expression in the address bar or use the (proposed) context menu "Create Rendering -> ...." from an existing rendering. I suspect adopters of the memory view have varied use cases, but I think the most common use case is: open memory view, type expression, view/scroll/edit, type different expression, repeat. This scenario is too complex in the Eclipse Memory view. My attempt to multitask has been inadequate. I once again have time allocated to work on the Memory View. Where should we go from here? thanks, ted
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
