Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316987

Summary: Show full paths preference under C/C++->Debug is not really necessary
Product: [Tools] CDT Reporter: Warren Paul <warren.paul>
Component: cdt-debugAssignee: John Cortell <john.cortell>
Status: RESOLVED FIXED QA Contact: Ken Ryall <ken.ryall>
Severity: normal    
Priority: P3 CC: elaskavaia.cdt, john.cortell, marc.khouzam, nobody, pawel.1.piech
Version: 7.0Flags: nobody: review+
Target Milestone: 7.0.1   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Fix
john.cortell: iplog-
Additional changes
john.cortell: iplog-
Additional changes john.cortell: iplog-

Description Warren Paul CLA 2010-06-15 19:28:54 EDT
Warren, it does indeed look like the preference is unused. My guess is that it was used prior to the introduction of the view menu action, but then orphaned and not cleaned up. I think ShowFullPathsAction should not have reused ICDebugPreferenceConstants.PREF_SHOW_FULL_PATHS, but rather given a new ID. The current state of things is pretty confusing, so please consider that additional cleanup if you remove the widget from the preference page. I.e., get rid of the field ICDebugPreferenceConstants.PREF_SHOW_FULL_PATHS altogether (but keep using the ID for backwards compatibility).

John

At 04:33 PM 6/15/2010, Warren.Paul@nokia.com wrote:

This is under the “Opened view default settings” group in CDebugPreferencePage.  It doesn’t appear to be hooked up to either CDI or DSF debuggers.  There are actions on the Debug and Breakpoints view to toggle this option for each view.  Can/should this preference be removed?
 
Thanks,
Warren
 
_______________________________________________
cdt-dev mailing list
cdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Comment 1 Marc Khouzam CLA 2010-06-15 22:28:57 EDT
I believe this preference is meant to trigger the very first time the debug view and breakpoints view is opened.    The way I imagine it
is that if you create a new workspace and you import your preference file, you can have the debug/breakpoints view show full paths
or not based on that preference, instead of having to set the option manually in the view.

From what I see it is being used by
ShowFullPathsAction#init (from ViewFilterAction) which calls getPreferenceValue(), which will check that preference but only
if the view in question doesn't have it set specifically (i.e., only the first time the view is opened, in a new workspace).
This logic works for both CDI and DSF (bug 248627)
Comment 2 John Cortell CLA 2010-06-16 08:17:25 EDT
(In reply to comment #1)
> I believe this preference is meant to trigger the very first time the debug
> view and breakpoints view is opened.    The way I imagine it
> is that if you create a new workspace and you import your preference file, you
> can have the debug/breakpoints view show full paths
> or not based on that preference, instead of having to set the option manually
> in the view.
> 
> From what I see it is being used by
> ShowFullPathsAction#init (from ViewFilterAction) which calls
> getPreferenceValue(), which will check that preference but only
> if the view in question doesn't have it set specifically (i.e., only the first
> time the view is opened, in a new workspace).
> This logic works for both CDI and DSF (bug 248627)

Wow. I overlooked the use of the base preference key string in ViewFilterAction.getPreferenceValue(). I saw the code adding the string to the view id, as it does in other places. Talk about some code that could have used a little documentation to state the non-obvious.

Personally, I don't like that mechanism. To have a preference exposed in the GUI that only has an effect the next time your create a workspace is a head-scratcher in my book. I'm sure there are exceptions where that kind of pref makes sense, but certainly not here. The action should simply persist the per-view state every time it's changed. That will provide desirable/expected behavior 99% of the time when creating a new workspace and importing the pref file, no?

Note that the show full path action is the ONLY action using this mechanism (at least, subclassing ViewFilterAction), so that tells me it is doing something out of the ordinary.
Comment 3 Marc Khouzam CLA 2010-06-16 08:50:41 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > I believe this preference is meant to trigger the very first time the debug
> > view and breakpoints view is opened.    The way I imagine it
> > is that if you create a new workspace and you import your preference file, you
> > can have the debug/breakpoints view show full paths
> > or not based on that preference, instead of having to set the option manually
> > in the view.
>
> Personally, I don't like that mechanism. To have a preference exposed in the
> GUI that only has an effect the next time your create a workspace is a
> head-scratcher in my book.

That behavior was there before, and maybe there is another case where this behavior makes sense.  I know Mikhail was using it.

> I'm sure there are exceptions where that kind of
> pref makes sense, but certainly not here. The action should simply persist the
> per-view state every time it's changed. That will provide desirable/expected
> behavior 99% of the time when creating a new workspace and importing the pref
> file, no?

Now that you mention it, as soon as the view is opened, it stores the general preference as a view-specific preference setting, which I believe is also stored when exporting preferences.  Therefore, my scenario is only useful if you've exported your preferences without having opened one of the Debug or Breakpoints view.

So I agree that this seems like a pretty rare case to have a global preference just for it.

So, I second the motion to remove that global preference.

However, I would like to get confirmation from Mikhail, as I may be missing some information on this.

