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

[Samantha Chan <chanskw@xxxxxxxxxx>]

Hi Ted -

>> I almost suggested this as a possible solution in my last post. We've
>> done it in the past. It's a deviation from customary user interface, I
>> think.

I agree.  We used to do this too, but I removed it because I found it
confusing.  I see this as a work-around, not a final solution.

If we can live with a non-global address bar for now, then we could add the
address bar to the table rendering without having to add the APIs.  The
synchronization will continue to keep all renderings in sync in this case.
We can do this:
*  Add shortcut key CTRL+G to invoke the go to address action.
* When the action is invoked, we can display an address bar at the bottom
of the table rendering.  The address bar allows user to specify an address
to go to.
* Typing enter will make the rendering go to the specified address.  The
address bar will become hidden again.
* User can also hide the address bar by typing ESC.
* The address bar can also be invoked using the GoToAddress context menu
action.

I opened this enhancement request for it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=127147

>> Would all of the address cells be editable? Or only the first? If all
>> are to be editable, would the entered address become the viewport start
>> address? Or would the start address be calculated as an offset based on
>> the position of the edited cell? I don't have a preference, but this
>> ought to be consistent among renderings. Choose a model and document it?

If we go down this path, then all address cells should be editable.  The
address entered will be the actual address to go to, not an offset.  (Maybe
if the user enter + / - before a string, then we will treat it as an
offset.)  I will document if this solution is implemented.

>> In the next cycle, I'll strive to provide feedback the moment
>> it becomes welcome.

I look forward to that... :)  I really appreciate your feedback.  It's how
we can make the view better.

Thanks...
Samantha



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





Samantha,

"What do you think about allowing the address column to be editable?"

I almost suggested this as a possible solution in my last post. We've
done it in the past. It's a deviation from customary user interface, I
think.

Would all of the address cells be editable? Or only the first? If all
are to be editable, would the entered address become the viewport start
address? Or would the start address be calculated as an offset based on
the position of the edited cell? I don't have a preference, but this
ought to be consistent among renderings. Choose a model and document it?

Even with a consistent model, slight variations in appearance of edit UI
between renderings may result in a less than ideal impression, similar
to that created by mixing swt with swing.

Also, I'm not sure if most users would find editable address cells to be
an obvious form of navigation. Sure, they'll learn, but it's a drawback.

"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"

I agree. In the next cycle, I'll strive to provide feedback the moment
it becomes welcome. I'm actually surprised by the lack of memory view
feedback. Has anyone else authored a rendering, yet? Does silence
indicate complete satisfaction?

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

Sorry for the confusion. This idea was in response to your statement
about API changes being necessary in order to implement a global address
bar. I wondered if it would be possible to tear down the existing
renderings and create new instances at the new memory block as an
alternative to new APIs.

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