Why do you think that this can only be done by exposing sys_flushtogui()? My guess is that this can be done using the current public API, but I'd to
know
more about the issue to make a concrete suggestion.
Indeed... To make any suggestions, like the one below, you would need to look at the external's behavior. In this case, connection is handled in the same thread as pd which means the thread freezes until wiimote connects. Because connection happens immediately after requesting the posting of a message "please press 1+2 buttons on a wiimote to connect" (which I would argue is rather important bit of information for a user), the message never reaches the gui because the thread freezes waiting on the Bluetooth stack to report that the connection has succeeded/failed. Flushtogui placed in between the post() call and the connect() call allows for the said message to be indeed displayed before the pairing takes place. If you can think of a better way to do this I'd certainly appreciate suggestions.
As for bidirectionality of communication, this has nothing to do with examples listed below. Rather, on lower-powered cpus (e.g. Atom netbooks) request to enable rumble on a wiimote most of the times results in an xrun. disis_wiimote handles this and other thread-unsafe actions in a separate thread so that one can send as many rumble/led/etc. requests back to wiimote without that having to result in an xrun.
There are a number of objects that handle bidirectional communication with hardware and they don't need sys_flushtogui(). [comport] and [hidio] come to mind. Then there are the network objects, which also handle
bidirectional
communication.