Bug 512279 - [Tooling] Direct editor for a state does not finish edit when pressing enter
Summary: [Tooling] Direct editor for a state does not finish edit when pressing enter
Status: CLOSED FIXED
Alias: None
Product: Papyrus-rt
Classification: Modeling
Component: tool (show other bugs)
Version: 0.8.0   Edit
Hardware: PC Windows 7
: P3 normal
Target Milestone: 1.0.0   Edit
Assignee: Young-Soo Roh CLA
QA Contact:
URL:
Whiteboard:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2017-02-16 06:55 EST by Peter Cigehn CLA
Modified: 2017-07-20 09:53 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Cigehn CLA 2017-02-16 06:55:18 EST
When using the direct editor for a state in a state-machine diagram, either directly after creating the state, or selecting the state in the diagram and pressing F2, and pressing the enter key to finish editing the name, moves the cursor to the next line and does not finish the editing as expected.

Steps to reproduce:

1) Create a UML-RT model based on the "UML-RT for C++" template
2) Create a capsule
3) Create a state-machine for the capsule
4) Open the state-machine diagram
5) Add a new state using the state tool from the palette
6) The direct editor is not activated
7) Start typing a new name and press enter
8) The edit box is now increased with a new line and the cursor is placed on the new line

Expected result would have been to simply finish the naming of the state, similar to how it is done for choice point and other pseudo-states.
Comment 1 Charles Rivet CLA 2017-04-26 12:50:09 EDT
(In reply to Peter Cigehn from comment #0)
> When using the direct editor for a state in a state-machine diagram, either
> directly after creating the state, or selecting the state in the diagram and
> pressing F2, and pressing the enter key to finish editing the name, moves
> the cursor to the next line and does not finish the editing as expected.
> 
> Steps to reproduce:
> 
> 1) Create a UML-RT model based on the "UML-RT for C++" template
> 2) Create a capsule
> 3) Create a state-machine for the capsule
> 4) Open the state-machine diagram
> 5) Add a new state using the state tool from the palette
> 6) The direct editor is not activated
> 7) Start typing a new name and press enter
> 8) The edit box is now increased with a new line and the cursor is placed on
> the new line
> 
> Expected result would have been to simply finish the naming of the state,
> similar to how it is done for choice point and other pseudo-states.

This is almost the same behaviour as in base Papyrus. in step 6, above, the direct editor is activated in Papyrus.

