Community
Participate
Working Groups
Currently, when a property is changed in the Customize Palette dialog, the PaletteCustomizer applies the change immediately to the palette model. When the Cancel button is pressed the changes are not reverted. Why not keep track of the changes to be made and only change the palette model when the Apply or Ok buttons are pressed?
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.
