Bug 497865 - [Control Mode] UI for dependent controlled units
Summary: [Control Mode] UI for dependent controlled units
Status: VERIFIED FIXED
Alias: None
Product: Papyrus
Classification: Modeling
Component: Core (show other bugs)
Version: 2.0.1   Edit
Hardware: All All
: P2 enhancement (vote)
Target Milestone: 3.0.0   Edit
Assignee: Christian Damus CLA
QA Contact: Peter Cigehn CLA
URL: https://wiki.eclipse.org/Papyrus/Neon...
Whiteboard:
Keywords: noteworthy
Depends on: 496299
Blocks:
  Show dependency tree
 
Reported: 2016-07-13 14:58 EDT by Christian Damus CLA
Modified: 2017-05-10 04:16 EDT (History)
1 user (show)

See Also:
give.a.damus: documentation+
give.a.damus: neon+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Damus CLA 2016-07-13 14:58:25 EDT
With the implementation of a controlled unit flavour that is not editable independently of its parent unit in bug 496299, some new UI is in order to let users determine which flavour a controlled unit should have:  "classic" or the new "dependent" unit.

(internally, these controlled units are dubbed "shards", but I'm not sure that this is the best terminology to face the user.  Ideas for a branding name are welcome)

This new UI should provide:

* an option on creation of a controlled unit to implement either classic or shard mode.  This is always remembered for the next invocation of the control action
* an action to change a controlled unit from classic to shard mode and vice versa
* a decorator on the ibis-head icon for controlled units in the Project Explorer.  This would be new for the "classic" mode units, too.  This would be driven by the new index, which tracks all cross-resource containments and also distinguishes those that are shards from the classic mode. so potentially these flavours could have different decorations
Comment 1 Christian Damus CLA 2016-07-26 13:44:42 EDT
A link to a design page on the wiki:

https://wiki.eclipse.org/Papyrus/Neon.1_Work_Description/Improvements/Control-Mode
Comment 2 Eclipse Genie CLA 2016-07-26 17:35:59 EDT
New Gerrit change created: https://git.eclipse.org/r/77939
Comment 3 Eclipse Genie CLA 2016-08-23 17:00:44 EDT
Gerrit change https://git.eclipse.org/r/77939 was merged to [streams/2.0-maintenance].
Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=9073a527c12f1be30333e7e0d6b3d490ba751a36
Comment 4 Eclipse Genie CLA 2016-08-23 18:01:42 EDT
New Gerrit change created: https://git.eclipse.org/r/79573
Comment 6 Christian Damus CLA 2016-08-23 18:35:52 EDT
(In reply to Eclipse Genie from comment #3)
> Gerrit change https://git.eclipse.org/r/77939 was merged to
> [streams/2.0-maintenance].

(In reply to Eclipse Genie from comment #5)
> Gerrit change https://git.eclipse.org/r/79573 was merged to [master].
Comment 7 Peter Cigehn CLA 2016-08-24 04:20:06 EDT
I've tested this in the context of the latest Papyrus-RT build, based on the latest Papyrus Neon build and it looks good. First I was expecting the "shards" to be more different, but maybe it is best to stick with the "submodel"-terminology and only differentiate if its "independent" or not.

One thing that I noted though was that when you created a new submodel, both an indepent and dependent submodel, there is an additional .sash-file created. Is that really intentional, that the submodel should have their .sash-file (then possibly stored in a version control system)? 

When reintegrating a submodel, then the .sash-file is left, so I guess there is something not working as expected when it comes to this .sash-file being created for a submodel.
Comment 8 Christian Damus CLA 2016-08-25 09:21:37 EDT
(In reply to Peter Cigehn from comment #7)
> 
> One thing that I noted though was that when you created a new submodel, both
> an indepent and dependent submodel, there is an additional .sash-file
> created. Is that really intentional, that the submodel should have their
> .sash-file (then possibly stored in a version control system)? 

I didn't intend to change anything in the management of .sash resources, and I don't think anything would have changed unintentionally.  I thought it best that, as the Project Explorer requires the *.di resource, the corresponding workspace-private *.sash should also be maintained because it will be assumed by various code to exist, even if it isn't used (it is only used by a sub-model that can be opened).  And a sub-model can change modes (if it's a package) so there is usually a possibility of the *.sash being used.


> When reintegrating a submodel, then the .sash-file is left, so I guess there
> is something not working as expected when it comes to this .sash-file being
> created for a submodel.

This is a more general problem:  the *.sash resource is never deleted from the workspace metadata area when a model is deleted.  cf. bug 440443
Comment 9 Peter Cigehn CLA 2016-08-25 09:46:14 EDT
I think that we possibly are talking about different things. Normally the .sash-file is always located in the .metadata folder of the workspace, right?

But what I am talking about is that you now get a .sash-file located in the same location as the .di/.notation/.uml-files, and it gets grouped by the "one file". And when reintegrating the submodel, the .sash-file is left visible in your project (if it is left in the .metadata folder then I would not have seen this).

Is that what you mean also? Or are you referring to the fact that the .sash-file now should get located directly in your project (which will cause it to be stored in your version control system and shared with other users, which was one of the driving forces of placing the .sash-file in the .metadata-folder)?
Comment 10 Peter Cigehn CLA 2016-08-25 09:59:52 EDT
Also when you import a fragmented legacy model, the (dependent) submodels that you get do no get the .sash-file created at the same location as the .di/.notation/.uml-files, i.e. if you file the "one file" node open you do not see a sash-node below as you do for the case when you create a submodel using the menu choice "Create submodel".

So there is some difference in the location of the .sash-file also for the case of importing a fragmented legacy model vs. creating new submodels via the UI.
Comment 11 Christian Damus CLA 2016-08-25 10:08:17 EDT
(In reply to Peter Cigehn from comment #9)
> I think that we possibly are talking about different things. Normally the
> .sash-file is always located in the .metadata folder of the workspace, right?

Right.

> But what I am talking about is that you now get a .sash-file located in the
> same location as the .di/.notation/.uml-files, and it gets grouped by the
> "one file". And when reintegrating the submodel, the .sash-file is left
> visible in your project (if it is left in the .metadata folder then I would
> not have seen this).

Oh, I hadn't seen this during development of this feature, but now I do.  I shall check to see whether this is a new problem caused by this feature (nothing is changed in the management of *.sash resources, AFAIK).
Comment 12 Christian Damus CLA 2016-08-25 10:42:16 EDT
(In reply to Christian W. Damus from comment #11)
> 
> Oh, I hadn't seen this during development of this feature, but now I do.  I
> shall check to see whether this is a new problem caused by this feature
> (nothing is changed in the management of *.sash resources, AFAIK).

Indeed, this is caused by a flaw in the fix for bug 461709.
Comment 13 Peter Cigehn CLA 2016-08-26 04:36:27 EDT
I've tested this again, now when Bug 461709 is fixed again, and now it works without getting the .sash-file at the same location as the .di/.notation/.uml-files. When re-integrating a submodel you do not get at .sash-file hanging around in your project anymore.

I think that this looks good, and we can keep the existing terminology regarding submodel with the only distinction if they are independent or not.

I put this one into verified.