[dsdp-dd-dev] Re: [platform-debug-dev] proposal for memory view address

[Samantha Chan <chanskw@xxxxxxxxxx>]

Hi Ted -

Regarding the user/plugin.xml configurable default rendering preference,
clients can already configure a set of default renderings via plugin.xml.
When defining a rendering binding, you may define a list of renderings to
be created by default using the defaultIds attribute.  The rendering ids
specified here are considered as default renderings.  They can be queried
using IMemoryRenderingManager#getDefaultRenderingTypes(IMemoryBlock).  In
your case, you need to specify the hex and ASCII rendering in the
defaultIds attribute.

There is also a primaryIds attribute in a rendering binding.  The rendering
specified here is considered as the primary default rendering.

When a new memory block is created via the Memory View, the Memory View
will get a list of default renderings from the memory rendering manager.
The Memory View creates all the default renderings. The primary default
rendering is put in the view pane on the left hand side.  The rest of the
default renderings are put on the right hand side.

Currently, users cannot define a set of default renderings.  I do not think
that this preference should be defined and managed globally by the
platform.  This preference is model-specific and should be saved and
restored by models.  While a set of default renderings make sense for one
debugger, it may not be valid for another debugger.  One thing that the
platform could add is to have actions and dialogs that allow users to
define these default renderings.  But the preference itself should be saved
and restored by the model.  (This is similar to the row/column size
preference.)

The address bar proposal is a good idea.  Here are some thoughts about it:
   Workbench real-estate - The address bar will take up more room in the
   view and will require the view to be even bigger for it to be workable.
   I have heard complains that the Memory View requires too much
   real-estate to run.  The address bar will only make the problem worse.
   I do not think you would want an address bar per rendering.  You are
   looking at having a global address bar for all renderings?
   #goToAddress method is not part of IMemoryRendering.  This means that
   not all renderings are capable of doing the #goToAddress action.  To
   implement the a global address bar, we will need new APIs.  (Similar to
   IResettableMemoryRendering.)

Thanks...
Samantha



                                                                           
             "Williams, Ted"                                               
             <ted.williams@win                                             
             driver.com>                                                To 
             Sent by:                  <dsdp-dd-dev@xxxxxxxxxxx>,          
             platform-debug-de         <platform-debug-dev@xxxxxxxxxxx>,   
             v-bounces@eclipse         Samantha Chan/Toronto/IBM@IBMCA     
             .org                                                       cc 
                                                                           
                                                                   Subject 
             02/06/2006 01:42          [platform-debug-dev] proposal for   
             PM                        memory view address bar             
                                                                           
                                                                           
             Please respond to                                             
             "Eclipse Platform                                             
              Debug component                                              
             developers list."                                             
                                                                           
                                                                           





hi Samantha,

I'd like to propose a memory view UI enhancement for the purpose of
improving workflow.

When I open the memory view, I almost always have a destination address in
mind. I immediately create a new rendering, entering the address in the new
rendering dialog. Often, I find it necessary to reposition the rendering to
another address while debugging. I've been using the "Go to Address..."
context menu item and it works, but it takes several clicks.

How would you feel about adding a user toggleable address bar along with a
user/plugin.xml configurable default rendering preference? This would
improve two common user scenarios:

1) Opening the memory view to an address. It would only be necessary to
show the memory view and enter an address. I imagine most users have a
favorite rendering. I tend to use "hex" (or mixed hex/ASCII where
available) most of the time.

2) Repositioning a rendering to another address. It would only take
entering the address in the address bar. Imagine what the workflow would be
if our web browsers lacked the address bar. We'd be using "File -> Open
Location" all day. In addition to reducing the complexity (clicks) of this
common task, the address bar would standardize navigation across all
renderings. (GoToAddressAction is programmatically instantiated in
AbstractAsyncTableRendering.)

As a lower priority topic, I think it'd be interesting to consider allowing
renderings to be replaced. It ought to be simpler to replace an existing
hex rendering with an ASCII rendering while retaining the viewport top
address.

thanks,
ted

 _______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev