[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Back/forward actions [Bug 5700]
|
I agree that we should not limit the API to ISelection since we are not
going to track only selection. An ISelection may have enough information
but I would prefer to have a new interface or abstract class (like
abstract class better). Whether we call it ILocation of INavigationContext
does not make much difference. I like the second better because is more
abstract and has a prefix.
I agree that if we need only the method addXXXX in the IWorkbenchPage then
we do not need the interface INavigationHistory but if we ended up needing
some extra methods then I would like to have it in a separated interface
since IWorkbenchPage is getting to complex.
I am not sure if we will need the EditorID and Input as parameter of
addXXX. I think that if the implementation internally traces/manages the
activation then the ILocation will always be related to the active editor.
We will need some work on merging the activation with the selection since
the users see only one action and that could be done by checking the tag
you talked about.
Not sure with we are thinking the same think here: We would need an
interface (need a name) with the method gotoLocation(ILocation) and that
would be implemented by the IEditorParts and would be used as tag to know
if the editor (IEditorPart) supports navigation.
Eduardo.
"Kai-Uwe Maetzel" <Kai-Uwe_Maetzel@xxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
09/10/2002 01:35 PM
Please respond to platform-ui-dev
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-ui-dev] Back/forward actions [Bug 5700]
It's good limiting the initial approach to editors. I share Cagatay's
thoughts about this issue.
Introducing the navigation history we naturally will have to deal with two
kinds of code. Those that is aware of the navigation history and those
isn't.
Regarding the latter, I like the idea of having the workbench tracking
editor activation and entering activation events into the navigation
history. This way we'd at least provide better support than there is right
now.
Code that is aware of the navigation history should have an opportunity to
completely take over the population of the history. I think this is
necessary because opening an editor perceived by the user as a single
atomic operation might include several steps that in a different context
should all be part of the navigation history. Look at the Java editor.
Opening an editor for a method from inside the type hierarchy view
requires
two execution steps. The first is opening an editor for a given editor
input using the standard platform API. The second step is setting the
selection in the editor and revealing it appropriately. This uses
JDTspecific API. Taking the generic approach two entries would be added
to
the navigation history. The opening and activation plus the initial
positioning. This is because for the editor the initial positioning is
exactly the same when a method in the outliner would have been selected.
Thus arbitrary code should have a way to populate the navigation history.
Just two examples are editors and actions.
Just thinking of editors, an entry in the navigation history needs three
pieces of information: The id of the editor, the editor input, and a
description of what should be selected and revealed. Looking at existing
API the minimal approach would be a public method
"addNavigationHistoryEntry(String editorID, IEditorInput input, ISelection
selection)" probably at IWorkbenchPage. Choosing ISelection as the type of
the last parameter allows for an implementation of the Back/Forward
actions
without requiring the editor to support additional API. The implementation
would open an editor of the given ID for the given editor input using
IWorkbenchPage.openEditor(IEditorInput, String) and then retrieve the
editor's selection provider and call
ISelectionProvider.setSelection(ISelection).
Using ISelection is rather implicit. As the workbench needs to find out
whether it should add the activation of a given editor to the navigation
history or not, editors must be tagged anyway. Thus, I'd prefer to replace
ISelection with something more explicit such as ILocation or a better name
and introducing an interface having a single method
gotoLocation(ILocation).
The approach sketched out is more procedural than the more abstract
mechanism consisting of INavigationHistory and INavigationContext. Thus is
could be one concrete implementation scheme of it. In order to avoid
locking ourselves in the API trap too soon, I'd like to go with abstract
classes first rather than interfaces. This also prohibits clients from
just
implementing INavigationContext in some existing object. Not using
existing object reduced the probability of inviting memory leaks.
What exactly should be added to the navigation history needs more
investigation I guess. Especially how the navigation history compares to
the edit location history within a single editor. In JDT land for example
each usage of any outliner like view causing a new editor selection should
be added. I'd also prefer the entries in the navigation history to be
change resistant. For example in JDT they would not be just character
offset but Java elements. This way the history remains correct even after
changes. This approach however limits the usefulness of support that
could
generically be provided.
Kai
"Eduardo Pereira"
<Eduardo_Pereira@oti.c To:
platform-ui-dev@xxxxxxxxxxx
om> cc:
Sent by: Subject:
[platform-ui-dev] Back/forward actions [Bug 5700]
platform-ui-dev-admin@
eclipse.org
09/10/2002 05:27 PM
Please respond to
platform-ui-dev
Since many people requested it and it seems to be a nice feature to have,
we thought about giving this some priority. I got assigned to it but the
idea is that by having a commiter helping on it we could make things go a
bit faster so I would help on it instead of implementing it myself. Many
people have added themselves to the CC list and Cagatay and Jared have
talked about implementing/helping.
The question is: Are you guys willing to work on it? If so, lets talk
about and once we conclude what is needed we can implement it. For the
people that do not want to implement it, ideas are welcomed. I would like
to know who is interested in implementing it and how fast you think we can
do it based on the time you have to help.
Let's go to the technical part.
Due the plugability of eclipse I don't think it is possible so solve the
problem without depending on other plugins (the ones that have editors).
So the platform-ui would provide: (a) back/forward actions (menu
options/toolbar buttons); (b) a implementation that could automatically
add editors as they are activated; (c) an API that would allow editors to
added the "movements" that happen inside the editor. So the strategy that
would track (d) the navigation inside the editor would depend on the
editor itself. For example a Java editor could/would have a different
implementation of a HTML editor.
Here are some initial thoughts:
(a) seems to be simple; a few changes in WorkbenchActionBuilder and we
would have the actions in place.
(b) we have to play with it and see how it goes. The implementation would
be concentrated on editors only and would track the activation. Must make
sure that a back or forward action do not add a new item to the history.
(c) once it becomes API it gets difficult to change so we must agree on it
- add the method "public INavigationHistory getNavigationHistory()"
to IWorkbenchPage
- the interface INavigationHistory would be marked as "not intended
to be implemented by clients" and would provide methods like "public void
add(INavigationContext)"
- the interface INavigationContext would be marked as "should be
implemented by clients" and would have methods like "getLabel()" and
"gotoLocation()".
(d) each editor adds the navigation context items they want to add to the
list. Every time the user presses back or forward the message
"gotoLocation" is sent to the INavigationContext history.
Eduardo.
_______________________________________________
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
