| author | mickeyl <mickeyl> | 2002-11-03 13:35:57 (UTC) |
|---|---|---|
| committer | mickeyl <mickeyl> | 2002-11-03 13:35:57 (UTC) |
| commit | 3bc2ff91e60f23dd235599b3d83471bde8be1c8a (patch) (side-by-side diff) | |
| tree | 9adf2c7c88228c78c2dc4c54f20986c56bfdb6c1 /noncore | |
| parent | 02d98447805cd4b413d4841eadb9ca14271cd015 (diff) | |
| download | opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.zip opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.gz opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.bz2 | |
Added a proposal for the daemon/gui communication.
| -rw-r--r-- | noncore/net/wellenreiter/docs/specification | 23 |
1 files changed, 22 insertions, 1 deletions
diff --git a/noncore/net/wellenreiter/docs/specification b/noncore/net/wellenreiter/docs/specification index d833451..0766ef4 100644 --- a/noncore/net/wellenreiter/docs/specification +++ b/noncore/net/wellenreiter/docs/specification @@ -44,8 +44,12 @@ startup and sends the informations to the GUI. The GUI contains an option daemon which actually changes the configuration file. The configuration file is placed in /usr/local/etc/wellenreiter.conf. The whole content of this file cannot be specified yet. +OPIE specific: Opie contains a bunch of high-level configuration classes, +which are used by most Opie applications. It should be discussed whether +to use this structure / API (preferred) or use a proprietary one. + -[ Interaction GUI<->daemon The GUI and the daemon will talk actively with eachother, meaning that @@ -57,9 +61,26 @@ it will be directly send to the GUI to be able to sniff in realtime. -[ Communication GUI<->daemon -Not yet specified. +The GUI and the daemon run as threads within one process, where the GUI +thread will be the main thread. Both the daemon and the GUI thread are +(mostly) "free-running". Once the GUI thread is started and has finished +its initializations, it jumps into the Qt event loop ( QApplication::exec() ). + +If the daemon thread is actively working and - +for instance - has acquired interesting data for the GUI thread to display, +it calls a special reentrant method of the GUI thread ( QApplication::postEvent ) +either transmitting the whole data structure or saying "Hey, there's interesting data +for you", which the GUI thread then retrieves. +To enable a free running daemon thread to actually receive messages from the +GUI thread, it's useful to to include a non-blocking check-for-messages-function +within the daemon main loop <since it is waiting for messages from a GUI thread, +this function has not be called very often>. If applicable, the daemon thread must +not call this function but only monitor some guarded variables from time to time +which the GUI thread can modify to alter the behaviour of the daemon thread. + +IMHO this is a much more leightweight design than to use a proprietary udp-socket protocol. -[ Setting card modes |