Hi, Charles,
I don’t know how close we are. With the Papyrus Components Discovery component, we already have some of the necessary infrastructure in place for automatic p2 installs. I don’t expect that it should be difficult to reuse/refactor this. Although, refactoring for reusability outside of Papyrus could be an issue given that Papyrus Neon has now past its API Freeze.
The more interesting question is intercepting the “open” action on RSA-RTE models. Happily, they already are easily recognizable (emx file extension, numerous XML namespaces). I can think of a few different ways to approach this, with Eclipse’s retargetable open action, Common Navigator’s open and double-click extensions, and even a clunky custom editor that just launches the import (and/or discovery) wizard. It would need a bit of investigation to scope this out.
cW
On 11 April, 2016 at 10:52:25, charles+zeligsoft.com (charles@xxxxxxxxxxxxx) wrote:
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@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 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 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 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
|
