[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Activities and Contexts - Important Update
|
>Then, we still have the issue of automatically changing the set enabled
activies as the user debugs. Thus, when the user starts a debug >session,
the appropriate views should come into being. When the sessions is
terminated (and removed), the views can then be hidden. I >believe hiding
the view when the debug session is removed is safe. This way, view content
can still be viewed after termination. Once the >user explicitly removes
the debug session, it should be safe to remove the output from that
session (this is how console output is currently >handled). Perhaps we can
use contexts to dynamically enable activities, based on what exists in the
debug view.
I think you are running a risk of mixed metaphor here. First of all views
are frequently adjusted by the user - position, size etc. is something
that they get the way they like. Closing the view and reopening can be
very frustrating as it is possible to lose context and configuration this
way. I think the idea of bringing a more relevant view to the top will
give the user context but not ruin any of thier layout.
Using contexts to enable activities will potentially cause some knock on
loss of context because if the inconsistency of trigger points. Contexts
come and go all of the time but when you work on an activity you do so for
the long term. For instance I use the console view to read over printlns I
may have inserted while debugging. When debugging is done and I am making
fixes based on these printlns I still want that output. I am still doing
the debugging activitiy even if I am not running an application currently.
Tod
Darin Wright/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
12/04/2003 09:47 AM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc: Wayne Ho/Toronto/IBM@IBMCA
Subject: Re: [platform-ui-dev] Activities and Contexts - Important Update
Originally, we were hoping that activities would solve the entire debug
problem - i.e. displaying the correct set of views/actions based on what
was being debugged. However, the problem we discovered is that the debug
platform provides a superset of actions and views that many debuggers
share different subsets of. Thus using activities to filter does not work
well (since the views actions all come from the same plug-in). As well, a
more dynamic solution is desired - i.e. we'd like views/actions to appear
and disappear as they are required rather than having a superset of
views/actions visible all the time.
For example, the debug platform provides the following views:
breakpoints, variables, expressions, registers, and storage (note - in
reality, the registers and storage views do not yet exist in the platform,
but may be contributed during the 3.0 time frame). When debugging "Java",
the registers and storage views are not applicable. When debugging a
functional language, the expressions view is not applicable. I suppose one
approach would be to define unique prefixes for each view and associated
actions such that we may be able to define activities properly to identify
the subset of views/actions used by each debugger.
Then, we still have the issue of automatically changing the set enabled
activies as the user debugs. Thus, when the user starts a debug session,
the appropriate views should come into being. When the sessions is
terminated (and removed), the views can then be hidden. I believe hiding
the view when the debug session is removed is safe. This way, view content
can still be viewed after termination. Once the user explicitly removes
the debug session, it should be safe to remove the output from that
session (this is how console output is currently handled). Perhaps we can
use contexts to dynamically enable activities, based on what exists in the
debug view.
Darin
Chris McLaren/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
12/03/2003 09:54 PM
Please respond to platform-ui-dev
To: Darin Wright/Ottawa/IBM@IBMCA, jaredburns@xxxxxxx,
Wayne Ho/Toronto/IBM@IBMCA
cc: platform-ui-dev@xxxxxxxxxxx
Subject: Re: [platform-ui-dev] Activities and Contexts -
Important Update
Wayne, thanks for this description. You and I are in sync with regards to
how 'contexts' will faciliate this work. It might be worth it for me to
describe where 'activities' and 'contexts' are as of today:
- Activities -
Activities have been taking priority, and the API is largely complete.
What remains in activities is work to ensure that various UIs within the
workbench adhere to the filtering that activities define, and that some
UIs expose smart workflow mechanisms that allow the user to 'grow into'
new activities in a more natural way that simply having them choose their
activities explicitly in some UI. (i.e. Being able to create a new Java
project in the new project wizard to enable the 'Java Development'
activity as opposed to requiring the user to go to an activities dialog
and select a check box which says 'Java Development')
Activities do effect debug, significantly: they can filter out debug
views, debug commands, and even the debug perspective as a whole, but it
is on a macroscale - debug is affected by 'activities' like any other set
of plugins in the sense that 'java development' (or a similar
coarse-grained activity) could be completely filtered out of the
application by the user, hence you the user would never get as far as java
debugging to be concerned with the use cases you describe below.
Assuming, however, that the user has enabled the required activities such
that debug is not filtered out of existence entirely, then contexts can
come into play.
- Contexts -
The contexts API is largely complete as well:
1. There are facilities to define contexts and their interdependancies
(via the org.eclipse.ui.contexts) extension point.
2. One can activate or deactivate contexts via API at various levels in
the workbench (workbench, window, page, part).
3. One can receive notification when the set of active contexts change, or
changes to particular contexts, via IContextManager.
What is missing? Primarily, I chose not to provide a mechanism in the
contexts API to bind contexts to specific functionality. Activities, in
contrast, has this mechanism built right into its API via its 'pattern
bindings'. The reason this could be readily included in activities is that
the semantics of binding an activity to some functionality is clearly
defined - the binding always means 'functionality X is available when
activity Y is enabled'. For contexts, however, I didn't think it was clear
yet what the semantics of bindings would be for various systems.
For commands, the semantics are fairly clear: menus and toolbars should
hide (or disable?) irrelevant commands. I am in the process of adding the
ability to bind contexts to commands in the org.eclipse.ui.commands
extension point, but it remains to be experimented with if the binding
should specify whether the command should be hidden altogether or just
disabled when the user is out of context for that command. (Commands are
already filtered on activity. Filtering on context would be next in the
chain of filtering for those commands that made it though the activity
filter)
For views, the semantics aren't as clear:
a) The big question: the Show View dialog currently filters out views
based on activity, but should the Show View dialog also further filter
context bound views? i.e. Should the user be restricted to only be allowed
to open views that are currently in context?
b) One might define that a particular view is to be opened and brought to
the top when a particular context becomes active, but another view is only
to open itself on the bottom of a stack such that the user notices only
the tab appearing.
c) There might be some user defined behavior here as well - preferences to
open certain views based on certain contexts.
d) Also there might be some user-defined behavior on how those views might
hide themselves once one leaves a context. How do we distinguish those
views that might contain residual information (logs, etc.) that you might
not simply want to disappear just because the debug target terminated, vs.
those that can disappear automatically (variables view, maybe?).
I'd like to work with debug to have them show/hide views programatically
for now in response to events from the context manager before considering
declarative API in the area of view-context bindings.
IWorkbenchPage.showView(..) has been made public for this purpose, with
the option to activate the view or not, (but it currently lacks further
options on how to show - brought to front/pushed to back - currently views
are always brought to front). IWorkbenchPage.hideView(..) also exists.
Chris.
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
