[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Back/forward actions [Bug 5700]
|
Since I had to spin a release of my plugin anyway to fix an M1 bug, I added
support for Back/Forward outline view selections by calling
selectAndReveal(). That was easy. I like very much that I can support this
feature in a backward compatible way. I hope this aspect doesn't get lost in
the rush to make the API more complicated. ;-}
Three comments:
1) So why doesn't the history use Positions in the corresponding document?
2) "Backward". The rest of the world thinks this action is called "Back".
3) I would like to do something with Find/Replace (even though browsers
don't) because my personal experience is that Find is the easiest way to get
lost in a file. I think the best and least intrusive implementation would be
to record only the beginning (pre-find/replace) and the ending
(post-find/replace) positions. I.e., each successive "find next" would
replace the ending position, so that the history does not grow unless the
find target is changed. But for those who like options, there could easily
be a history option related to Find/Replace: a) Ignore Find/Replace, b)
Record only last stop (above), c) Record all stops. Let the user decide.
Since only option (a) is entirely trivial, I'm interested in what others
think.
Bob
----- Original Message -----
From: "Eduardo Pereira" <Eduardo_Pereira@xxxxxxx>
To: <platform-ui-dev@xxxxxxxxxxx>
Sent: Wednesday, September 11, 2002 10:14 AM
Subject: 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
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
