Wow, lots of good helpful details! I hope we have some time for forms even for this release. It would be really good to add your comments to https://bugs.eclipse.org/bugs/show_bug.cgi?id=108470 so we can track all the folks who have been contributing towards the forms stuff in various ways. We hold contributors in high regard!
Mircea Luchian wrote:
Hello Ed,
I agree with your point on the properties view. It's purpose is justified for requirements not needing GUI validation, however, to implement on the spot GUI validation, the Properties view is not sufficient. For this reason, I believe an effort in 4.0 should be reserved towards the adjustment of the JET templates to generate an EMF editor using eclipse forms.
Here are the main changes I made. I feel that some of them could be improvements made for 4.0 whenever possible.
- I created a composite panel for every node in the tree. I modified the ObjectDetailsPage and removed the SampleSection inner class. I replaced it with a DetailsSection class responsible to create the panels and update them in function of the "Object input" variable
private void detailsPageSwitch(final Object input)
{
sampleSectionHolder = new DetailSection(toolkit, input, adapterFactoryItemDelegator, adapterFactoryLabelProvider, mform.getMessageManager(), this);
ScrolledPropertiesBlock.setDetailsPage(this);
sampleSectionHolder.createSection(input);
}
public void update()
{
detailsSection.setText(adapterFactoryItemDelegator.getText(input));
detailsSection.layout();
ScrolledPropertiesBlock.setDetailsPage(this);
sampleSectionHolder.updateSection(input);
}
With the detailsPageSwitch(), I pass the message manager of the managed form (mform) SrolledPropertiesBlock class to every panel. As such, the panels now have control on the message manager and can add / remove errors depending whether the user types in a widget or switches from the one node to another.
Thanks,
- There is one "problem" with radio buttons (A = "true" and B = "false" initially) attached to boolean attributes in EMF.
and
As radio buttons are mutually exclusive, setting B, unsets A automatically. This will register as two actions in the EMF's command stack (B = "true", then A = "false"). If the user presses undo once, the B radio button will be "false" leaving A radio button "false" as well. The user must execute a second undo action to revert to the initial state.
To prevent this from happening, I had to "hack" the EditingDomainActionBarContributor class located in org.eclipse.emf.edit.ui.action so I can call cutom Undo and Redo actions.
I created the following and put all custom code in my plugin:
public class CustomEditingDomainActionBarContributor extends MultiPageEditorActionBarContributor implements IMenuListener, IPropertyListener {
[....]
protected CustomUndoAction customUndoAction;
protected CustomRedoAction customRedoAction;
[....]
}
Custom Undo/Redo actions call themselves recursively if they detect that variables reserved for a group of mutually exclusive radio buttons are all set to false
public class CustomRedoAction extends RedoAction {
@Override
public void run()
{
super.run();
MyEditor.updateFromRedoUndo();
Command mostRecentCommand = domain.getCommandStack().getMostRecentCommand();
if (mostRecentCommand instanceof SetCommand)
{
SetCommand mostRecentSetCommand = (SetCommand) mostRecentCommand;
EObject owner = mostRecentSetCommand.getOwner();
/***********************************************************************************************************
* MyNodeImpl OWNER
**********************************************************************************************************/
if (owner instanceof MyNodeImpl)
{
if (!((MyNodeImpl) owner).isReadOnly() && !((MyNodeImpl) owner).isReadWrite() && !((MyNodeImpl) owner).isWriteOnly())
run(); // RUN AGAIN TO SET THE RADIO BUTTON THAT WAS DESELECTED
[....]
- The eclipse forms panels (with every widget bound to the model) was not updated during an Undo or Redo action. I added both actions a MyEditor.updateFromRedoUndo(); statement that calls the editor to refresh the current selected panel in the Scrolled properties block:
public static void updateFromRedoUndo()
{
try
{
if (scrolledPropertiesBlock.treeViewer.getTree().getSelection().length != 0)
{
scrolledPropertiesBlock.getObjectDetailsPage().update();
}
}
catch (Exception e)
{
}
}
This update mechanism for the eclipse forms does not exist on the EMF example found on the net.
- I added error and warning status variables for every node in the model. This is really custom work, however with the usage of the eclispe forms' message manager, this complements very well the user experience.
Data can have errors or warnings in the panels, so I changed the item providers for every node to display the icons in an error/warning state. Whenever we use validation on such panels, the nodes in the tree must reflect these same error states for later correction (say the errors exist but the user chooses to save/closes his file and chooses fix the errors later during the day; he must then know where the errors are...).
I also made the parent nodes aware if their children have errors or warnings so they can be propagated to the root node. This makes the errors easier to search if the nodes are collapsed. How the error/warning flags are initialized on the faulty node is custom implementation, however, the error propagation to the parent nodes is performed in the model's implementation classes. Only the latter mechanism could be accomodated in a future version of EMF. See pictures below for a better understanding. I had to hide some information as the product is still under development.
1.![]()
2.
3.
4.
5.
6.No more errors / warnings in the tree
Mircea
Ed Merks wrote:Tom,
All that command stuff came long after we'd already done the EMF.Edit support. It's impossible to keep up with the Jone's when there are dozens of them and only two or three of us. Maybe an Eclipse 4.0 effort would allow us to throw away some of the cruft and focus on supporting only the latests and greatest patterns.
I'd be happy to provide hooks for whatever solution works well for this type of scenario. I hope we can find at least a bit of time this release to look at how to support forms and exploit data binding. I'm kind of sick and tired of the limitations of the crummy properties view (which doesn't even work for RAP).
Tom Schindl wrote:
Ed Merks schrieb:
Mircea,
Gosh, I don't have a lot of experience with this type of thing. I hope someone else has some clue, because I won't even know where to begin. Maybe Tom will read this and have an idea...
Tom has read it :-) I'm not really skilled when it comes to all those key-binding thingies.
But the following could work. If your TextWidget receives focus I'd try to reset the copy/cut/paste actions to their original counter parts:
widget.addFocusListener( new FocusListener() {
IAction emfcutaction = actionBars.getGlobalActionHandler(ActionFactory.CUT.getId());
IAction emfcopyaction = actionBars.getGlobalActionHandler(ActionFactory.COPY.getId());
IAction emfpasteaction = actionBars.getGlobalActionHandler(ActionFactory.PASTE.getId());
IAction standardCut = ActionFactory.CUT.create(....);
IAction standardCopy = ActionFactory.COPY.create(....);
IAction standardPaste = ActionFactory.PASTE.create(....);
public void focusLost(FocusEvent e) {
actionbars.setGlobalActionHandler(ActionFactory.CUT.getId(),emfcutaction);
actionbars.setGlobalActionHandler(ActionFactory.COPY.getId(),emfcopyaction);
actionbars.setGlobalActionHandler(ActionFactory.PASTE.getId(),emfpasteaction);
actionbars.updateActionBars();
}
public void focusGained(FocusEvent e) {
actionbars.setGlobalActionHandler(ActionFactory.CUT.getId(),standardCut);
actionbars.setGlobalActionHandler(ActionFactory.COPY.getId(),standardCopy);
actionbars.setGlobalActionHandler(ActionFactory.PASTE.getId(),standardPaste);
actionbars.updateActionBars();
}
});
If this works it would be great if the EditingDomainActionBarContributor would provide a possibility to restore the actions.
Another possible solution that comes to my mind is usage of the commands framework. I don't know if COPY/CUT/PASTE are handled by commands (but Paul knows so I've added eclipse.platform to the CC list :-).
Tom
M. Luchian wrote:
Hello,
The EditingDomainActionBarContributor.java class defined in the EMF plugins overrides the Windows CUT/COPY/PASTE actions' keyboard shortcuts (CTRL-X, CTRL-C, CTRL-V) with EMF's own.
This is correct as long as the actions are performed on the tree. However, I implemented an editor based on eclipse forms, with text widgets (Windows native) handling the COPY CUT PASTE actions with a right click of a mouse. As the mouse actions work fine and interact with the windows' clipboard, pressing the keyboard shortcuts for the same actions in the text widgets will call the actions reserved by EMF ... This is problematic as the CTRL-X, CTRL-C, CTRL-V shortcuts are overridden with the EMF copy, cut, paste actions for the entire editor.
Is there a possible way to register the actions for the editor's tree only? (See picture)
I have a CustomEditingDomainActionBarContributor.java replacing a few small things from the original EditingDomainActionBarContributor.java class, but I don't want to manage the registering / unregistering the copy, cut and paste actions when the tree is in focus or not.
Any help appreciated
Thanks,
Mircea
