Re: [platform-ui-dev] Activities and Contexts - Important Update

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

> It sounds like contexts play much the same role
that perspectives 
> have played in the past.  Perspectives have always had this funny
> split role of defining part layout as well as filtering commands,
> and the contents of the "show view", "new" and
other such menus.  It
> sounds like this second role of perspectives is now being done by
> contexts.  As a user I think this is a positive step - I often
> switch perspectives in order to obtain a different part layout while
> working on the same task, thus I find it annoying that this disables
> the various commands and menus that I use frequently. I find myself
> switching to the Java perspective just to hit Ctrl+Shift+T to open
a
> type, and then switch back to the perspective I was in before. Of
> course I can manually customize all of my perspectives to have the
> same commands and menus, but this is tedious configuration work.  
> So, I welcome the idea of separating "context" or role change
from 
> layout change. 
> 
> To avoid competing configuration stories in 3.0, you may want to 
> consider deprecating the portions of perspective functionality that
> is now being done by contexts, or somehow link the two together (for
> example a perspective could define a default set of contexts for 
> that perspective, and perspective extensions could add more contexts
> as appropriate). 

I agree with you here. If perspective is layout +
the functionality that contexts offer, perhaps severing them would be appropriate.
I mentioned this overlap in my 'contexts' document of august 5, but its
remained on the horizon since then. 

One could simply maintain a small set (1-4?) of layouts
('full screen editor', 'really big editor window with space at one side
for views', 'small editor with three view regions', etc) and use contexts
(and activities as well) to have the views and commands show and hide within
the active layouts (some layout AI work might be warranted here). Perhaps
layouts themselves could change based on context changes (the general solution
to how debug offers the preference to change perspectives when a debug
session starts). Next and previous perspective could become 'next and previous
layout'.

Thanks for the anecdote re Ctrl+Shift+T, here's one
of mine: After debugging, I always find myself editing code in the debug
perspective for a while. Eventually, I realize that the editor window is
too small for prolonged editing use and remember to switch back to the
Java perspective. Working with a large screen editor, having debug views
show up while in the debugging context (making my editor smaller), and
then disappearing when the target terminates, to me, would be great.


Chris.