Community
Participate
Working Groups
The CheatSheet API gives no way to restart/reinitialize the cheat sheet. This is a problem when the cheat sheet is opened programmatically and must appear in its initial state. In the current behaviour opening a cheat sheet always restores the cheat sheet last state, and there is no way to restart it programmatically.
+1 for being able to programmatically restart a cheat sheet. This is a major issue if you want to be able to utilize a cheat sheet to assist with a recurring activity. Forcing the user to manually restart the next time they need guidance from the cheat sheet provides a poor user experience. Along these same lines it might be nice if one could not only restart the cheat sheet but also provide a cheat sheet manager which is pre-initialized with some values used in the cheat sheet (null could be passed for the trivial restart case). This would allow for seeding the cheat sheet with values for cases where the context might allow you to provide intelligent default data.
We should implement this for 3.2 M6 and allow the cheat sheet data to be pre-initialized. At the same time we should add a function to get the key set for a cheat sheet manager, this would be very useful for composite cheat sheets. Since ICheatSheetManager is marked with * <p> * This interface is not intended to be implemented by clients. * </p> This is a non-breaking change. Below are the two new functions I propose adding to org.eclipse.ui.cheatsheets.ICheatSheetManager. /** * Get the cheat sheet manager for the enclosing composite cheat sheet. * @return The cheat sheet manager for the composite cheat sheet which contains * this cheat sheet as a task or <code>null</code> if this cheatsheet was not * opened as a subtask of a composite cheat sheet. * @since 3.2 */ public ICheatSheetManager getParent(); /** * Get the keys for the data in this cheat sheet manager * @return The set of keys. * @since 3.2 */ public Set getKeySet(); }
I forgot to include the API change that is central to this defect - this is the function to be added to org.eclipse.ui.cheatsheets.ICheatSheetViewer to perform the restart. This is also a non-breaking change. * <p> * This interface is not intended to be implemented by clients. * </p> Here's the new function: /** * Sets the currently active cheat sheet to its initial state and set * the cheat sheet manager data. * @param cheatSheetData A map whose keys and values are all of type * <code>java.lang.String</code> or <code>null</code> to reset all data in * the cheat sheet manager. */ public void reset(Map cheatSheetData);
Even non-breaking API additions need to be approved by the PMC at this stage. CCing McQ.
Tentatively setting target to M6 (awaiting PMC approval).
John is correct, in that all API changes need to be approved. In particular, one of the purposes of the API freeze is to ensure that other projects that depend on us can understand what they are getting early enough to be able to make use of it. If our contracts change in interesting ways (such as being able to reset cheat sheets programatically) it could significantly influence how their workflows are implemented, and if this was a feature that they really wanted, but couldn't use because it was too late in the cycle, they would be pissed. +1 to this particular change, ok to proceed, but we really need to push towards making these things happen earlier in the cycle.
Created attachment 35860 [details] Patch including API, implementation and JUnits Thanks for the approval, here's the patch.
Applied.
