[
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 will need some guidelines otherwise we would end up with
too much state added to the history making this feature useless.
Inter-page: I think this would be done automatically by the platform UI
and API users would not have to think aboult it. Actions like tab switches
end up on editor activation (made visible at least) and that would be
track internally.
Intra-page: We will have to play with it a bit and get the feedback from
the users to see what we need to add to the history (GotoLine, F3, F4,
etc). Once we have an idea of what we really need then a guideline should
be written.
Eduardo.
"Bob Foster" <bob@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
09/10/2002 01:07 PM
Please respond to platform-ui-dev
To: <platform-ui-dev@xxxxxxxxxxx>
cc:
Subject: Re: [platform-ui-dev] Back/forward actions [Bug 5700]
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
>
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
