| Re: [platform-ui-dev] RFC - Loss of Context Proposal (end date = 11/27) |
A general statement to start with:
Dave's proposal is rather long. Although, all listed issues somehow belong
together, I'd prefer when presented proposals would have a sharper focus.
Long proposals have the inherent disadvantage of a discussion scattered
over a big set of issues. This automatically reduces the weight of
individual arguments. In addition, for persons not that familiar with the
overall topic it is hard to pin down the most relevant statements.
Loss of context is certainly an important issue. My line of discussion
comes from my experience using the SDK as is, and from some very limited
experience with WSAD.
When do I feel that I loose context? This is mostly the case when
perspectives and parts are opened programmatically. The first case is a
real loss of context. The MRU approach is an considerable relief in this
respect. I strongly support this feature. At the first glimps, the second
case does not look that important. However, this is only true, if the
current perspective already defines a place holder for the newly opened
part. If not, the part is "always" opened at the wrong place and thus ruins
my layout. I preceive this as rather servere because the new part steals
display real estate from the parts that are already there. This causes such
parts to shrink which in turn scrolls what I am interested in out of the
visible area. For me this means that there is a set of actions which are
disruptive to my workflow. I don't refer to the conceptual workflow, I am
talking about that I have to interact with the UI although it is absolutely
not what I wanted to do at this very moment.
"Perspectives are task centric." I believe this is an overall optimistic
statement... For me, perspectives are just setting the context in which I -
the user - decide about the tasks I want to purse. I strongly believe that
from an IDE perspective the user should be in control of the context. This
might not generallt be true for Eclipse as open platform - but because
Eclipse is an open platform there are always use cases in which the
provided mechanisms cause harm to the user.
Why are there so many perspectives and editors, e.g., in WSAD? Surely there
are several reasons. The one I personally believe is underestimated is that
of limited display real esate. When developing eclipse plugins and being
faced with limitations of the presentation space you simply invent a new
perspective. In your own perspective you have the complete control - at
least initially. You don't have to pay the costs - they are put on the user
in form of a disrupted workflow.
In addition, I think that the programmatic creation and switching of
perspectives contradicts the freedom we give the user to design, create,
open, and close custom made perspectives. Either the user is in control or
not. Having supported both but neither sufficiently is not a good solution.
I am in favor of user control. Thus, the user should acknowledge or veto
the program initiated switch of perspectives. In addition, I would
encourage to investigate whether it would make sense that newly created
parts would be created as free floating parts that the user can place
immediately whereever the user believes it belongs. To some degree this
would resemble what Smalltalk environments did when creating a new browser.
The difference would be that those parts are already complete, i.e. the
user can see its contents allowing for a better judgment where the part
belongs to.
I use eclipse regularly on my laptop. I got burned over and over again
with these two problems: limited display real estate and disrupted
workflows. Both issues should be solved when providing a viable solution.
For two months I have been experimenting by taking the route of giving the
user more control. I changed the strategy WorkbenchPage implements for
opening new parts - both view parts and editor parts. The basic idea is
that of reusing a part of the same type depending on the input of the page
the part belongs to and independent from the window or or other aspects of
the page to which the part belongs. There must be exceptions to this which
I will explain.
I'm using the following setup for developing Java:
perspective EDITING: editors + content outliner
perspective NAVIGATION: navigator, package view, type hierarchy view -
no editors
perspective OUTPUT: console, task list, search result view - no
editors
perspective TEAM: synchronization view, repositiory view - no editors
perspective DEBUG: the standard debug perspective
Each of these perspectives has its own window. Thus, when double clicking
on a task in the task view, an editor opens in the EDITING window and the
window is activated. The previously mentioned exception is important for
debugging. There when clicking on a stack frame, I don't want to switch
windows. Thus, the strategy I implemented has a list of perspective IDs
which it excludes from the reuse. The exclusion happens when looking for
reusable parts as well as when the excluded perspective requests a new part
to be opened.
The advantage of this approach is that as long as all required parts are
already created, the behavior of the environment is completely predictable.
I.e. no part is resized or misplaced, no context is lost. When a part must
be created , this approach suffers from the same shortcomings described
above. Together with user control over newly opened perspectives and parts
as proposed above this approach would be close to what I would like to
develop with.
Attached please find the code based on build 20011122. The behavior as well
as the exclusion list are hard coded, however it would be easy to implement
a perference page - or some more appropriate UI. The code changes are
minimal as you can see.
Kai
(See attached file: Opening Strategy.zip)
"David
Springgay/OTT/OTI" To:
platform-ui-dev@xxxxxxxxxxx
<David_Springgay@xxxxxx cc:
m> Subject:
[platform-ui-dev] RFC - Loss of Context Proposal (end date =
Sent by: 11/27)
platform-ui-dev-admin@e
clipse.org
11/20/2001 09:59 PM
Please respond to
platform-ui-dev
Please provide comments on the following proposal by 11/27. This is not a
call for committers to vote.
(See attached file: Proposal.html)
(See attached file: Opening Strategy.zip)Attachment:
Opening Strategy.zip
Description: Zip archive