Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Renaming "DSF Disassembly"
I think the toolbar is perfect how it is.  I'm less happy with the view menu and context menu contents.  There just seems to be random inconsistency with them.  Again, minor nitpicking. 
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Mehregani, Navid
Sent: Friday, February 19, 2010 9:56 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] Renaming "DSF Disassembly"

Warren,

Here’s my 2 cents…

>Also some nitpicking on the UI.  The toolbar has goto, refresh, home and show source.  The view menu has find, home,
>goto and show source.  The context menu has >copy, select all, show source, show symbols and prefs.  When you go
>to the prefs there are 5 different boolean options.  I guess I just find the current organization a bit strange for some reason.

I personally find the toolbar very intuitive and I don’t think it should be changed. 
The toolbar *menu* is kind of hidden and not a lot of users will use it.  Most of the actions in this menu are a duplicate of the toolbar actions, which provide a text-based description of the actions (similar to action tooltips).  The ‘Find’ operation will very likely be accessed via the global Ctrl+F keyboard shortcut, which is why it wasn’t included in the toolbar.  I think ‘preferences’ should also be in the toolbar *menu*.
I don’t see anything wrong with the context menu either.

Also, more nitpicking on the prefs.  Shouldn't the address display format be indented under "Show instruction address" and be enabled/disabled accordingly?  Also, no tooltips. 

I agree.  I think you should file a bugzilla for this.  I can submit a patch for it.

Most options are very obvious, but not necessarily "Force Radix prefixes".

I also agree.  I think we should have a tooltip on this radio button.  You can probably include it in the same bugzilla.

Regards,
 Navid

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren.Paul@xxxxxxxxx
Sent: Friday, February 19, 2010 10:32 AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Renaming "DSF Disassembly"

 

I updated my sources last night and just did some testing with our EDC and our CDI debuggers.  For the most part it looks great! 

 

I did fix one NPE I got when scrolling with our CDI debugger that I'll check in shortly.  I also see these in the console so they should be cleaned up:

 

!MESSAGE NLS unused message: Disassembly_GotoSymbolDialog_title in: org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyMessages

!MESSAGE NLS unused message: Disassembly_GotoSymbolDialog_label in: org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyMessages

!MESSAGE NLS missing message: Disassembly_GotoAddressDialog_error_not_a_number in: org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyMessages

 

Also some nitpicking on the UI.  The toolbar has goto, refresh, home and show source.  The view menu has find, home, goto and show source.  The context menu has copy, select all, show source, show symbols and prefs.  When you go to the prefs there are 5 different boolean options.  I guess I just find the current organization a bit strange for some reason.

Also, more nitpicking on the prefs.  Shouldn't the address display format be indented under "Show instruction address" and be enabled/disabled accordingly?  Also, no tooltips.  Personal pet peeve of mine.  Most options are very obvious, but not necessarily "Force Radix prefixes".

So at what point do we pull the old view and rename this one?  I guess we also need to move the prefs from under DSF into just CDT.  What else?

 

Thanks,
Warren

 

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Mehregani, Navid
Sent: Tuesday, February 16, 2010 7:56 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Renaming "DSF Disassembly"

Hi John,

 

Thanks for your effort.  Here are my findings.  I hope you find them useful:

 

1)  Jump to address combo box and 'Go to address' action under toolbar menu are not working.  If these features are not supported for CDI, then we should probably disable or hide them.

 

2) Clicking on 'View Disassembly' from <unknown> editor, opens up CDI disassembly instead of DSF disassembly. I guess this can be switched when we replace CDI's disassembly.  <unknown> editor pops up after starting a debug session and the source file cannot be found.

 

3) Resize disassembly view to a small size, start a debug session, now resize it a bigger size, notice the empty lines  in disassembly view.  Clicking on refresh doesn't resolve the issue.  Reselecting the stack frame populates the empty lines.  I believe this is a general problem with disassembly view.  I reproduced it with  DSF debugger too.

 

 

- There are dotted lines displayed between each source line (see snapshot below):

 

 

- I somehow get the following exception.  Sometimes I get it when I start a debug session and sometimes I get it when I switch between views and switch back to DSF Disassembly.

 

java.lang.ArrayIndexOutOfBoundsException: 1

at org.eclipse.cdt.debug.internal.ui.disassembly.dsf.DisassemblyBackendCdi.retrieveFrameAddress(DisassemblyBackendCdi.java:177)

at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart.gotoFrame(DisassemblyPart.java:2077)

at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart.gotoFrame(DisassemblyPart.java:2036)

at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart.gotoFrameIfActive(DisassemblyPart.java:2045)

at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart.setActive(DisassemblyPart.java:1789)

at org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart$1.partVisible(DisassemblyPart.java:296)

at org.eclipse.ui.internal.PartListenerList2$7.run(PartListenerList2.java:172)

at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)

at org.eclipse.core.runtime.Platform.run(Platform.java:888)

at org.eclipse.ui.internal.PartListenerList2.fireEvent(PartListenerList2.java:55)

at org.eclipse.ui.internal.PartListenerList2.firePartVisible(PartListenerList2.java:170)

at org.eclipse.ui.internal.PartService.firePartVisible(PartService.java:253)

