Community
Participate
Working Groups
Samantha Chan asked me to file a defect report. Here goes. CDT provides a "Memory Browser" option while basic eclipse has a "Memory" option. It is confusing to have both of these available. In addition to having a view selection, CDT's memory renderer also populates the Memory viewer with a "Traditional" rendering. MemoryViewer uses renderIds to enable and disable which renderer you want. This mechanism does not work for this traditional rendering. In my case, tradition rendering is broken (produces aliased data) as addressableSize() > 1 . Which make me want to remove it even more. https://bugs.eclipse.org/bugs/show_bug.cgi?id=167970 https://bugs.eclipse.org/bugs/show_bug.cgi?id=172224 https://bugs.eclipse.org/bugs/show_bug.cgi?id=161859 https://bugs.eclipse.org/bugs/show_bug.cgi?id=265361 etc... (as far as I can tell, these are all the same bug) There are other bugs, almost equally devastating. In summary, I would like an easy way to disable/hide the CDT Memory Browser, and pull the traditional rendering out of the memory viewer.
I've been saying the same ever since I found out about the memory browser. The situation points to there not having been a meeting of the minds, and an abandonment of efforts to come to a consensus. Perhaps the technical and design differences cannot be overcome and we really need to have two significantly different ways to let the user view memory. At a very minimum, there should be a single Memory view with the ability for the user to switch between presentation styles...maybe a "basic" or "simplified" presentation (browser), and the "classic" presentation. But making users deal with two *views* that basically do the same thing but in different ways is no doubt going to confuse the user and it makes us look like we don't have our act together. No doubt vendors shipping Eclipse-based products can decide to distribute only the view they think their customers want, but I'm worried about the experience for users of stock eclipse.
Both the traditional rendering and the memory browser are optional CDT components. The easiest way to disable them is not to install them in the first place. Two more possibilities: - Would you like it to be excluded from the "Eclipse IDE for C/C++ Developers" package download? - Would it help to have a capability defined for this feature. Capabilities can be turned on/off in the Preferences dialog.
BTW, I totally agree that the best thing would be to merge the two views, though the backward compatibility requirements in platform make this an expensive proposition.
Here's some history on the previous attempts to merge the two views: https://bugs.eclipse.org/bugs/show_bug.cgi?id=244822 (In reply to comment #1) I agree with you John. We should merge the Memory View and the Memory Browsing View. In addition, I also think that the traditional rendering needs to be enhanced to support addressable size > 1. And I also agree with Pawel, maintaining backwards compatibility makes this really difficult because the underlying design and assumptions are so different between the two views. I have put some thoughts into how we can merge the views. I looked at Ted's demo and came up with the following observations: 1) The UI workflow is much simpler. I think this is the major benefits of this view. 2) The Memory Browsing view can only show traditional rendering - is this true? How can adopters control what renderings to use in the browsing view? 3) The monitors pane and the second rendering pane is removed. This implies that every tab in the memory browsing view is backed by a new memory block. In the past, these are the major sticking points that prevent us from merging the two views: 1) Removing of the memory monitors pane and the split pane -> imply the removal of synchronization service. 2) Relaxing the rendering view pane to host renderings from different memory blocks. -> imply the breaking the sync service / need to rewrite the sync service. 3) Use of go to address bar as a global control in the view with no way to override. These changes break the following features in the Memory View with no replacement: 1) Address Space Support - because the user cannot override the go to address bar, adopters cannot prompt the user for additional information like address space when creating a memory monitor. Secondly, removal of the memory monitors pane prevents us from showing memory blocks grouped by address space. 2) IMemoryBlock Support - the use of go to address bar also prevents us to support the old IMemoryBlock since we need to prompt the user for the size of the memory block when this type of memory block is created. I do not know if this is THAT important since I doubt that we have many adopters that use the old IMemoryBlock interface. 3) Removal of split pane and sync service - in our debuggers, we make heavy use of the second rendering pane, to show customized renderings. This is a breaking change for existing debuggers that use this feature. My feeling is that the Memory Browsing View addresses the need of general use case, but cannot satisfy the more advanced requirements of the Memory View. But I also agree that we should not penalize users with complicated and confusing workflow. I think we should try to take the best of both views and try to come to a consensus on what the Memory View should look like. Now that everyone has seen both the Memory View and the Memory Browsing View, can I get some feedback on the following: 0) Memory View - what are the most confusing features in the Memory View that you would like to see removed? 1) Memory Monitors Pane - is it that useful? Can we remove it or make it a "fast-pane"? 2) Go to Address Bar - how critical is it to support address space when a memory block is created? What if we allow this widget to be customizable? 3) The importance of the the split pane and synchronization service - do other people use this other than us? 4) Memory Browsing View - what are some of the key features here that you think should be incorporated in the Memory View? Thanks...
(In reply to comment #4) > Here's some history on the previous attempts to merge the two views: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=244822 > > (In reply to comment #1) > > I agree with you John. We should merge the Memory View and the Memory Browsing > View. In addition, I also think that the traditional rendering needs to be > enhanced to support addressable size > 1. > > And I also agree with Pawel, maintaining backwards compatibility makes this > really difficult because the underlying design and assumptions are so different > between the two views. Not to ignore the many good questions/points you've brought up, Samantha, but I want to highlight what I suggested earlier, because it seems to me it lets us sidestep all those challenges. There's the idea of merging the functionality and usability of the two views (what you're discussing here), and the possibility of letting the two approaches co-exist within the same view as distinct modes (my suggestion). I.e., I think the biggest problem is not that we have two distinct GUIs for showing memory; it's that they're in distinct views. If we just let them coexist, then we need not worry about merging the features of the two views. The notion of an app presenting a simplified GUI and a more complex one for advanced users/capabilities is not new. I think the user would be OK with that. If we could find common grown between the two views and come up with an implementation that is backward compatible, that would be ideal. But if we can't, I think the two-mode approach is a reasonable alternative, and one that's better than having the two views (current situation).
(In reply to comment #5) > Not to ignore the many good questions/points you've brought up, Samantha, but I > want to highlight what I suggested earlier, because it seems to me it lets us > sidestep all those challenges. There's the idea of merging the functionality > and usability of the two views (what you're discussing here), and the > possibility of letting the two approaches co-exist within the same view as > distinct modes (my suggestion). Yup... I agree that this is also a good alternative. :) I just want to explore a bit, and figure out other ways of doing this before going down this path.
How about delegating the view instantiation to an IExecutableExtensionFactory which would create either the original Memory view or the Memory Browser, based on some preference setting. I'm sure there are issues with that (e.g. action contributions), but it might be worth for consideration.
FYI, Ted who implemented the memory browser and the traditional is out on vacation until after Thanksgiving, but I'm CC'ing Randy who may have answers to some of the questions on the view limitations.
FWIW, here is what my group is interested in. > Can I get some feedback on > the following: > 0) Memory View - what are the most confusing features in the Memory View that > you would like to see removed? I had no problem using the memory view as is. It seems pretty straight forward. That said, one criticism that I could possibly see here is that when you add a monitor, you have to type an expression in were the browser just comes up at address 0. For our case it turns out that we are supporting multiple address spaces Data, Program, ROM, etc. so it is great that the memory viewer has this functionality. It would be sad to see it removed. However, someone that doesn't have this requirement might want to be able to configure it so it just comes up to a predefined memory block / address. > 1) Memory Monitors Pane - is it that useful? Can we remove it or make it a > "fast-pane"? Yes, totally useful for the case of multiple address spaces. Sorry, I am not sure what a "fast-pane" is. Also, I would like to associate a default rendering with a memory block or address range. For example, if they go to ROM, I would like the default rendering to be a disassembly type rendering where if they are looking at data, hex is best. > 2) Go to Address Bar - how critical is it to support address space when a > memory block is created? What if we allow this widget to be customizable? When a block is created, customized UI would be very useful. I would like to have a pull down menu that shows the different address spaces that are available. Right now the user has to type in "rom 0x100" to look at ROM address 0x100. I am grateful that this works but wish it could be more self revealing. Another useful operation would be to be able to create Monitors programatically. For example, in a symbol view they could right click on a simple and select something like "View Memory" and it would pull up the right block type. > 3) The importance of the the split pane and synchronization service - do other > people use this other than us? It seems like you can do this to create some interesting renderings. Essentially you can create the "Traditional Rendering" using the split pane. With something like the traditional rendering it seems like the need for this is lessened. > 4) Memory Browsing View - what are some of the key features here that you > think should be incorporated in the Memory View? Since this view doesn't yet support our 16-bit units correctly, I haven't had a chance to really use it. > > Thanks... Thank you!
