Re: [platform-ui-dev] Back/forward actions [Bug 5700]

["Bob Foster" <bob@xxxxxxxxxx>]

I am willing to spend time working on this and to test the API in my editor
(XMLBuddy).

It would help to establish a set of UI guidelines for minimal support. In
fact, it is essential. If editors implement seriously disjoint subsets of
each other's features it will result in a most confusing user experience.
The guidelines (not necessarily the API) should address how much state is
recorded by INavigationContext. Specifically, are selections recorded?

Guidelines should be developed separately for inter-page and intra-page
actions. (I am using page in the sense browsers do instead of in the
vestigual way Eclipse does.) I have seen IDEA cited several times as an
examplar (most recently by Jesper Nordenberg in bug 5700). It would help for
someone to note for the record exactly what IDEA does. Browsers are another
exemplar, but they provide a very small subset of what I believe IDEA does.
For example, they do not go back from a Find.

Inter-page: It seems a no-brainer that each time the user's focus is changed
from one editor to another or one resource to another within the same
editor. Actions the editor implements are no problem. How would the API you
sketched be used to implement cases where the editor is not involved in the
action, or only involved passively? E.g., Search, tab switches in editor
view. How does this feature affect multiple editor views visible at the same
time?

Intra-page: The definition offered by Jesper is that all navigation that
does not involve mere cursor movement should enter the history, but that is
more a goal statement than a guideline. What about scrolling, Page Up, Home?
Whatever is determined to be minimal support should be implemented directly
in AbstractTextEditor, SourceViewer, StyledText and friends.

Finally, the proposed API, wisely I think, does not determine what is an
"editor", leaving the field open for those who want other views considered.
But the discussion should not be bogged down by this. If someone wants to
make a case and do the implementation, swell. Otherwise, a first round
involving only what we normally think of as editors would be fine with me.

Bob

----- Original Message -----
From: "Eduardo Pereira" <Eduardo_Pereira@xxxxxxx>
To: <platform-ui-dev@xxxxxxxxxxx>
Sent: Tuesday, September 10, 2002 10:27 AM
Subject: [platform-ui-dev] Back/forward actions [Bug 5700]


> 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
>