[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-dd-dev] Re: AsynchronousTreeViewer and IMemoryBlockRetrieval
|
Hi all -
I investigated using the current debug context as the tree viewer's input.
The purpose of this change is to allow IMemoryBlockRetrieval objects to not
extend from PlatformObject. It also makes the view more flexible by
allowing any debug element as its viewer input.
Currently, the Memory View shows the following hierarchy in the tree view
pane:
IMemoryBlockRetrieval -> IMemoryBlock
If the current debug context is used, the Memory View shows hierarchy as
follows:
IDebugTarget -> IMemoryBlock (if a debug target is selected)
IThread -> IMemoryBlock (if a thread is selected)
IStackframe -> IMemoryBlock (if a stackframe is selected)
To be backward compatible, the platform will have to provide content
adapters to IDebugTarget, IThread and IStackframe. These content adapters
discovers the IMemoryBlockRetrieval that is associated with the selected
debug element and returns a list of memory blocks from the same memory
block retrieval.
The platform also needs to provide a model proxy for IDebugTarget, IThread
and IStackframe for the Memory View. The model proxy responds to memory
block added / removed event and updates its view accordingly.
The new approach presents a number of problems:
* It causes the Memory View to flash more. Every time the selection is
changed in the Debug View, the Memory View's tree view pane will have to
change its input to the newly selected debug element. This causes the
Memory View selection to change and will cause the renderings to refresh
unnecessarily.
* It also causes the view to interact with its model more. Whenever the
debug context is changed, the tree view pane will be updated. It causes
the renderings to get updated and will have to get memory from their models
again. This could pose performance problems if getting memory is slow.
* User experience suffers because expansion and selection cannot be
maintained properly when a different debug element is selected. For
example, the Memory View shows two address spaces, Address Space A and
Address Space B. Under each address space, we have Memory Block A and
Memory Block B. When StackFrame A is selected from the debug view, the
user has expanded Address Space A and selected Memory Block A. As the user
switches to StackFrameB, the Memory View is forced to change the input to
the viewer. And since the viewer has not previously shown that input, the
viewer is not able to maintain expansion and selection in the view. To see
the same memory block, the user must manually expand and select the same
memory block again.
* Finally, if a client ever wants to show a different hierarchy in the
tree view pane, a client has to override a lot more adapters than it used
to. In the "old" world, a client only needs to override the content
adapter for its IMemoryBlockRetrieval and to provide customized model proxy
for its IMemoryBlockRetrieval. In the new world, a client must override
content adapters for all elements that can show up in the debug view. It
also needs to provide customized proxies for all the debug elements that
might show up in the Debug View. The new approach makes it more difficult
for a client to show flexible hierarchy in the Memory View.
Looking at these problems. I am not convinced that allowing the current
debug context to be the viewer input is the correct way to go. The Memory
View is really intended to show a hierarchy under an IMemoryBlockRetrieval.
Allowing any object as viewer input and providing adapters for these
objects feel like a hack to me. The only benefit resulted from this change
is that IMemoryBlockRetrieval does not have to implement PlatformObject.
The extra flexibility can be achieved by returning a different memory
retrieval based on the selected debug element.
I do not have a strong use case for this change. I plan on using
IMemoryBlockRetrieval as the tree viewer's input in the Memory View for 3.2
and IMemoryBlockRetrieval objects must subclass from PlatformObject..
However, if you have a use case for this change, please let me know. Maybe
it will help me better understand the different hierarchies.
Also, if you have any question, please let me know.
Thanks...
Samantha
"Mikhail
Khodjaiants"
<mikhailk@xxxxxxx To
> "Eclipse Platform Debug component
Sent by: developers list."
platform-debug-de <platform-debug-dev@xxxxxxxxxxx>
v-bounces@eclipse cc
.org
Subject
Re: [platform-debug-dev]
12/30/2005 12:50 AsynchronousTreeViewer and
PM IMemoryBlockRetrieval
Please respond to
"Eclipse Platform
Debug component
developers list."
> Maybe what we need is to
> update the java docs and mark the internal APIs as "experimental"?
That would be very helpful.
Thanks.
----- Original Message -----
From: "Samantha Chan" <chanskw@xxxxxxxxxx>
To: "Eclipse Platform Debug component developers list."
<platform-debug-dev@xxxxxxxxxxx>
Sent: Thursday, December 29, 2005 7:47 PM
Subject: Re: [platform-debug-dev] AsynchronousTreeViewer and
IMemoryBlockRetrieval
> Hi Mikhail -
>
> There is now a bug entry for this work item: : )
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=122349
>
> I believe extending from platform's debug target content adapter should
> be
> the right solution.
>
> As to distinguish what classes and interfaces are going to be public, I
> do
> not think we have a systematic way of doing it. Maybe what we need is
> to
> update the java docs and mark the internal APIs as "experimental"?
>
> Thanks...
> Samantha
>
>
>
>
>
> "Mikhail
>
> Khodjaiants"
>
> <mikhailk@xxxxxxx
> To
> > "Eclipse Platform Debug component
>
> Sent by: developers list."
>
> platform-debug-de <platform-debug-dev@xxxxxxxxxxx>
>
> v-bounces@eclipse
> cc
> .org
>
>
> Subject
> Re: [platform-debug-dev]
>
> 12/29/2005 04:58 AsynchronousTreeViewer and
>
> PM IMemoryBlockRetrieval
>
>
>
>
>
> Please respond to
>
> "Eclipse Platform
>
> Debug component
>
> developers list."
>
>
>
>
>
>
>
>
>
> Samantha,
>
> > One of the things on my to-do list is to remove the requirement of
> > passing
> > IMemoryBlockRetrieval object to the tree viewer as the input.
>
> Is there a bugzilla entry for it?
>
> Thanks,
> Mikhail
>
> ----- Original Message -----
> From: "Samantha Chan" <chanskw@xxxxxxxxxx>
> To: "Eclipse Platform Debug component developers list."
> <platform-debug-dev@xxxxxxxxxxx>
> Sent: Thursday, December 29, 2005 10:00 AM
> Subject: Re: [platform-debug-dev] AsynchronousTreeViewer and
> IMemoryBlockRetrieval
>
>
> > Hi -
> >
> > One of the things on my to-do list is to remove the requirement of
> > passing
> > IMemoryBlockRetrieval object to the tree viewer as the input.
> Instead,
> > the
> > current debug context will be passed as the input to the viewer. It's
> > up
> > to the content adapter of that object to retrieve the correct
> > IMemoryBlockRetrieval and associated memory blocks when asked to
> > populate
> > the view. This approach will make the viewer more flexible as any
> > object
> > can now become the input to the viewer. It also removes the needs of
> > making IMemoryBlockRetrieval an IAdaptable.
> >
> > So, for the modules view, is it possible for your viewer to accept any
> > object as input. And then the content adapter of that object will be
> > responsible for getting the modules?
> >
> > Thanks...
> > Samantha
> >
> >
> >
> >
> >
> > "Mikhail
> >
> > Khodjaiants"
> >
> > <mikhailk@xxxxxxx
> > To
> > >
> <platform-debug-dev@xxxxxxxxxxx>
> >
> > Sent by:
> > cc
> > platform-debug-de
> >
> > v-bounces@eclipse
> > Subject
> > .org [platform-debug-dev]
> >
> > AsynchronousTreeViewer and
> >
> > IMemoryBlockRetrieval
> >
> > 12/28/2005 02:49
> >
> > PM
> >
> >
> >
> >
> >
> > Please respond to
> >
> > "Eclipse Platform
> >
> > Debug component
> >
> > developers list."
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > An IMemoryBlockRetrieval object is passed to the Memory view's viewer
> as
> > an
> > input. This object is required to be an instanceof of IAdaptable to
> work
> > with AsynchronousTreeViewer.
> > The IMemoryBlockRetrieval interface defines a functionality, not a
> model
> > object and I am not sure if it is right to make it adaptable.
> > I implemented the CDT Modules view based on the asynchronous tree
> > viewer,
> > but I had the same problem - I had to make the object responsible for
> > the
> > modules retrieval to extend PlatformObject.
> >
> > Thanks,
> > Mikhail Khodjaiants
> > QNX Software Systems _______________________________________________
> > platform-debug-dev mailing list
> > platform-debug-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
> >
> >
> > _______________________________________________
> > platform-debug-dev mailing list
> > platform-debug-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
>
>
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
