We have a big problem with the selection behavior in History View.
GitHistoryPage.createControl installs a selection provider to publish the selection:
getHistoryPageSite().getPart().getSite().setSelectionProvider(
revObjectSelectionProvider);
1. This does not work correctly (see Bug 322751): after showing the history view, the selection is not properly published.
If you click in another view and then in history view, the selection is published correctly.
2. Second problem: if you trigger Team->show in local history on a not shared file afterwards, still the selection of the Git History page is published.
I assume the following would be the right solution:
org.eclipse.team.internal.ui.history .GenericHistoryView. createPartControl
needs to be extended to set a selection provider. This provider in turn uses selection providers of the pages (GitHistoryPage, CVSHistoryPage, LocalHistoryPage).
But for this solution GenericHistoryView needs to be extended and we cannot rely on this since we have to be compatible with Eclipse 3.5.
So we removed setSelectionProvider from GitHistoryPage and changed the handler implementations not to take the global selection. Instead the page selection is taken.
But then we got the next problem: it seems that the system calls the enabled method of the handlers also only if the global selection has changed. So once e.g. the reset action is enabled in history view, it remains enabled if the selection is enhanced
to two commits (isEnabled is not called by the system).
<menu
icon="icons/obj16/reset.gif"
id="reset"
label="%ResetMenuName">
<visibleWhen
checkEnabled="true">
</visibleWhen>
<command
commandId="org.eclipse.egit.ui.history.Reset"
label="%Soft_Reset_label"
style="push"
tooltip="%Soft_Reset_tooltip">
<parameter
name="org.eclipse.egit.ui.history.ResetMode"
value="Soft">
</parameter>
<visibleWhen
checkEnabled="true">
</visibleWhen>
</command>
======> Question: is our assumption right that we cannot use commands and handlers for history view if history view does not install a selection provider?
If this is true we have to go back to actions inside a programmatically created context menu.
Comments?
--Jens
