Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 357940 - Inconvenient representation of children of org.eclipse.ui.activities, org.eclipse.ui.handlers nodes when editing a plugin.xml
Summary: Inconvenient representation of children of org.eclipse.ui.activities, org.ecl...
Status: VERIFIED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: PC All
: P3 enhancement with 8 votes (vote)
Target Milestone: 3.8 M3   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2011-09-16 09:45 EDT by Dennis Fridlyand CLA
Modified: 2011-10-25 14:40 EDT (History)
3 users (show)

See Also:


Attachments
org.eclipse.ui.handlers (38.32 KB, image/png)
2011-09-16 09:55 EDT, Dennis Fridlyand CLA
no flags Details
patch 1 (947 bytes, patch)
2011-09-27 05:46 EDT, Dennis Fridlyand CLA
curtis.windatt.public: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Fridlyand CLA 2011-09-16 09:45:28 EDT
Build Identifier: I20110613-1736

When using an editor for plugin.xml, it's too inconvenient to work with children of org.eclipse.ui.activities and org.eclipse.ui.handlers nodes on the Extensions tab of the editor. The problem is that handlers doesn't contain name attribute, and their representation in an extensions tree is just '(handler)'. If you need to find a particular handler in this tree, you have to look through the list of all handlers to see their Extension details.

I propose to add a 'name' attribute to each handler and activity, and then use the values of this attribute when creating labels for Activities and Handlers in the Extensions tree

Reproducible: Always

Steps to Reproduce:
1. Create a simple plugin
2. Open plugin.xml in the editor
3. Go to Extensions tab of the editor
4. Add org.eclipse.ui.handlers extension point, and then add some handlers to this extension point
5. See the textual representation of each handler in the tree

Use the equivalent steps to reproduce the issue with org.eclipse.ui.activities
Comment 1 Dennis Fridlyand CLA 2011-09-16 09:55:44 EDT
Created attachment 203487 [details]
org.eclipse.ui.handlers

Illustration of the issue
Comment 2 Curtis Windatt CLA 2011-09-16 10:01:41 EDT
To add a new optional attribute to the extension would require changes from the extension point owner (eclipse ui), not PDE.  One other option is to take an existing attribute and have PDE use that as for the label if it can't find a name/id.  I'm not sure exactly where in PDE that logic exists, but I can track it down if you are interested in pursuing that solution.
Comment 3 Dennis Fridlyand CLA 2011-09-16 10:08:01 EDT
Please, track it down because all our team is interested to get a solution for this issue.
Comment 4 Dennis Fridlyand CLA 2011-09-26 07:19:05 EDT
Is there any solution for the described issue?
Comment 5 Curtis Windatt CLA 2011-09-26 11:46:03 EDT
The label is figured out in ExtensionsSection#resolveObjectName() in the org.eclipse.pde.ui plug-in.

The PDE team doesn't have time to work on this, but we will review any community contributions.
Comment 6 Dennis Fridlyand CLA 2011-09-27 05:46:39 EDT
Created attachment 204062 [details]
patch 1

I propose to add "commonId" element to ExtensionsSection#COMMON_LABEL_PROPERTIES array, because it's a required attribute for a handler. This solution is suitable for our development team.

The patch is provided (based on version 1.79 of ExtensionsSection.java)
Comment 7 Curtis Windatt CLA 2011-09-27 12:11:43 EDT
Thanks for the patch.  While looking more closely at the code, there is no drawback to adding a few more entries to the array of common attributes for labelling.  Therefore I added in activityId as well for the handlers extension.

Fixed in master branch.
Comment 8 Curtis Windatt CLA 2011-10-25 14:40:52 EDT
This change got put in while I was working on fixing the PDE menu contributions.  When I ended up trying to work with them in a build without this trivial change I found it way more frustrating.

In the future we should look at what other common label properties we can add for extensions.

Verified in I20111021-1625