Deserializing Hopper example fails

[aymanhab]

This happened while trying to test a build of the GUI but can be reproduced on the API side by writing the hopper with device model to a file then reading it back. The deserialization fails with message is not a recognized/registered object type and the device ends up lost on deserialization.

[chrisdembia]

Some of this is a bug (input connectee names do not yet serialize), but some of it is not a bug; one cannot expect to load a model into the GUI if it doesn't know about the objects it uses. We could create a plugin containing the new Object types used in the example.

[aymanhab]

I think Device is a bogus abstraction, it is just a Container or Model or Submodel. I don't think "Device" type needs registration altogether as far as I can tell but I'm open to counter arguments.

[chrisdembia]

I don't think "Device" type needs registration altogether as far as I can tell but I'm open to counter arguments.

I agree.

[chrisdembia]

The example still uses "SignalGenerator"

[aseth1]

An "advanced" part of the example could be to create a plugin that includes and registers the Device and the SignalGenerator. That avoids the issue of nested models altogether and shows the user how to get their custom components loaded in the GUI. Since the objective of this example is to highlight how to create new (custom) Components and hook them up then adding the plugin is the next logical extension since users are likely to want to open Models with their custom components in the GUI.

@aymanhab @chrisdembia @tkuchida what do you think?

[chrisdembia]

If creating a plugin can be done in a way that does not make this example confusing/convoluted, then I think that could be good. I think it is also fine for this to be an API-only example. There could be other examples that are not intended to be didactic and thus could be more complicated and include building a plugin.

[tkuchida]

Perhaps we can just provide the code that creates plugins from the "teacher" versions of the hopper example? Then, in a workshop, the "students" would be able to build the plugins and see the model in the GUI even if they were unable to complete the other tasks. :rabbit:

[chrisdembia]

@tkuchida I like that idea, though it is potentially confusing if the teacher version puts those classes in a plugin (library) while the student version does not.

[aymanhab]

In my mind, examples should be simple to follow and modify. Plugins is an artifact of our type registration/serialization that would pollute the simple mental picture. It'd be good if "advanced" denotes advanced functionality to the user.

I'd lean toward making a shell class called Device (if we're not going to introduce a general container) and have the whole registration idea hidden from the example. Do you think that would be possible?

If Device is too generic we can use HopperDevice or something more specific to avoid polluting the namespace, though it may come in handy in our testing to change what a Device really means (it's just a Component/Container).

[chrisdembia]

Are you suggesting putting HopperDevice into the OpenSim libraries (e.g., Tools or Simulation)? I don't think that is a good idea.

[aymanhab]

It can be its own library (e.g. experimental, or future), the issue is more of hiding the plugin stuff from users, if this's their first encounter with the OpenSim API.

[aseth1]

What about SignalGenerator? While I agree that the example should be simple, I would also be frustrated to learn that my Components (that are now easy to create and even display in the Visualizer) cannot be loaded into the GUI. I rather see the actual way of doing it (artifact or not) so I can load my models with my components in the GUI. The solution perhaps is to have an additional part or separate tutorial (e.g. How to make your custom Components loadable in the OpenSim GUI) that demonstrate how to do it using the hopper's components as its starting point.

[aymanhab]

I'd add that we should also consider whether we should try to include some incarnation of this example in Python or Java/Matlab (where Extension has not been tested), or have a different example that just assembles pre-existing Components

[chrisdembia]

Part of this example is teaching people how to create their own inputs/outputs, which means creating their own component.