Hello Pawel,
I might have found the problem, or at
least one of them.
The initialization performed in LaunchManager.initializePreferredDelegates()
will only look for the PREFERRED_DELEGATES as a preference key. If the new
extended syntax is used, PREFERRED_DELEGATES will instead be a children node
including a set of keys, each of which corresponds to a launch configuration
type id and indicates a set of delegate-modes pairs in its value.
I have patched LaunchManager so that it
uses the newer IPreferencesService to retrieve the subnode if the old method
fails to retrieve the key at root level.
Now I can see that the preferences window
is initialized according to my product configuration even on a blank workspace!
However, an application launch will always
default to the CDI debugger, no matter what the Default Launchers preference is
set to. Could this be caused by the “hack” you were mentioning? I
am not able to find that in CMainTab nor in LaunchConfigurationTabGroupViewer.
I am now looking for reliable regressions,
so that I can submit bug reports for those two issues.
Best,
Mario
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Pawel Piech
Sent: den 23 juli 2009 16:28
To: CDT
General developers list.
Subject: Re: [cdt-dev] Setting a
default launch delegate in a productin theDefault Launchers preference page
Mario Pierro wrote:
Hello Pawel,
Thanks for the quick answer, now the problem is much clearer.
I am puzzled by the preference being stored in the workspace when
selected manually, but ignored when set via default. Also, it seems that
exporting and re-importing the preferences in a blank workspace will not
restore the previous launch delegate settings.
If exporting and reimporting doesn't work, that would
mean it's a regression. Please file a bug against platform debug and I'll
take a look at it as well.
Thanks!
Pawel
The current approach seems reasonable - maybe there is no need to change
extension point definitions once the products are able to override the
CDI default using customization.
I'll work on this and post a patch if I find one.
Best,
Mario
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Pawel Piech
Sent: den 23 juli 2009 00:14
To: CDT General developers list.
Subject: Re: [cdt-dev] Setting a default launch delegate in a product in
theDefault Launchers preference page
Hi Mario,
You are correct the platform does not set the default, it is sort of
selected at random and overriding the preference is the currently the
only mechanism to set the default launcher. I was planning to use the
preference mechanism to set the default in CDT, but I discovered that
CDT doesn't have a "product" in which I could set the preference
override. As a result, late in CDT 6 when we got a lot of negative
feedback for not having the standard launcher be the default, I put in a
hack set the default in CMainTab.setDefault().
I'm not really that familiar with the default preferences handling, so
without debugging it myself I can't tell if the reason below is why it's
not working. To be honext, once I figured out that this option wasn't
going to work for CDT, I stopped testing it. If you do some experiments
and find an easy way to fix it, file a bug against Platform Debug with a
patch and I'll gladly apply it. Keep in mind though that the changes
will need to be backward compatible.
Also, if you would like to contribute a new addition to the launchers
extension point to specify a default more explicitly I would gladly look
at that for 3.6 as well.
Thanks,
Pawel
Mario Pierro wrote:
Hello,
I am trying to set a default launch delegate for our debugger, so that
users will not need to explicitly set one in preferences (Run/Debug >
Launching > Default Launchers).
In my plugin_customization.ini, I am adding an entry which refers to
my
launch delegate ID
org.eclipse.debug.core/org.eclipse.debug.core.PREFERRED_DELEGATES/org.ec
lipse.cdt.launch.applicationLaunchType=<my own launch delegate ID
here>,debug
However, this specific default setting seems to be ignored when the
preferences page is initialized in my product.
The preference key is formed as described in the class
org.eclipse.debug.internal.core.LaunchManager
so that it is org.eclipse.debug.core.PREFERRED_DELEGATES followed by a
slash and the launch configuration type id.
I have looked through bug 262826
https://bugs.eclipse.org/bugs/show_bug.cgi?id=262826
However, by debugging through
org.eclipse.core.internal.preferences.DefaultPreferences
I have noticed that in the applyDefaults() method, line 133:
private void applyDefaults(String id, Properties defaultValues,
Properties translations) { for (Enumeration e = defaultValues.keys();
e.hasMoreElements();) { String fullKey = (String) e.nextElement();
String value =
defaultValues.getProperty(fullKey);
if (value == null)
continue;
IPath childPath = new Path(fullKey);
here>>>> String key = childPath.lastSegment();
childPath = childPath.removeLastSegments(1);
.
.
.
the key gets set to the id of the launch configuration type
org.eclipse.cdt.launch.applicationLaunchType
while the childPath is
org.eclipse.debug.core/org.eclipse.debug.core.PREFERRED_DELEGATES
because of the call to lastSegment()
Might this cause the key which is set afterwards in the code to be
incorrect?
If so, how does CDT default to the CDI debugger launch? There seems to
be no preferred launch delegate selected by default.
Am I missing something?
Thanks for your help!
/Mario
_______________________________________________
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
