Community
Participate
Working Groups
In 'eclipse', there are three Command frameworks which support/enable very similar functions ( redo/undo/execute ). Having similar functions would confuse the developers and affect the software maintenance cost. Need to converge GEF command to Platform's command. No more similar functions.
What exactly are you suggesting? Should our Command class implement IUndoableOperation?
Could be. The problem we are having now is that we are confused which 'command' is the best to be used. For example, if we are developing a GEF application, using GEF command is the best because some GEF apis requires GEF command ( i.e. EditPart#getCommand ). But if we use EMF as the model to EditPart, probably using their Command would be best. If GEF command is compatible with Platform's one and EMF is as well ( though they don't like Platform's command :), we can develop our command based on Platform's one. I think the goal is for us to be able to use a single Command to Platform and GEF ( and EMF ... ) Please consider having this compatibility in the future plan item. .
*** Bug 125494 has been marked as a duplicate of this bug. ***
I was asked to give feedback why it's important for our project that GEF command stack will be based on Eclipse Undoable Operation Support. I suppose that the most important reasons were describe here already. I'll not open discussion why Eclipse Undoable Operation Support is preferable for command management, I suppose that it's clear (only execute function definition with Status returning preferable on GEF Command implementation). The problem which we faced with, comes from multiple usage of single command. We have several editors, where one of them is GEF editor, and sharing bulk of commands which can be executed for each of these editors. Since all commands have to be extended from GEF Command and we did not want to implement for every command IUndoableOperation interface, we HAVE TO use GEF command stack implementation. Moreover we thought to overwrite CommandStack, but as was mentioned before it's not exactly possible, because some GEF apis requires GEF command ( i.e. EditPart#getCommand )
*** Bug 284867 has been marked as a duplicate of this bug. ***
I would also like to see this change. I think the best approach would be to re-implement the GEF API using the platform Operation (for Command) and IOperationHistory (for CommandStack) and add direct support for the platform operation framework. This way existing GEF applications won't break but we could code to the platform implementation going forward.
