Community
Participate
Working Groups
R3.2M5 Case 1 (problem case) If a view is opened before the plugin that contributed view actions is started, the actions will not be created/initialized before the popup menu is displayed. Case 2 (working case) If the contributing plugin is loaded before the view is opened, the contributing actions are created and therefore initilized when the view first becomes visible. To the end user there should be no difference between the 2 cases. In my application the actions are enabled when they shouldn't be. If the user selects one of these actions they usually will get a message that the action is disabled and the action in the popup menu becomes disabled. I understand that this is part of the lazy load strategy. A possible solution would be: 1) When the view initializes the context menu it should remember which contributing plugins were not loaded. 2) each time the context menu is about to display the view should check to see if any of the "missed" plugins have been loaded and construct/initilize their actions. It would not be necessary for the view to listen to plugin load events.
Which build?
(In reply to comment #1) > Which build? > I20060217-1115
Could you try I20060321-0800 or later? I believe I've already fixed this bug for 3.2 M6.
Tested on Version: 3.2.0 Build id: I20060330-0010 The problem is still there.
The user says the problem still exists. Re-opening....
Moving Dougs bugs
Alan, just to recap your usecase: 1. You open your view and the contributing plugin is not loaded. The menu contains an action, but the action is not initialized (expected behaviour). 2. some action causes the contributing plugin to be loaded 3. The next time you pop up the menu, your view action delegate is still not initialized, although now the plugin has loaded (unexpected behaviour). Later, PW
The problem only occurs if the view is open before my plugin is loaded. Views that were visible when the workbench was shutdown are restored the next time it starts up. They are initialized early, before my plugin is loaded. If the view is not visible when the workbench starts my plugin is loaded before the user is able to click on the view and then bring up the menu.
Hi, Is it possible to address this bug for 3.2.1? Thanks... Samantha
No decisions have been made w.r.t 3.2.1 bugs. PW
(In reply to comment #0) > R3.2M5 > > Case 1 (problem case) > If a view is opened before the plugin that contributed view actions is started, > the actions will not be created/initialized before the popup menu is displayed. > > Case 2 (working case) > If the contributing plugin is loaded before the view is opened, the > contributing actions are created and therefore initilized when the view first > becomes visible. > > To the end user there should be no difference between the 2 cases. I just re-read this and I'm not sure I'm following. If a view is up and a non-started plugin contributes to its popup menu, eclipse will display the actions as enabled until the user clicks on it. Then it will c reate the delegate and either execute it, or pop up a "operation not available" message. This is by design. Are you saying you don't want this behaviour, or that a usecase that is supposed to work isn't? Like after you click on your action it is not being created? PW
(In reply to comment #11) > If a view is up and a non-started plugin contributes to its popup menu, eclipse > will display the actions as enabled until the user clicks on it. Then it will > c reate the delegate and either execute it, or pop up a "operation not > available" message. This is by design. > > Are you saying you don't want this behaviour, or that a usecase that is > supposed to work isn't? Like after you click on your action it is not being > created? > > PW I'm saying that there should be no difference to the end user. The enablement of actions should be consistent. The current design means that a user could click on several actions only to find that for each of them the "Operation is not allowed" with no explanation why they aren't allowed. After clicking on them they become disabled begging the question why they weren't disabled in the first place. Some of our users made the comment that if they weren't allowed in the first place why weren't they shown as disabled. In addition, if a plugin contributes many actions the user is allowed to click on each one of them before finding out what is allowed. Perhaps a partial solution that would be to load the plugin that contributed the action when the user selects the first one that returns "Operation not allowed". That way the rest of its contributed actions would be correctly enabled. Ultimately this is a usablility problem. Some of our customers couldn't understand why these actions were shown as enabled. They thought they were doing something wrong because the message "Operation not allowed" didn't tell them very much. Hope that helps
This is feature work as opposed to a bug, deferred to 3.4 PW
I think the summary should be updated to reflect what was mentioned in comment 12.
(In reply to comment #12) > In addition, if a plugin contributes many actions the user is allowed to click > on each one of them before finding out what is allowed. > > Perhaps a partial solution that would be to load the plugin that contributed > the action when the user selects the first one that returns "Operation not > allowed". That way the rest of its contributed actions would be correctly > enabled. This is the case today ... clicking on one action (and getting the "Operation not available") will load the plugin, and all contributed actions are available. > Ultimately this is a usablility problem. Some of our customers couldn't > understand why these actions were shown as enabled. They thought they were > doing something wrong because the message "Operation not allowed" didn't tell > them very much. For providing your own product/RCP app, there is a workaround available. Start all of the plugins that you are deploying, and take the startup time hit. Eclipse SDK doesn't pay the startup price, and is willing to train the users to expect that behaviour for unloaded plugins. PW
(In reply to comment #14) > I think the summary should be updated to reflect what was mentioned in comment > 12. > Do you have a suggestion for the summary... There is a lot mentioned in comment #12
(In reply to comment #15) > (In reply to comment #12) > > In addition, if a plugin contributes many actions the user is allowed to click > > on each one of them before finding out what is allowed. > > > > Perhaps a partial solution that would be to load the plugin that contributed > > the action when the user selects the first one that returns "Operation not > > allowed". That way the rest of its contributed actions would be correctly > > enabled. > > This is the case today ... clicking on one action (and getting the "Operation > not available") will load the plugin, and all contributed actions are > available. > While the plugin does get loaded I only saw the state of the selected action updated. Other actions (even from the same plugin) were not getting a chance to update their state. Has this changed in a newer version of Eclipse? That also doesn't address the case where multiple plugins contribute the actions. > > Ultimately this is a usablility problem. Some of our customers couldn't > > understand why these actions were shown as enabled. They thought they were > > doing something wrong because the message "Operation not allowed" didn't tell > > them very much. > > For providing your own product/RCP app, there is a workaround available. Start > all of the plugins that you are deploying, and take the startup time hit. > I don't want to go against the "lazy load" plugin architecture. I want the fast startup of my RCP app. > Eclipse SDK doesn't pay the startup price, and is willing to train the users to > expect that behaviour for unloaded plugins. > > PW > Unfortunately, customers that pay for products built on the Eclipse platform don't want to be trained by what they (and I) consider poor usability.
(In reply to comment #17) > While the plugin does get loaded I only saw the state of the selected action > updated. Other actions (even from the same plugin) were not getting a chance > to update their state. Has this changed in a newer version of Eclipse? This behaviour has been there for a while (at least for standard object contributions). If you are seeing this problem, please open another bug (it might be a regression). > > For providing your own product/RCP app, there is a workaround available. Start > > all of the plugins that you are deploying, and take the startup time hit. > > > > I don't want to go against the "lazy load" plugin architecture. I want the > fast startup of my RCP app. This was the optimization trade off ... start up speed for accuracy. You can get 100% accuracy by starting up all the plugins. The more lazy, the less accurate the presentation to the user. > > Unfortunately, customers that pay for products built on the Eclipse platform > don't want to be trained by what they (and I) consider poor usability. You are correct it is not ideal. Menu items should not move around, nor should the appear/disappear unless it is extremely predictable. Enabled/disabled is the best case (because no one has to guess where the menu items went). But the startup time problem was deemed severe enough that this behaviour was warranted (and since this optimization is in the action framework, it has been this way for a long time). The behaviour is unlikely to change in the 3.x stream. It is possible that a different approach might be available in the 4.0 stream, I'll post a bug back here when we're considering options. PW
Updated as per http://wiki.eclipse.org/Platform_UI/Bug_Triage PW
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
