Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Back/forward actions [Bug 5700]

Sorry for my absence the last two weeks, I'm back from a (much needed) vacation. My comments are below:

Another way of looking at this problem is to consider any action that should open/reveal a part of a model in an editor as an "open" action. In other words, why not have just one IWorkbenchPage.open(IAdaptable) method? Clients that need to show stuff in editors (opening types in Hierarchy view, clicking on a method in outliner) would delegate to this. The implementation could ask for a corresponding INavigationContext adapter that would provide an editor input/selection/other stuff to navigate to this model element and reveal it in an editor of correct type. INavigationContext could have a simple implementation in the platform for simple text editors and clients could implement theirs to provide their own navigation data.

A second part to this scheme would be a filter mechanism to let plugins customize (substitute/cancel) what goes into the navigation history since we may not want every open action to be recorded in the history. A read only API to get the navigation history can be provided but changing it manually is not permitted.

As an example, most of the implementation for INavigationContext in JDT to map Java elements to editor inputs could come from the org.eclipse.jdt.internal.ui.javaeditor.EditorUtility class.

This alternative would provide a clean API to "open" any custom model in a generic way in the platform besides handling navigation needs in a central place. It would also require rework in clients, though it seems to me that in most cases the new code would be simpler. This is also different from the selection based approach I think is implemented in the latest builds. I don't have clear thoughts on how to editor location history (as opposed to workbench navigation history); the more I think about it the more it seems messy. Maybe letting outliner selections and find/replace positions in the history is enough.

Kai-Uwe Maetzel wrote:

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


--
CK.




Back to the top