Re: [platform-ui-dev] IContext JavaDoc

[Randy Hudson <hudsonr@xxxxxxxxxx>]

1. We have expressed this requirement
for the GEF palette.  If the palette becomes a View, it needs to go
away when not use, and appear when needed.  You could make the same
argument for the propertysheet, which doesn't get a lot of use by the platform
itself, but is heavily used in Websphere and other eclipse-based products.

I've already added my comments to the
bugzilla.

Thanks,
Randy

Chris McLaren <Chris_McLaren@xxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 09/11/2003 02:06 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ui-dev] IContext JavaDoc

1. well, we haven't actually done views yet in this
manner. i have this 
dream.. a pipe dream, some may say.. 
that views (some? all?) could magically appear when needed (which already
happens in eclipse) and go away when not needed. this could be at the 
user's option on a view by view basis (?).
there could be a pinning mechanism / or some kind of smart algorithm for
closing views that doesn't upset the user and/or cause to much flicker.
also - there is the question of how these views could happily appear and
disappear without putting your current layout out of whack. there's a 
bunch of thinking required here yet.
i think the association between views and contexts (for now) could be as
simple as automatically generating the view shortcut menu and/or 
automatically filtering the show view dialog based on role.

2. if you consider my example above where the show view dialog limits 
views to those which would activate contexts recommended within the user's
role, the user would probably have the option to open any view, but those
"unrecommended views" would come with the appropriate UI warning,
etc. 
part of the experiment this week that the dynamic team is working on is
to 
see where these trigger points might be. its will be a balancing act to
make sure that the user is sheltered from irrelevant functionality most
of 
the time, while not limiting the user from moving into new roles when they
really, really want to. the set of recommended functionality should always
be cohesive. for your specific question, the presence of a view (either
active or just on screen) may activate a context - this will have the 
trickle down effect of enabling commands - which, in turn, will enable
the 
keybindings.

3. somewhere in the canadian idol thread i said something about this, as
a 
possible option in the opposite direction of chris laffra's suggestion
that contexts be flat. this is still up for a decision..

a lot of these details are not solidfied yet by any means. (some haven't
even liquified yet.)
chris.






Jared Burns <jaredburns@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
09/11/2003 01:36 PM
Please respond to platform-ui-dev

 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-ui-dev]
IContext JavaDoc



Thanks, Chris. I read the proposal (and the "Canadian Idol" thread)
and I 
have 
a few questions.

1. When you activate a context, does the platform automatically open all
the 
view's associated with that context? Or does the context provider have
control over which views appear?

2. Does manually activating a single view from a context mean that that
context is now considered active? If not, does that break the idea of 
linking 
keybindings to contexts (you'd have a view without its keybindings)? If
so, 
would the other views in that context be automatically opened when you
open 
one view?

3. Can contexts have multiple parents? It's easy to imagine contexts that
would want this. For example, the "java debugging" context might
want to 
extend both the generic "debugging" context and the "java
text editing" 
context. If you don't like that example, take the "java hot-swap 
debugging" 
context which extends both "java debugging" and "java text
editing" or the 

FooBarBaz context which wants to extend Foo and Bar.

- Jared


On Wednesday 10 September 2003 04:13 pm, Chris McLaren wrote:
> context api docs will appear *shortlyish*. there is a contexts
> proposal/white paper on the platform ui team page which should help
> somewhat.
>
> the context work is tracked under "[workbench] [plan item] scalability"
> bug # 37929.
>
> as far as moving the code goes, i expect it will be moving very shortly
in
> fact, out of the workbench plugin to its own plugin - either at the
ui
> level (org.eclipse.ui.contexts) or the jface level
> (org.eclipse.jface.contexts).
>
> chris.
>
>
>
>
>
>
> Jared Burns <jaredburns@xxxxxxx>
> Sent by: platform-ui-dev-admin@xxxxxxxxxxx
> 09/10/2003 06:48 PM
> Please respond to platform-ui-dev
>
>
>         To:     platform-ui-dev@xxxxxxxxxxx
>         cc:
>         Subject:        [platform-ui-dev]
IContext JavaDoc
>
>
>
> We here in debugland are interested in the emerging IContext work
to
> better
> support multiple language debuggers. I've been asked to explore this,
but
> it
> looks like IContext and related interfaces/classes are mostly
> undocumented.
>
> It's no problem if the interfaces change, but it would be helpful
to 
have
> some
> basic JavaDoc in place so that we can at least see how things stand
right
> now. For our planning purposes, does anyone have an idea when comments
> might
> start to appear on this code?
>
> Also, my queries haven't had any luck finding the bug report that's
> tracking
> the context work. Does anyone have a bug number?
>
> Thanks,
> - Jared
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ui-dev

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev



_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev