GUI for larger application with AF

[JonasCJ]

Hi all

Since I found the AF I've done a few small examples where I have a few "backend" actors and a single event based GUI actor. The GUI actor will send messages to the backend saying "a and b is available, do addition" and after completing some operation (e.g. addition of two numbers) the backend will send a message back to the GUI saying "operation complete, result c available, display it" (a, b and c are global variables). So no data transfer using the messages, only messages saying data is available at some shared location. I think this design pattern (if I add a controller actor between the GUI and the backend so GUI and backend does not communicate directly) will do well for larger applications as well.

But how about larger and more complex GUIs? My small exampels have just been one GUI actor and the frontpanel the user saw was just the front panel of the GUI actor's actor core.

What do I do when I need the user to percieve one single window ("the application") and within that window maybe multiple tabs which each reveals very different UIs? One tab shows the setup of a DAQ-device (choose channels, sample rate etc), another shows data from the DAQ device, a third shows some analysis of those data (e.g. FFTs).

Could I make one GUI actor which would be responsible for the overall look of the application (e.g. the tabs, top menu bars etc.) and then within that launch other GUI actors depending on which tab the user has selected? E.g. if the user selects the "Raw Data"-tab I would launch the "Raw Data GUI"-actor and embed it in a subpanel or the like?

Any comments on my above questions/suggestions, other direct advice regarding larger GUIs and links/references to other material will be very welcome.

Thanks

JonasCJ

[fabric]

One of the best ways to implement multiple tabs is using a subpanel control. In the context of AF, your main GUI would be the parent actor and each subpanel GUI would be a callee actor. There was some discussion about subpanels here and here.

Note: You may find that there is quite a bit of messaging/framework overhead in implementing a multi-actor GUI... but it does encourage good encapsulation and division of responsibilities. I would definitely give it a go just for the learning experience 🙂

[AristosQueue (NI)]

I agree with fabric. Subpanels. There are also some games you can play with XControls -- write an XControl that launches an actor as part of its "start running" method and gives that Actor some events to which the XControl will respond -- but those appear (don't know anyone who has tried to use this approach systemically) to be good only for some limited situations. Subpanel I think gives you far more control with less messaging. Again -- the XControl approach is viable, but I don't know anyone who has explored how viable. You'd be treading new ground.