Should it be pushed to Papyrus as a more desirable approach (potentially breaking workflow for established Papyrus users) or should it be solved in Papyrus-RT?
Comment 2 Peter Cigehn CLA 2017-04-27 05:27:06 EDT
(In reply to Charles Rivet from comment #1)
> This is almost the same behaviour as in base Papyrus. in step 6, above, the
> direct editor is activated in Papyrus.

Sorry for the confusion. But I made a small, but very crucial, spelling error in step 6. It should of course be: 

6. The direct editor is now activated

Otherwise you are not able to start typing a name in step 7. So I expect the behavior and steps to be rather identical between Papyrus-RT and Papyrus.

> Should it be pushed to Papyrus as a more desirable approach (potentially
> breaking workflow for established Papyrus users) or should it be solved in
> Papyrus-RT?

Not sure if we need to do that. We have "overridden" several of the direct editors, using the extension mechanism that Papyrus provides for this, for several other model elements (ports, capsule parts, transitions and so on), so I think that we could simply do the same for states as well and keep this change local to Papyrus-RT.

The only aspect is if we have similar issues were Papyrus for some reason have made it not possible to override the default direct editor (some priority issue I think). If I understood it correctly we have had some issues with this related to Bug 513060 for example, where some workaround had to be made (which now is tracked for reverting via Bug 513695).

I suggest that we assume that we can fix this locally in Papyrus-RT by introducing the same simple (single-line) name editor as we have done for several other elements in Papyrus-RT. Only if we bump into issues, we push for a fix in Papyrus (similar to as what had to be done for Bug 513060).
Comment 3 Peter Cigehn CLA 2017-05-23 07:55:48 EDT
Since no one is assigned, I move this one back to NEW to make that clear.
Comment 4 Charles Rivet CLA 2017-05-25 12:54:10 EDT
Young-Soo to investigate and implement simple solution is possible. Else document workaround in release note and address in a future release.
Comment 5 Eclipse Genie CLA 2017-05-30 14:36:02 EDT
New Gerrit change created: https://git.eclipse.org/r/98251
Comment 7 Peter Cigehn CLA 2017-06-01 04:34:06 EDT
Verified to be fixed in the latest Papyrus-RT build (#373). The direct editor for a state now finish when pressing enter as expected, making it easier/faster to enter a name for a new state.
Comment 8 Peter Cigehn CLA 2017-06-01 04:34:22 EDT
Closing as verified fixed.
Comment 9 smaoui asma CLA 2017-06-02 09:04:41 EDT
Hello 

This introduce regression for direct editor for RT Port. The gerrit is not supposed to change the direct editor of Port. 
I tested the port direct editor typed by a system protocol and I got the validation marker again: the xtext editor is used instead of the UML RT editor

can some one else test if it works for ports ?

Thanks
Comment 10 Young-Soo Roh CLA 2017-06-02 09:11:40 EDT
(In reply to smaoui asma from comment #9)
> Hello 
> 
> This introduce regression for direct editor for RT Port. The gerrit is not
> supposed to change the direct editor of Port. 
> I tested the port direct editor typed by a system protocol and I got the
> validation marker again: the xtext editor is used instead of the UML RT
> editor
> 
> can some one else test if it works for ports ?
> 
> Thanks

Hi Asma,

I will check it and let you know.
Comment 11 Peter Cigehn CLA 2017-06-02 09:34:10 EDT
(In reply to smaoui asma from comment #9)
> This introduce regression for direct editor for RT Port. The gerrit is not
> supposed to change the direct editor of Port. 
> I tested the port direct editor typed by a system protocol and I got the
> validation marker again: the xtext editor is used instead of the UML RT
> editor
> 
> can some one else test if it works for ports ?

I tested this in the latest nightly build, and I cannot see this issue. I can create port based on a system protocol, and I don't get the error marker as you used to. From what I can see, the direct editor for a port is the plain name based one (it only shows the name of the port when editing, and not the "name : type" style as the more advanced editor from base Papyrus does.

Were have you made you test? In a developer run-time workbench, or with the tester setup?
Comment 12 Peter Cigehn CLA 2017-06-02 09:41:37 EDT
(In reply to Peter Cigehn from comment #11)
> (In reply to smaoui asma from comment #9)
> > This introduce regression for direct editor for RT Port. The gerrit is not
> > supposed to change the direct editor of Port. 
> > I tested the port direct editor typed by a system protocol and I got the
> > validation marker again: the xtext editor is used instead of the UML RT
> > editor
> > 
> > can some one else test if it works for ports ?
> 
> I tested this in the latest nightly build, and I cannot see this issue. I
> can create port based on a system protocol, and I don't get the error marker
> as you used to. From what I can see, the direct editor for a port is the
> plain name based one (it only shows the name of the port when editing, and
> not the "name : type" style as the more advanced editor from base Papyrus
> does.
> 
> Were have you made you test? In a developer run-time workbench, or with the
> tester setup?

One thing that I know from experience is that things does not work out very well in existing workspaces. I usually create a new workspace to avoid any issues with old .metadata in the workspace. If I remember correctly, I think that I have exactly these kinds of issues with direct editors not working as expected when I tested in an old existing workspace, but which started to work as expected in a new fresh workspace...
Comment 13 Young-Soo Roh CLA 2017-06-02 10:15:01 EDT
(In reply to smaoui asma from comment #9)
> Hello 
> 
> This introduce regression for direct editor for RT Port. The gerrit is not
> supposed to change the direct editor of Port. 
> I tested the port direct editor typed by a system protocol and I got the
> validation marker again: the xtext editor is used instead of the UML RT
> editor
> 
> can some one else test if it works for ports ?
> 
> Thanks

Asma,

I changed port direct editor priority from highest to high because I don't think we need to set it to highest. However I don't think this does change anything since no other editor has higher priority than the medium priority. 

As Peter says there is possibility that your existing workspace remembers the preference setting for direct editor. See bug#517549. If you ever changed default direct editor then you have no way to get the default editor back due to this bug. To fix this manually, you need to open .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.papyrus.extensionpoints.editors.prefs file and remove the entry for the port direct editor and restart the workbench.
If you are using Oomph preference recorder then you should also remove the stored settings from the Oomph settings file as well.

HTH
Comment 14 smaoui asma CLA 2017-06-02 10:38:33 EDT
OK. I tested with the last successeful build and it works as expected. However I still got the wrong behavior in my runtime environement (I test the behavior in a second eclipse instance, the first one contains the master plugins (last version of code))

I will fix my workspace preferences as suggested by Young S. 

If it works in the RCP product, never mind if it still did not working in my runtime environement :)

So, Sorry for the disarrangement