Community
Participate
Working Groups
I200411170800 It would be cool if the plugin manifest editor could retain the context when switching tabs. I.e. when I'm editing an Extension Element Detail on the "Extensions" tab and then switch to the plugin.xml tab, the selection should be in the xml element corresponding to the field I was editing just before (and vice versa).
*** This bug has been marked as a duplicate of 61522 ***
The way bug 61522 was solved, this is not a complete duplicate any more. In 3.3M1, GUI selections are mapped to text selections on the source pages (only at the element level, not for individual attributes, but I can live with that). But the other way 'round, this still does not work. I'm sometimes editing on a source tab and then decide that some Form UI would be more helpful to solve the task. Currently, I always have to search the element again after switching to the GUI pages, since neither the "selected" element nor the Outline selection are taken over. Could you reopen this bug or shall I file a new one?
You can reopen this one since the (vice versa) part was missed.
Reopening and adjusting summary for remaining request.
hey JLB, how much work is it to do the other direction?
This may cause some unwanted behaviour for some users (that don't want their tree selections to be reset). Maybe we should have a toggle for this functionality, possibly as a button in the form toolbar. What do you think Markus?
I'd vote against another toggle unless people really start asking for it. I don't see a clear use case where users ... - are on a form page - switch to a source page - change the selection on the source page - switch back to the form page ... and expect the selection of the form page to remain constant. If they just switch to a source page, scroll around, and then go back, the selection should not be affected. If they are e.g. on the Extensions page and then switch to the MANIFEST.MF page, the selection on the Extensions page should also not be affected (there's nothing on the Extensions page to match the source selection, hence the form's selection should not be changed).
Thanks for your input Markus.. I would however like to petition with the following as I believe it could be a common case. When a user arrives at a source page (with the intent to inspect some xml) and a lot of text is selected, it would seem like a natural reaction to deselect the selection as inverted text is difficult to read. This would pose a problem of new elements being selected... it could be avoided if the user deselects within the element (but NOT within one of its children). We could work around this feature by introducing a context menu action (on the source page) which would bring focus to the appropriate element (and even attribute field) on the extensions page. Markus and Wassim, what are your thoughts?
The "huge selection" is a bug in itself that I just didn't file so far (it's bug 154030 now;-). A "Show In" action would be better than nothing, but I still don't think it's necessary. After all, the multi-page editor is just one editor, and having one selection shared across pages is the most natural behavior, IMO. Users who want two separate editors can always choose Window > New Editor.
Janek, if we resolve bug 154030, we would address the valid issue you bring up in comment 8. I was playing around with DreamWeaver today. When you switch between the raw html and the design page, the cursor does retain the context. However, they have an easier problem since they have no trees and no multipage editors. However, I do believe that bug 154030 is the obstacle here to a reasonable solution to PDE.
Thanks for the feedback, after closing bug 154030 this behaviour is definiltey worthwhile. Selections are now retained between the xml source page <-> Extensions/ExtensionPoints pages.
