Hi Christian,
Thanks for the feedback!
I really like your proposal for the import. The question then becomes: how close are we to having this available. Papyrus-RT 1.0 will be available at the end of June and we need a good user experience at that point.
As for the Welcome page, that is the current plan.
Sincerely,
Hi, Charles,
See some replies in-line, below, on the technical questions. On 11 April, 2016 at 10:26:47, charles+zeligsoft.com (charles@xxxxxxxxxxxxx) wrote: ———— 8< ———— A question:
- Could this be handled through the installation process/tool? That his, having the default product includes the importer, but allowing knowledgeable be able to leave it optional? Can OOMPH provide this level of configurability?
The experience that I, as a user, would like for model interchange scenarios like this is automatic discovery of the required importer. Say I’m an RSA-RTE user and I have a workspace already that contains a bunch of models. When I open one of these models in Papyrus-RT, what I should see is that Papyrus-RT recognizes that there is content in this model (probably indicated by a foreign XML namespace declaration) that it doesn’t handle natively, but for which it has an importer that it can install via p2. The tool then prompts me to say something like “To edit this, it needs to be imported into the Papyrus-RT format. This requires additional software to be installed. Proceed?” and, on acceptance, the tool then automatically installs the import feature using the p2 APIs. This experience can be expanded to cover all of the import scenarios for other source tools as they are implemented over time. Oomph does something very like this in the setup authoring. The Setup Editor knows about tasks that can be added to a setup model, for which tasks the model definitions and tooling support are not currently installed. When you try to add one of these tasks to your setup model, the editor basically runs you through the scenario I described above. In any case, I think that maybe “import” oughtn't really be an explicit step that users should have to invoke to work with their RSA-RTE models. Double-clicking to open the model should just be redirected to the import wizard.
- Related to this, we need a “Getting Started” link on the “Welcome” window, and this topic must be in there. However, long-time users of Eclipse may just power through that screen...
Hardened Eclipsers probably do power through this screen, but we do notice when it pops up again in an installation that we’ve been using for some time, to highlight new features. Even if the Welcome view has been closed by the user, if an update installs a plug-in that adds new content to this screen, it will be shown when the workbench re-starts and actually highlights the new content with a yellow shadow thing. So, I think it definitely is worth adding Papyrus-RT getting-started material to this screen. You’ve already developed tutorials, Charles, that would lend themselves fairly readily to encoding in Eclipse UA’s tutorial format.
Hi,
Good questions. Regarding the builds I personally have no opinion about that, since I do not understand or have insight in the implications of the different choices.
When it comes to the features, I have actually been thinking about exactly the same.
I realized for example that I had missed the Papyrus_RT Core C++ Feature, which is not included in the top level Papyrus-RT Feature either. This makes perfect sense also, since the bringing in the specific language feature should be optional (depending on which languages we should have). We had a discussion in the mailing list a while ago, about exactly this, and I made a simple picture back then
<image.png>
I guess in the same way as we want to keep the C++ (or C or Java and so on) as optional features, we should also have the import tool a separate feature, not included in the top level Papyrus-RT Feature.
So I would propose to move the new import feature as separate feature as well. If you have the need to import old RSARTE models, then you need to check one additional feature (apart from the action/target language that you want to use).
/Peter Cigéhn _______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________papyrus-rt-dev mailing listpapyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|