[PD] new disis_wiimote : undefined symbol: sys_flushtogui

[Ivica Ico Bukvic]

> 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.