Re: [platform-ui-dev] RFC - Loss of Context Proposal (end date = 11/27)

["Randy Giffen/OTT/OTI" <Randy_Giffen@xxxxxxx>]

As a general comment I think we need to have a simple, strong, story as to how the workbench should be used. While configurability is fine, for a given task we really need to be able to state that "this is how you perform it" in the workbench. There will always be users who come from a variety of backgrounds and of course they would like everything to be familiar. But I think part of what they are really saying is "we want to do our work" and if the IDE is familiar then it is easy. But the trap here is that we try to become something that we are not (ex. source view in VAJ) and just end up confusing users. So while there may be cases where we want to adopt a VAJ style this or a VI style that, Eclipse is Eclipse. It needs to be intelligent, intuitive, and functional more than it needs to be "like" anything else.


- A global MRU list for the contents of the Perspective > Open menu means that the order of the list is not stable. 
        > If this is implemented as a menu I think that it is important that the ordering be stable since reorganizing menu items is confusing.
        > If this is implemented as a pop-up list then I think you could have a stable order but preselect the previous one. This would still make it easy to switch back and forth.

- Label decorators (such as version numbers) require you to run code. Thus just browsing could cause a lot of plug-ins to load. But I suppose the user will be able to select what decorators to show.

- It seems there is a conflict between the decision to "replace" perspectives by default and the functionality to "open a new perspective (window) on an object". 
The idea to replace perspectives is designed to prevent users from losing their editors. This presents the workbench ui model as a shared editor set which appears with one of a configurable set of views. 
The idea of opening an object in a page is more the vaj model. In this context the feature of having a single editor which is reused seems the most appropriate otherwise you have not really solved the "loss of editors" problem.

- "encourage the use of multi-window mode for perspective creation rather than multi-page mode."
This will significantly impact startup time, one of the advantages of multipage-mode it that you only need the plug-ins for the visible parts on startup. Perhaps a common multi-window eclipse use case is having a Resource, Java, Debug, and Team perspective open. In this situation the eclipse platform API has the disadvantages of the requirement to support lazy plug-in loading while in reality it has to activate most plug-ins on startup anyway. 

- "if a selection occurs in one view it is not uncommon to select and reveal the object in a second view.  This leads to loss of state in the second view. "
Why are we revealing the object in the second view? If it is because you can only perform certain operations on the object in the second view then I think we need to address that issue. One of the problems here is that, although one can open an editor on an object, you really have to select that object in a view in order to be able to perform "object level" operations on it. Being able to access the operations in the editor area (perhaps a pop-up on the editor tab) might simplify things.
BTW just having an option to "link this to that' is not good enough. In the navigator and editors case, I find there are times when I want it linked and times I don't.

- "It is never clear which perspective to use.  This is the most apparent when you compare the Java and Resource perspective, and the Resource and Team perspective.  These perspectives are all very similar."
I agree. I think we should discourage perspectives from including a view just because it might be useful in some rare circumstance (in which case the user can easily open it). They should be as specialized as possible. Otherwise we should just have one perspective.

- "Every user is different, and should have the ability to customize the UI to suit their working style."
But I think this should be limited to customization's within some consistent conceptual model of the ui. Not creating a new model. To use VAJ for example one could customize things like horizontal/vertical layouts, one could work in the workbench browser or multiple project browsers. But we maintained the concept of "opening a browser on an object".

- "expose the action classes in the navigator for reuse."
 In addition to reuse I think you will have to design the actions to be subclassed. There will be many cases where you want the base functionality "but just a little bit more" 

-"encourage ISV's to add a "Show in Navigator" action."
The workbench should make this available from any editor open on an IResource.

- "if one delegate in a plug-in is instantiated, instantiate the rest"
Since the issue is plug-in loading, delegates should be instantiated when the plug-in loads, regardless of the trigger.

- "issue: perhaps core should provide us with more file attributes for action enablement.  Currently the name, 
          extension, and project are not enough to determine what a file contains."
A proposal for defined file types may help here.