Community
Participate
Working Groups
Build 20020214 - do a sync - make a change in the left pane - Save is enabled on the left pane's context menu, but File/Save and Ctrl+S do not work
Hooking the Save global action is not the right approach. In a normal editor, the editor should issue a property change for the dirty property, and answer true for isDirty() when there have been changes. Save will then be enabled, and call doSave(IProgressMonitor) when invoked. The Compare editor seems to delegate this to the CompareEditorInput's isSaveNeeded() method, which SyncCompareInput doesn't seem to handle properly.
I think the compare editor's save behavior is different from a regular editor because it is shown in a view. Andre can comment on the Eclipse limitations of having an editor in a view. Over to you Andre.
Yes, it is a view, so File/Save can't be hooked. Feel free to close or defer.
we are now retargeting other actions to view, so it should be possible to do the same for the Save action. Compare could implement a custom save action that is retargeted to the global save action. I don't see why this shouldn't work.
*** Bug 274 has been marked as a duplicate of this bug. ***
*** Bug 8987 has been marked as a duplicate of this bug. ***
*** Bug 19584 has been marked as a duplicate of this bug. ***
So what should I do? I'm using GlobalActionHandlers in Compare for Cut/Copy/Paste, Select All, Next Difference, Previous Difference, and Save. Retargeting works for all but "Save" when switching between ViewParts and EditorParts. Only the Save action behaves differently: even if the Sync-view is active, the Save action targets an editor (if any). How can I retarget Save to the Sync-view? (And what should happen with "Save As" and "Save All"?)
(Adding KevinM to the cc list). This is on the "hot list" of PRs to address for 2.1 based on input from the other teams. Save is not a global retargetable action (not supported by IActionBars.setGlobalActionHandler). It always targets the active editor. However, this appears to be counterintuitive to most people. If the current view supports an open/edit/save lifecycle (which only editors are supposed to do, but that's another argument), then the user expects Ctrl+S and File/Save to work. There are three ways we can solve this. 1. Make the sync editor an editor. This is unlikely to happen for 2.1 <g>, and there may be other valid reasons for why it's a view (e.g. screen real estate usage). 2. Allow the individual Save actions to be retargeted to the view if it has registered handlers for them. If the view has not registered handlers for them, they would still target the active editor. This could lead to surprising behaviour if the view handles Save but not Save As.... It would not make sense for the view to handle Save All, but this means that Save All would only target the editors. 3. Allow views to implement a new interface (either directly or via IAdaptable) which handles the save related APIs currently on IEditorPart. Something like: interface ISaveablePart { static final int PROP_DIRTY = 0x101; void doSave(IProgressMonitor); void doSaveAs(); boolean isDirty(); boolean isSaveAsAllowed(); boolean isSaveOnCloseNeeded(); } IEditorPart would be changed to extend this interface (IEditorPart.PROP_DIRTY would have to remain on IEditorPart, but could refer to ISaveablePart.PROP_DIRTY as long as the value remains the same, which it should). If the current view implements ISaveablePart, then Save and Save As... would be redirected to it. Otherwise, they would target the active editor as before. For Save All, all views in the current perspective implementing ISaveablePart would be told to doSaveAs() (if dirty). However, there are other issues with (3): 1. You sometimes get a dialog to save all dirty editors, e.g. when doing a build or sync, or exitting. Should views with unsaved changes be included in this dialog? 2. How to indicate dirty state? You get this for free in editors. Should we add a '*' to the view title if the view is dirty? 3. There may be views with unsaved changes that are open in other perspectives, but not visible in the current perspective. It may be confusing if Save All does not save their changes, but it would be equally surprising to save changes in hidden views. This issue does not arise with editors since they are shared across all perspectives. Note that the same view may be open in multiple perspectives too. For this particular bug, (2) would probably suffice for 2.1 and we can think about (3) some more for 2.2. Sync would implement Save and Save As... (always disabled). Save All would just target the editors. I think this is a good 95% solution.
#2 sounds good. Does this mean that registering a GlobalActionHandler for Save (as I already do) would be enough to make this work?
That would suffice for Save. I think we should also allow you to hook Save As... so that you can disable it, otherwise Save will target the view but Save As... will target the editor.
Since the sync view is VCM, moving over... Please let me know what you need from Compare.
Actually, I'm having second thoughts about hooking individual Save actions. I think doing something like the ISaveablePart would make more sense, even if it has restricted functionality for 2.1 (e.g. Save only, not Save As...). UI team needs to add support for this.
I have added support for the ISaveablePart interface and updated the Save and Save As action to handle views which implement or adapt to this interface. All this code has been marked as experimental. It still not clear to me at least that views should become part of this open/edit/save lifecycle. We should in the next release look at whether it makes sense for the Sync to become an editor (or more precisely, a couple of views and editor). If we determine that we really need views to have access to Save actions, then we need to address the issues listed in Nick's comment above (#9). As a test, I updated the SyncView to be a ISaveablePart and it all worked. Whomever doing the work on SyncView can come and see me for details.
I created a view that contains an editor, so I currently have my view implement ISaveablePart so that when a Save is performed in my view, I save inside my embedded editor rather than save the current active editor. I notice that as of 3.0 M3, ISaveablePart is still marked as "experimental API" When will this API stop being "experimental"?
Generally we recommend that workbench parts that follow an open/edit/save/close lifecycle be implemented as editors, not views. The old sync view was an exception, which is why we added ISaveablePart. However, in R3.0 the sync view has been refactored into a live sync view (showing just the sync tree) and compare editors for viewing/editing the changes, so ISaveablePart is no longer used by the sync view. Could you please open a new feature request against Platform UI providing more details about what you're trying to do?
