Repository navigation
Backend Frontend Interface Review #42
Description
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:
-
LogicItem.__init__(self, data):constructur should take meta-data dict, nothing else. -
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:
-
ItemRegistry.get_all_guids(guid):a function that returns all available guids from the backend. -
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.
Metadata
Metadata
Assignees
Labels
No labels
Activity
hacst commentedon Dec 28, 2014
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 commentedon Dec 28, 2014
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.Implement part of the changes agreed upon in review #42
hacst commentedon Dec 28, 2014
@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 commentedon Dec 28, 2014
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:
Open questions from my side:
hacst commentedon Dec 28, 2014
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 commentedon Dec 29, 2014
@hacst In order to implement
GridScene.on_new_instance(self, data)andGridScene.on_delete_instance(self, data)I need a way to trigger such updates from the backend. What would be the best way?hacst commentedon Dec 29, 2014
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?