> Note that the show full path action is the ONLY action using this mechanism (at
> least, subclassing ViewFilterAction), so that tells me it is doing something
> out of the ordinary.

Yeah, I was surprised too that there was this ViewFilterAction base class that no-one else used.
Comment 4 Nobody - feel free to take it CLA 2010-06-16 09:55:24 EDT
(In reply to comment #2)
> Wow. I overlooked the use of the base preference key string in
> ViewFilterAction.getPreferenceValue(). I saw the code adding the string to the
> view id, as it does in other places. Talk about some code that could have used
> a little documentation to state the non-obvious.
>
> Personally, I don't like that mechanism. To have a preference exposed in the
> GUI that only has an effect the next time your create a workspace is a
> head-scratcher in my book. I'm sure there are exceptions where that kind of
> pref makes sense, but certainly not here. The action should simply persist the
> per-view state every time it's changed. That will provide desirable/expected
> behavior 99% of the time when creating a new workspace and importing the pref
> file, no?
> 
In general, it's a common approach (not an exception) to have a global preference that affects all settings. Not sure if it works in this case, but by using "Reset Perspective" action users should be able to reset the default values of all UI related properties, so this is not only a one time preference.

> Note that the show full path action is the ONLY action using this mechanism (at
> least, subclassing ViewFilterAction), so that tells me it is doing something
> out of the ordinary.

As far as I remember the ViewFilterAction class was simply copied from the platform. It implements an enablement mechanism. For instance, "Show full paths" it is enabled only for ICBreakpoint and ICDebugElement elements in the Breakpoints and Debug views. At that time I thought it would be useful to have an abstract class. Don't forget that this was implemented long before the action enablement mechanism was introduced.
Comment 5 John Cortell CLA 2010-06-16 10:22:43 EDT
(In reply to comment #4)
> In general, it's a common approach (not an exception) to have a global
> preference that affects all settings. Not sure if it works in this case, but by
> using "Reset Perspective" action users should be able to reset the default
> values of all UI related properties, so this is not only a one time preference.

I just don't see this approach being of any practical use for this particular action (maybe in other cases, it does). I'd be *extremely* surprised if any user understands what that global preference represents (how it affects behavior), and even more surprised if they rely on it. It took three CDT developers to look at the code to understand what the preference does, and even now there's still some doubts.
Comment 6 Nobody - feel free to take it CLA 2010-06-16 12:33:07 EDT
(In reply to comment #5)
> I just don't see this approach being of any practical use for this particular
> action (maybe in other cases, it does). I'd be *extremely* surprised if any
> user understands what that global preference represents (how it affects
> behavior), and even more surprised if they rely on it. It took three CDT
> developers to look at the code to understand what the preference does, and even
> now there's still some doubts.

John, I don't mind removing this particular preference. The issue is not worth the time we have spent discussing it. I was just trying to explain what why it was implemented in this particular way.
Comment 7 John Cortell CLA 2010-06-16 16:00:25 EDT
Created attachment 172069 [details]
Fix

Thanks, Mikhail. Here's a patch. Can you please review it?
Comment 8 John Cortell CLA 2010-06-16 16:02:25 EDT
Committed to HEAD. Commit to 7_0 branch pending code review.
Comment 9 Marc Khouzam CLA 2010-06-16 16:56:23 EDT
(In reply to comment #7)
> Created an attachment (id=172069) [details]
> Fix accidental regression in last commit. Also, enhanced documentation

Weird patch name :-)

I had a look at the patch since I played with this stuff not long ago.
I think this makes the preferences clearer for the user but also makes the code clearer.

1- Can we move the ShowFullPathsAction.PREF_KEY to a Constants file that is also accessible by DsfLaunch?  That would avoid having a copy of that id in DsfLaunch, which is not nice.

2- CDebugPreferencePage line 178 has a comment that should be removed.

3- PreferenceMessages#CDebugPreferencePage.5 can probably be removed

4- Maybe fix the comment above DsfLaunch.PREF_SHOW_FULL_PATHS (depening on #1)

5- I haven't tested it, but I believe that when starting from a fresh workspace (or resetting the perspective?), the showFullPath option will now be off, when the default used to be on.  Do you think this will annoy the user?  I think the only way around it is to put back the IS_SET trick...
Comment 10 John Cortell CLA 2010-06-16 17:26:52 EDT
Created attachment 172077 [details]
Additional changes
Comment 11 John Cortell CLA 2010-06-16 17:27:17 EDT
Comment on attachment 172077 [details]
Additional changes

Additional changes based on Marc's review.
Comment 12 John Cortell CLA 2010-06-16 17:32:22 EDT
(In reply to comment #9)
> Weird patch name :-)

That's auto-completion for you. Usually a friend, but not always.

> 1-4. 

Done.

> 5- I haven't tested it, but I believe that when starting from a fresh workspace
> (or resetting the perspective?), the showFullPath option will now be off, when
> the default used to be on.  Do you think this will annoy the user?  I think the
> only way around it is to put back the IS_SET trick...

I think this is actually nicer, but that's just my preference. File paths are usually pretty long, making it quite a pain, and most source files are unique in a project. But, if someone objects, I can restore the previous behavior. BTW, the off state is not re-introduced on a perspective reset. It happens only for a new workspace.

Please review latest patch. Will hold off on comitting.
Comment 13 Nobody - feel free to take it CLA 2010-06-16 17:55:41 EDT
While I was installing the latest version and creating a new workspace Marc beat me with the review (thanks!). I agree with his comments except #5 - I think having "Show Full Paths" turned off by default is a good idea, hope nobody will notice this change.
Comment 14 Marc Khouzam CLA 2010-06-16 21:38:54 EDT
(In reply to comment #12)

> (In reply to comment #9)
> > 1-4. 
> 
> Done.

Thanks.
I didn't see changes to DsfLaunch, but I'm assuming you just forgot to include it in the posted patch?

> I think this is actually nicer, but that's just my preference.

(In reply to comment #13)
> I think having "Show Full Paths" turned off by default is a good idea,

That's fine with me then.
Since it will be in both HEAD and 7.0.1, I'm sure someone will say something by the time 7.0.1 is released, if they are really bothered by it.
Comment 15 John Cortell CLA 2010-06-17 14:23:41 EDT
Created attachment 172147 [details]
Additional changes
Comment 16 Marc Khouzam CLA 2010-06-17 14:29:19 EDT
(In reply to comment #15)
> Created an attachment (id=172147) [details]
> Additional changes

Looks good to me.
Thanks
Comment 17 John Cortell CLA 2010-06-17 14:44:47 EDT
Committed to HEAD and cdt_7_0.
Comment 18 Elena Laskavaia CLA 2010-06-29 11:11:08 EDT
*** cdt cvs genie on behalf of jcortell ***
Bug 316987: Show full paths preference under C/C++-&gt;Debug is not really necessary

[*] IDsfDebugUIConstants.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/ui/IDsfDebugUIConstants.java?root=Tools_Project&r1=1.5&r2=1.6

[*] ICDebugPreferenceConstants.java 1.22 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/preferences/ICDebugPreferenceConstants.java?root=Tools_Project&r1=1.21&r2=1.22
[*] CDebugPreferencePage.java 1.32 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/preferences/CDebugPreferencePage.java?root=Tools_Project&r1=1.31&r2=1.32

[*] ShowFullPathsAction.java 1.12 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/actions/ShowFullPathsAction.java?root=Tools_Project&r1=1.11&r2=1.12
[*] ViewFilterAction.java 1.12 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/actions/ViewFilterAction.java?root=Tools_Project&r1=1.11&r2=1.12

[*] IDsfDebugUIConstants.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/ui/IDsfDebugUIConstants.java?root=Tools_Project&r1=1.6&r2=1.7

[*] ICDebugInternalConstants.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.core/src/org/eclipse/cdt/debug/internal/core/ICDebugInternalConstants.java?root=Tools_Project&r1=1.5&r2=1.6
[*] MANIFEST.MF 1.27 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.core/META-INF/MANIFEST.MF?root=Tools_Project&r1=1.26&r2=1.27

[*] DsfLaunch.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf/src/org/eclipse/cdt/dsf/debug/model/DsfLaunch.java?root=Tools_Project&r1=1.6&r2=1.7

[*] PreferenceMessages.properties 1.17 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/preferences/PreferenceMessages.properties?root=Tools_Project&r1=1.16&r2=1.17
[*] CDebugPreferencePage.java 1.33 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/preferences/CDebugPreferencePage.java?root=Tools_Project&r1=1.32&r2=1.33

[*] ShowFullPathsAction.java 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/actions/ShowFullPathsAction.java?root=Tools_Project&r1=1.12&r2=1.13

[*] IDsfDebugUIConstants.java 1.5.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/ui/IDsfDebugUIConstants.java?root=Tools_Project&r1=1.5&r2=1.5.2.1

[*] ICDebugInternalConstants.java 1.5.20.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.core/src/org/eclipse/cdt/debug/internal/core/ICDebugInternalConstants.java?root=Tools_Project&r1=1.5&r2=1.5.20.1

[*] MANIFEST.MF 1.26.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.core/META-INF/MANIFEST.MF?root=Tools_Project&r1=1.26&r2=1.26.2.1

[*] DsfLaunch.java 1.6.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf/src/org/eclipse/cdt/dsf/debug/model/DsfLaunch.java?root=Tools_Project&r1=1.6&r2=1.6.2.1

[*] ShowFullPathsAction.java 1.11.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/actions/ShowFullPathsAction.java?root=Tools_Project&r1=1.11&r2=1.11.2.1

[*] PreferenceMessages.properties 1.16.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/preferences/PreferenceMessages.properties?root=Tools_Project&r1=1.16&r2=1.16.2.1
[*] CDebugPreferencePage.java 1.31.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/preferences/CDebugPreferencePage.java?root=Tools_Project&r1=1.31&r2=1.31.2.1