at org.eclipse.ui.internal.WorkbenchPagePartList.firePartVisible(WorkbenchPagePartList.java:68)

at org.eclipse.ui.internal.PartList.partVisible(PartList.java:288)

at org.eclipse.ui.internal.PartList.access$2(PartList.java:277)

at org.eclipse.ui.internal.PartList$1.propertyChanged(PartList.java:47)

at org.eclipse.ui.internal.WorkbenchPartReference.fireInternalPropertyChange(WorkbenchPartReference.java:375)

at org.eclipse.ui.internal.WorkbenchPartReference.fireVisibilityChange(WorkbenchPartReference.java:536)

at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:318)

at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:529)

at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180)

at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270)

at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)

at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)

at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1254)

at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1207)

at org.eclipse.ui.internal.PartStack.presentationSelectionChanged(PartStack.java:841)

at org.eclipse.ui.internal.PartStack.access$1(PartStack.java:827)

at org.eclipse.ui.internal.PartStack$1.selectPart(PartStack.java:137)

at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation$1.handleEvent(TabbedStackPresentation.java:133)

at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:269)

at org.eclipse.ui.internal.presentations.util.AbstractTabFolder.fireEvent(AbstractTabFolder.java:278)

at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder.access$1(DefaultTabFolder.java:1)

at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder$2.handleEvent(DefaultTabFolder.java:88)

at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)

at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1050)

at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1074)

at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1059)

at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:773)

at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.java:3278)

at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:2049)

at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:331)

at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)

at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1050)

at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3984)

at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3577)

at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2407)

at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2371)

at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220)

at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)

at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)

at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)

at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)

at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)

at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)

at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)

at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)

at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:367)

at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:611)

at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566)

at org.eclipse.equinox.launcher.Main.run(Main.java:1363)

at org.eclipse.equinox.launcher.Main.main(Main.java:1339)

 

 

Let me know if you have any questions.

 

Regards,

 Navid

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Monday, February 15, 2010 10:38 AM
To: CDT General developers list.; CDT General developers list.
Subject: RE: [cdt-dev] Renaming "DSF Disassembly"

 

Navid, I just committed the changes to HEAD. I'll take you up on your offer to test it :-) I've done quite a bit of testing myself, but more would be better.

John

At 03:33 PM 2/5/2010, Mehregani, Navid wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_496565EC904933469F292DDA3F1663E602AA658233dlee06enttico_"

Great!!
Let me know if you need help with testing it.
 
Navid
 

From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Thursday, February 04, 2010 9:07 PM
To: CDT General developers list.; CDT General developers list.
Subject: RE: [cdt-dev] Renaming "DSF Disassembly"
 
I've been working this week on refactoring the DSF disassembly view to work with both DSF and CDI and I just had my first CDI session where it appears to be mostly working. (Naturally, I got DSF working first)

I'm not going to raise the victory flag just yet, though. I'll update again when I've gotten all the features working. Just wanted to let people know work on it is progressing and looking encouraging.

John

At 08:49 AM 1/14/2010, Mehregani, Navid wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_496565EC904933469F292DDA3F1663E602AA311636dlee06enttico_"

We can open a Bugzilla entry after we determine this to be feasible.
Perhaps we can further discuss this in the next CDT monthly meeting.
 
Thanks,
 Navid
 

From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Wednesday, January 13, 2010 5:53 PM
To: CDT General developers list.; CDT General developers list.
Subject: RE: [cdt-dev] Renaming "DSF Disassembly"
 
There is no bugzilla entry for it but feel free to create one. We can use it to record our results.

I'm hoping we will have it done in time for 7.0. We're still trying to determine the feasibility of it, so I can't say for sure it will happen. But I can tell you someone is actively working on it and that we'll keep everyone posted, whichever way it ends up going.

John


At 04:48 PM 1/13/2010, Mehregani, Navid wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_496565EC904933469F292DDA3F1663E602AA31153Cdlee06enttico_"

Hi John,
 
Is this planned for CDT 7.0? Is there a bugzilla entry for it?
 
Thanks,
 Navid

From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Wednesday, January 13, 2010 5:19 PM
To: CDT General developers list.; cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Renaming "DSF Disassembly"
 
We are actively working on retrofitting the DSF Disassemby view to work with CDI, thus making the non-DSF one obsolete. If we are successful, this will address your concern, since there will only be one view.

John

At 04:16 PM 1/13/2010, Mehregani, Navid wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_496565EC904933469F292DDA3F1663E602AA31150Cdlee06enttico_"

Hello,
 
Ive used activities to hide CDIs Disassembly view.  Our product is only shipped with DSF Disassembly view.  However, our users dont know or care about DSF.  Im sure most CDT users (not developers) really know what DSF/CDI is.
At first I thought about hiding the DSF Disassembly view via activities and redefining it with a new name, but that doesnt work since DisassemblyView class is in an internal package thats not exported.  I assume the community wouldnt want to export this package?  I obviously dont want to duplicate the code in DisassemblyView and DisassemblyPart. 
 
Does anyone else have this problem? Does it make sense to rename DSF Disassembly to something that would be a bit more meaningful to CDT users? (similar to Memory and Memory Browser views). 
 
Thanks for your help,
 
- Navid
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top