RE: [dsdp-dd-dev] Re: [platform-debug-dev] proposal for memory viewaddre

[Samantha Chan <chanskw@xxxxxxxxxx>]

Ted -

What do you think about allowing the address column to be editable?  When
the user modifies the address column, the rendering will jump to the
location specified?
This would save real-esate as no address bar is required.  If the
renderings are synchronized, all renderings should jump to the same
location.  There is no need for new APIs in this case as this would be done
internally in the table renderings.

I still think the address bar solution is more user-friendly approach for
user.  However, given that API freeze is this Friday for 3.2 and the
limited time/resources that I have, I do not think I have time to add this
for 3.2.
I have submitted an enhancement report and will look at this after 3.2.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=126909

About replacing renderings, are you trying to switch from viewing memory as
HEX to viewing it as ASCII without having to create a new rendering?  There
is an enhancement request to allow user view memory in different
representations:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=114377

However, this representation enhancement requests is a little different
from replacing the rendering completely.  When viewing memory in different
representations, users are still looking at memory in a table, but they can
choose to see it as Hex, ASCII, intergers, etc.  By replacing the
rendering, user can switch from a table to a tree to a bit map and so on.

I just wish to find out why you see a need of replacing the rendering in
the tab.

Thanks...
Samantha



                                                                           
             "Williams, Ted"                                               
             <ted.williams@win                                             
             driver.com>                                                To 
             Sent by:                  "Device Debugging developer         
             platform-debug-de         discussions"                        
             v-bounces@eclipse         <dsdp-dd-dev@xxxxxxxxxxx>, "Eclipse 
             .org                      Platform Debug component developers 
                                       list."                              
                                       <platform-debug-dev@xxxxxxxxxxx>,   
             02/08/2006 01:28          Samantha Chan/Toronto/IBM@IBMCA     
             AM                                                         cc 
                                                                           
                                                                   Subject 
             Please respond to         RE: [dsdp-dd-dev] Re:               
             "Eclipse Platform         [platform-debug-dev] proposal for   
              Debug component          memory  viewaddress bar             
             developers list."                                             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Samantha,

"Regarding the user/plugin.xml configurable default rendering
preference, clients can already configure a set of default renderings
via plugin.xml."

Ooops, good point. The address bar could reposition the existing
renderings and when none exist, open the defaultIds set.

"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 think this is a valid concern and I've expressed the complaint myself.
However, I would find an address bar to be more valuable than the
existing table header, which probably occupies an equal amount of real
estate. Recognizing the address column is obvious and tooltips would
provide better annotation of cell addresses than operator use of the
header offsets. By providing a visible/hidden toggle for the address
bar, users would have the option to reclaim the space when desired.

Additionally, the request for better use of real estate can at least
partially be solved by implementing a mode for automatic adjustment of
the column count to fit the viewport. This way, only a vertical scroll
bar is ever presented.

"I do not think you would want an address bar per rendering.  You are
looking at having a global address bar for all renderings?"

That's correct. At the moment, I have an address bar in our rendering
prototype. This approach suffers the disadvantage of creating
inconsistency between 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.)"

Assuming we can agree on the concept, will the need for additional APIs
be a complete block?

Might there be alternative implementations not requiring API changes? In
place of issuing a goToAddress, could we replace the existing renderings
with new instances?

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