Community
Participate
Working Groups
I was using the Plug-in Manifest editor on the MANIFEST.MF page and closed the editor when I was done. I then did an Open Resource on plugin.xml and chose the plugin.xml file for the same plugin (a regular source project in the workspace) as the MANIFEST.MF that I was looking at previously. When the editor opened, it went back to the MANIFEST.MF page instead of the plugin.xml source or any other plugin.xml-related page.
*** Bug 158948 has been marked as a duplicate of this bug. ***
Upping severity. This annoys me every time I want to fix a warning in a plugin.xml or a Manifest.mf. See also bug 128236 (plugin manifest editors not shared).
Could this be considered in the M7 polish pass?
sure, but this is one of the 'damned if you do and damned if you don't' defects. With the 3-file-in-one-editor thing, the behavior is never going to please everyone. How are you proposing we address it? What happens when you click on a manifest.mf? what happens when you click on a plugin.xml? If you close the editor while you are on a Forms page, and you open it again, right now, you go back to the same page, do you want to go to the source page?
Yes, I always want to go to the source page for the file I opened, see bug 173624. For me, the manifest editors almost always open on the wrong page, even in cases I really want to use one of the forms pages. My take is that opening on the source pages is the least confusing option. If you really want to open the editor on forms pages, then you should at least make sure that the shown forms page really corresponds to the opened file, e.g. if I doubleclick a manifest.mf, I never want to land on the Extension Points page.
Wassim, can you try this: 1) Store last visible page on the per input context 2) Open on the last page of the input context, not the last page when saving the editor.
Dejan, I am not sure what you mean by last page per input context. let' say: 1. In a plug-in that has both manifest.mf and plugin.xml, I open on a plugin.xml. It goes to the Extensions page. Fine. 2. I switch to the Extension Points page just for fun. 3. I switch to the dependencies tab and close. What do I save here?
> 1. In a plug-in that has both manifest.mf and plugin.xml, I open on a > plugin.xml. It goes to the Extensions page. Fine. > 2. I switch to the Extension Points page just for fun. > 3. I switch to the dependencies tab and close. > What do I save here? According to my previous suggestion, you should save 'Extension Points' page because Dependencies belong to a different input context (manifest.mf).
how do we keep track of that?
It would require more work. You whould need to add a field in InputContext (lastPageId). Whenever a new page is selected, you would need to get the input context that this page belongs to, and store the page in it. On close, you would need to store last page Id for each input context in the memento. On open, you would need to get the input context for the initial editor input, load its stored last Id, and use it.
sure, but after all that work, Markus will still be unhappy because he wants the source page :) I think we will have to reinstate that 'always open on source page' preference in addition to what you are suggesting.
Preference page is fine. However, in his case opening build.properties would initially open 'Build' page but after switching to build.properties source page, this choice will be stored. If he later opens plugin.xml and close it on the Extensions Page, opening build.properties will give him source right away, not 'Extensions'. Essentially my proposal pays attention to the file you clicked on to open the editor. In your scenerio above and with the 'Use source page' preference only, you would get the following: 1. In a plug-in that has both manifest.mf and plugin.xml, I open on a plugin.xml. It goes to plugin.xml source page. 2. I switch to manifest.mf source page and close. 3. I open plugin.xml again. With the preference page only, after 3. you will get manifest.mf (being the last page stored), not plugin.xml.
I understand. Note however that I said in comment 11: "I think we will have to reinstate that 'always open on source page' preference IN ADDITION to what you are suggesting." Neither approach seems sufficient on its own to please the world. As for your build.properties example, most of it is not applicable here, since double-clicking on a build.properties does not open all three files due to editor-file extension binding limitations in the platform.
I don't want to get in between the clash of two titans; however, I think we should take care on not being *too* smart and automatically doing unexpected things from the non-power user's perspective. See Bug # 180396.
(In reply to comment #11) > sure, but after all that work, Markus will still be unhappy because he wants > the source page :) I would already be happy (at least for 3.3) if comment 10 was implemented. If I understood that correctly, the approach assumes that each manifest editor page "belongs" to exactly one source file, and opening a source file shows the most recently used editor page for that source file. Scenarios: - if I only ever close an editor on a source page, it will always reopen on that source page - close an editor on a forms page that belongs to the editor's source file => reopening the file will reopen on that forms page - close an editor on a page that does *not* belong to the editor's source file => reopening the file will reopen on the most recently used page that belongs to the opened file (forms or source page) > I think we will have to reinstate that 'always open on source page' preference > in addition to what you are suggesting. If the behavior becomes predictable as outlined above, I could even live without the 'always open on source page' preference ;-).
Cool. We can't please the world, so at the very least, we can try to please Markus.
As an end user, the behavior I would expect is fairly straightforward. If I was on a forms page, I expect to be back on that same forms page when I reopen any of the 3 files. If I was on a source page, though, I expect to go to the source page of the file I'm opening right then.
If I > was on a forms page, I expect to be back on that same forms page when I reopen > any of the 3 files. If I was on a source page, though, I expect to go to the > source page of the file I'm opening right then. Actually, this is not a bad simplification that would be easier to implement: 1) When saving, if the current page is a form page, store it. Otherwise, store the special key '__input_source_page__' or something. 2) On restore, check the stored page id. If it is the special key, open the source that matches the initial editor input. Othewise, simply switch to the stored page id.
Comment 17 would also be fine with me.
Before people change their minds again, we seem to have a concensus on comment 17. Mike, could you please take a look? Once this is resolved, we can close Markus' other bug about having a preference as WONTFIX. I hate preferences.
*** Bug 173624 has been marked as a duplicate of this bug. ***
Fixed. Patch released to HEAD. Target: 3.3 M7 Patch: patch_153515_2007-04-12_16-27.txt
Thanks Mike. I verified that it works very nicely.
