Summary: | [Palette] Cannot cancel changes made in Customize Palette dialog | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] GEF | Reporter: | Cherie Revells <crevells> | ||||
Component: | GEF-Legacy GEF (MVC) | Assignee: | gef-inbox <gef-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | ahunter.eclipse, hudsonr, nyssen, thatnitind | ||||
Version: | 3.2.1 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Cherie Revells
2007-11-27 10:00:20 EST
I see that the TreeViewer in the PaletteCustomizeDialog is also based on the palette model, so if the palette model isn't updated until later, the tree viewer won't be updated on the fly either. Cancel calls revert to saved on the customizer. Can the customizer not undo the effects of the dialog? The customizer saves and restores the state. The intention is that revertToSaved() would reload the last saved state, hopefully applying it to the palette being displayed. Yes, I think that is what I will need to do, but why it isn't done in GEF? Couldn't the GEF PaletteCustomizer generically save and restore the state? Seems to me that every client would need to do this. > Yes, I think that is what I will need to do, but why it isn't done in GEF?
> Couldn't the GEF PaletteCustomizer generically save and restore the state?
> Seems to me that every client would need to do this.
Probably so in the simple case of just hiding and reordering entries, although even that is not very simple (number of entries changes between releases). As long as the entries, groups, and drawers all had IDs, GEF could probably use mementos to persist the default properties.
In more complex cases, the user can create their own entries, specifying icons, creation parameters, etc., all of which is domain specific, so its persistence can't be handled generically. There are also cases where the palette is a contribution from multiple sources, which means the changes must be persisted in multiple places.
So I guess this is something that we most likely wouldn't do in GEF? If so, I will close this bugzilla. By the way, in GMF, we try to enforce that all palette entries have ids. We subclassed the GEF palette entry classes so that id is passed in the constructor. Created attachment 124892 [details]
I've created default save and restoreToSaved methods.
Since the methods were previously abstract, in order to see the change, you must go into a projects PaletteCustomizer class (in the logic diagram it is LogicPaletteCustomizer.java) and either remove the empty save and restoreToSaved methods, or add calls to the superclass.
Unset target milestone as the specified one is already passed. Assigning back to gef-inbox (and state to new), as specified assignee is no current GEF committer. |