Backend Frontend Interface Review

[christianbrugger]

This is based on the review with @hacst on the phone.

Our goal is to keep the backend frontend interface as simple as possible, with the following design rationals:

• new functionality in the frontend or backend should not result in the creation of new frontend / backend interface methods.
• the number of interface methods should be kept to a minimum.
• all partners in the frontend backend interface should know as little about the events they are handling as possible, best everything should be treated equally.

  GUI class changes:

We only introduce the following functions:

• [x] LogicItem.__init__(self, data): constructur should take meta-data dict, nothing else.
• [x] LogicItem.update(self, data): data being the meta-data dict. This update handles position changes, new connections, disconnects, logic-state changes, etc. The function itself it called by the registry, that listens on updates from the backend and distributes them.
• [ ] GridScene.on_new_instance(self, data): slot handling the creation of new instances listening on the registry signal instantiated.
• [ ] GridScene.on_delete_instance(self, data): slot handling the deletion of instances listening on the registry signal deleted.

  New registry functions:

• [x] ItemRegistry.get_all_guids(guid): a function that returns all available guids from the backend.
• [x] ItemRegistry.instanciate_element(self, guid): returns an instance of LogicItem that is not part of any scene and without any backend element. It is a fully functioning LogicItem (QGraphicsItem) initialized with the default meta-data, that can be added to scenes temporarily or persistently. It might already contain a 64-bit random id to allow later communication with the backend. If an item is added to a scene (or changes from temporary to non-temporary) it by itself (in LogicItem.itemChange) tells the backend that it now should be instanciated also in the backend.

(the names are not completely fixed)

Open questions from my side:

• From my side it makes sense to treat logic-items and line-trees in the same way. If yes, we should create a common base type for both elements and implement the update function in that one.

[hacst]

About your question: That matches the design in the backend. The corresponding element would be the Interconnect (we should rename one of them to match the other). Will need some more thought though. Currently connections aren't part of the meta-data for elements and are created/dissolved with separate methods all elements have in common. Hence they don't have a notion of delay which we want for interconnect connections. Not a big issue but something that will need some more thought.

[hacst]

About ItemRegistry.instanciate_element(self, guid):: Having though about it some more instantiating front-end elements without backend backing will create quite a few issues for us down the road. Not only must we now add fallbacks for all missing metadata fields that are only available from the backend (e.g input states), we also can't really have any important parts of the visuals (e.g. label, colors etc.) depend on backend instance behavior. All must be hard-coded into the type metadata or into the front-end element. I do realize instantiating them without backend backing makes the palette easier and reliefs some of the asynchronous communication issues but it won't be a free lunch.

[hacst]

@chris- Please review my changes and see if they fit what you had in mind. I didn't make any modifications to the scene as I think might already have an idea on where you want to take that and I didn't want us to collide there.

[christianbrugger]

Thanks for raising this issue, I was not aware of this implication. I also don't like duplicate information in the backend logic and metadata definition, also fallbacks are a mess (tedious to test).

Here is an alternative:

• All items instances will create a backend instance, once they are connected to a scene. [and destroy them on disconnect]
• Scenes can be explicitly switched off. [The palette will be in this mode showing the available items (also without mouse interactions, as it is now). Since the backend does not check the position, it should not make a problem to have unconnected items anywhere on the scene.]
• As far as I see UndoRedo can stay the same. (as the items are not part of a scene).
• Also item instantiation can be implemented as described above. [as long as the components are not part of a scene it should not matter if meta data is missing. However their might be a small delay until all data is there, once the item is added to the scene, but as far as I see their is no way around this and it should not be noticeable.]

Open questions from my side:

• The palette having its own scene, should it also get its own backend?
• Will backends define their own items that are not shared among all backends (image having two circuits open with different compound elements, do we even plan for having that, or multiple backends opened in parallel in general?). Will their be a common knowledge about elements among all backends? The later part would simplify the palette design. (Further down the road we could introduce component groups in the palette based on some GUID + description, ...).

[hacst]

Instantiating the elements in the backend should be fine but might make us do things like accidentally save them with the rest of the simulation if we aren't careful.

Architecturally it would make sense to completely separate the backends. If we want the core to use a multiprocessing.Process later on we'll have no choice but to separate them out and as far as objects go they won't share anything. As you described this isn't exactly ideal when it comes to keeping the component libraries synchronized though.

Having the palette use a active backend would enable some other cool things like being able to interact with or demo the element in a catalogue like display or even display a sample circuit using it in there. Making it use the same backend as the simulation would be fine interaction wise however but it would be affected by things like simulation rate or say the simulation being paused.

I would suggest spinning up another backend for the palette/catalogue. We can think about how to solve the potential desync issues later on. Imho having a simple way of spinning up as many backends as we want while having them use the same types is something we will want anyways.

[christianbrugger]

@hacst In order to implement GridScene.on_new_instance(self, data) and GridScene.on_delete_instance(self, data) I need a way to trigger such updates from the backend. What would be the best way?

[hacst]

There are already signals for that on the registry. Just create the two slots on the scene and connect them. Or do you mean something else?