Community
Participate
Working Groups
Build Identifier: I20091204-0800 The CDT contributes a Refresh button in the upper right corner of the Debug View. This button is always initially enabled. However when the button is pressed an information dialog appears with the text "The chosen operation is not enabled". This is confusing, and the button should be initially disabled instead. Reproducible: Always
i agree that this is annoying, though it is the standard action delegate behavior intended to avoid premature loading of plugins. Another example of this is the "Signals..." action. However, if users feel that having this toolbar action is too much for the view toolbar, we could just remove it and rely on the standard File->Refresh (F5) action.
Just to give more details on what Pawel meant (because I remember that it was not obvious to me, when I first looked as this behavior). In Eclipse, buttons are contributed through XML definitions. This allows Eclipse to know of the existence of these buttons, without actually loading the plugin. The problem is that in some cases, like for our 'refresh', the only way to know if the button should be disabled is to load the plugin. So, to be efficient, what eclipse does is to keep the button enabled so that someone can use it, but only then will it load the plugin to figure out if the button should be enabled or not. The alternative would be to keep the button disabled, but then there would be no way to trigger the loading of the plugin. Some buttons can figure out through XML that they should be disabled, but this is not always the case (like here).
(In reply to comment #2) > Just to give more details on what Pawel meant (because I remember that it was > not obvious to me, when I first looked as this behavior). > > In Eclipse, buttons are contributed through XML definitions. This allows > Eclipse to know of the existence of these buttons, without actually loading the > plugin. The problem is that in some cases, like for our 'refresh', the only > way to know if the button should be disabled is to load the plugin. So, to be > efficient, what eclipse does is to keep the button enabled so that someone can > use it, but only then will it load the plugin to figure out if the button > should be enabled or not. The alternative would be to keep the button > disabled, but then there would be no way to trigger the loading of the plugin. > > Some buttons can figure out through XML that they should be disabled, but this > is not always the case (like here). In the case of Refresh, the action is not a launch point for the plugin. That is, if a debugger-related plugin isn't loaded, e.g., it makes no sense for the refresh button to be enabled. Doesn't the enablement element allow the plugin state to be considered? I believe it does.
(In reply to comment #3) > In the case of Refresh, the action is not a launch point for the plugin. That > is, if a debugger-related plugin isn't loaded, e.g., it makes no sense for the > refresh button to be enabled. Doesn't the enablement element allow the plugin > state to be considered? I believe it does. You are right. I guess I only got part of the story. Could it be that for an other plugin to retarget such an action, having it disabled in XML would prevent to retarget it? But I'm still learning here...
