Community
Participate
Working Groups
Build RC To reproduce: 1. Create plug-in project, "hello.world" (empty is fine) 2. PME opens, label is correct, "hello.world" 3. Change plug-in id, save. 4. Reopen plugin.xml. Label is now "Plug-in Manifest Editor" See attached screenshots.
Created attachment 12046 [details] Before
Created attachment 12047 [details] Mid-way
Created attachment 12048 [details] After
Build RC2, fresh unzip.
I see this behavior too. When opening a plugin.xml for an external plug-in from the Plugins view, I randomly either get the id of the plugin (good) or "Plugin Manifest Editor" (not good). When opening a feature.xml, I get "Feature Manifest Editor" as the editor tab title.
This seems like a Platform/UI issue. Adding Stefan for comment. When opening a plugin manifest editor, ManifestEditor.getTitle() gets called several times. The first couple of times, PDE has not initialized a model yet, so we return the generic string "Plugin Manifest Editor". However when getTitle() gets called the third time and onwards, we return the id of the plugin, but the original generic title does not get overwritten.
Moving to Platform/UI
Moving to Stefan to address post-3.0.
Nick, we beg to differ. This is a serious issue for PDE because you don't want to have several manifest editors opened with the same label on the tab (Manifest Editor). This used to work before, then it stopped, then it got fixed, and now it comes and goes depending on the scenario. Therefore, this is a regression and should not go into 3.0.
Is there any way that the editor could return the right thing sooner, or return null or something when it does not know the correct title? What I am saying is have you tried any workarounds?
We are open to workarounds but we need to be told about them :-). If returning null will do the trick, we can easily do it when our model is still null.
*** Bug 67802 has been marked as a duplicate of this bug. ***
The manifest editor is not firing a PROP_TITLE property change event when the result of getTitle() changes (see the JavaDoc for IWorkbenchPart.getTitle()). This is a tricky thing to get right, which is why the setTitle(...) (and more recently, setPartName(...)) methods were provided. The exact timing of the first call to getTitle() is not part of the contract between IWorkbenchPart and the workbench. The easiest way to fix this is to call setPartName(...) (or setTitle(...) if using the old APIs) when the label needs to change rather than overloading getTitle(...). If this is impossible, then the implementation of getTitle(...) should be updated to conform to the spec.
Moving to PDE. These changes need to be done in PDEFormEditor.
Note: PDEFormEditor has a handy updateTitle() method that fires off the missing property change. If you want to fix this the quick-and-dirty way, you can insert a call to updateTitle() after the model is first initialized.
This definitely cannot ship like this - making it an RC4 candidate.
The fix is fairly straightforward. If we call 'updateTitle()' inside 'createPages()', we will ensure that the title has been recomputed after the model is created, ensuring that the value is computed when the model is not null: protected void createPages() { clipboard = new Clipboard(getContainer().getDisplay()); MenuManager manager = new MenuManager(); IMenuListener listener = new IMenuListener() { public void menuAboutToShow(IMenuManager manager) { contextMenuAboutToShow(manager); } }; manager.setRemoveAllWhenShown(true); manager.addMenuListener(listener); contextMenu = manager.createContextMenu(getContainer()); getContainer().setMenu(contextMenu); createInputContexts(inputContextManager); super.createPages(); inputContextManager.addInputContextListener(this); String pageToShow = computeInitialPageId(); if (pageToShow != null) setActivePage(pageToShow); updateTitle(); <-- The fix } Attached is a patch for this tix.
Created attachment 12618 [details] Manifest editor title patch
Patch works great. +1
Verified! +1
Konrad, we are soliciting another vote for this defect to be addressed in RC4.
I agree, that this problem should be fixed. Patch looks very safe. +1
Patch applied. Marking as fixed.
