Community
Participate
Working Groups
After a long debugging session, I finally found what is causing the new macro recorder to get really confused. The new macro recorder/player tries to avoid the fragility of low-level events by tracking higher (semantic) events like selections. It works great with static menu items. However, dynamic menu items suffer from the following problem: Most dynamic submenus follow the same pattern ie. they contribute a custom contribution item that creates actions on the fly, then calls each action contribution item to fill in the provided menu. When initially created, menu items correctly get the ActionContributionItem set as data (MenuItem.setData). However, the following code in MenuManager (line 605): int start = menu.getItemCount(); src.fill(menu, destIx); int newItems = menu.getItemCount() - start; for (int i = 0; i < newItems; i++) { MenuItem item = menu.getItem(destIx++); item.setData(src); } I debugged the code above and it seems that it replaces data for each dynamically build action menu item with the data for the parent contribution item. For example, all the menu items for the 'Open Perspective' menu have the same data (ChangeToPerspectiveMenu). This makes it impossible to get to the unique perspective Id and reliably reach the same menu item during playback. The same story repeats for other dynamic menus (Show View, New... etc.). Is this behaviour intended or just a bug? It seems counter-intuitive to me that several actions have the same data associated with it.
Raising severity for three reasons: 1) It is impossible for the macro recorder to uniquely identify dynamic menu items 2) The pattern is repeated in several places in the menu bar 3) The same problem will affect instrumentation plug-in because it uses similar event listening technique (which has been shamelessly stolen for the macro recorder :-)
This was probably initially done as part of the design. The problem is that the menu items in a dynamic menu may not be contribution items at all. For example, up until I added support for perspective key bindings, the perspective menu did not have contribution items for each of its entries. The way the dynamic menu support works is that you are given a menu from which you can do anything. It is not uncommon for raw menu items to be pushed into the menu -- avoiding contribution items altogether. Likely the person who designed dynamic menus initially wanted at avoid menu items with no data (but I'm just guessing). I believe it should be possible to check for the existence of data before trying to overwrite. However, then you end up with inconsistency: some menu items could have the parent contribution item, and some menu items could have their own contribution item. It might be better to keep the parent as the data, and add try to make dynamic menus responsible for providing more information about their dynamic entries. Or possibly try to enforce a contribution item for each entry.... Tracking the activation of dynamic menu items is not a major part of the Eclipse design. Moving it back to "normal". :)
If platform UI would set the unique ID using another key, as in : menuItem.setData(IUIConstants.AUTOMATION_ID, id); it would be all I need. This would need to be done in several places but is harmless since it does not affect the current logic. Going forward, it would be a practice I would like to see used throughout the UI because it would help macro recorder/player, instrumentation plug-in and other automation agents uniquely identify the widget without questionable casts. Can you do this in a reasonable time frame?
Which unique identifier do you mean? Right now, I'm ripping apart all of the contributions work. It's essentially amounts to a re-write to (1) make contributions command-centric; and (2) accomodate some requirements that original design can't handle well (e.g., dynamic menus). I'm loathe to allow many patches into the old code base while in the process of the rework.
Doug, the common problem with instrumentation plug-in and macro recorder/playback is to be able to reliably identify widgets in the UI so that accurate usage can be reported (instrumentation) and the same widget can be located during playback (in case of the macros). When the widget has data object of a known API (i.e. IContributionItem), it is possible to cast it and ask the item to supply the unique Id. This, however, requires some knowledge of the platform UI working that makes it somewhat brittle. A safer approach would be to ask the widget to provide the unique identifier so that it can be located by ID in the subsequent session. What I proposed was that this unique ID is set on the widget during the creation using a well known constant (widget.setData(<constant>, id)). This constant should be used throughout the platform UI for every widget it creates so that automation software can ask the widget for the id and not worry about casting the data object into something that can supply this ID. In terms of the value, the ID is readily available: for commands, it is command Id, for perspective dynamic menu, it is perspective Id etc. No need for a new ID scheme - the key is to use an already available identifier and set it in a known data field on the widget reserved for automation use. As you are ripping apart the contribution code, please include this requirement to your list. Shorter term, we are OK with static items - it is the dynamic items that cause us problems, so if we could get this automation ID scheme used only there, it would be great. Adding Nick because we already discussed this idea in the past.
I understand the request, my question was: what should the id be? From the sounds of things, you don't particularly care. Ideally though, you want to be able to somehow look it up again later. Would a command id be sufficient? If a command id suits you, then it would be fairly trivial to do. With the understanding that anything using the backward compatibility layer might not provide such an id. In those case, would you prefer no id, or some other id?
It depends on the contribution item, but in most cases it is possible to find something that will uniquely identify the widget. For action contribution items, action Id is unique enough. Typically these IDs are obtained from IPluginContribution.getLocalId(). I don't particularly care what it is, as long as I can repeatedly locate the same widget in subsequent invocations using this ID. For this reason, it has to be something that does not change from session to session (and IDs originating from the extensions satisfy this requirement).
Note that similar requirement will come for objects in views (so that a unique identifier can be fetched for selections in threes and tables). Right now I know about some known object types like resources and Java elements, but in general we should ask for all these objects to be adaptables and provide an interface that will allow us to ask for a unique ID of any object (we cannot do this for widgets, hence the need to provide this ID as 'getData (<automationKey>).
Moving Dougs bugs
Assigning to component owner 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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
