summaryrefslogtreecommitdiff
authormickeyl <mickeyl>2002-11-03 13:35:57 (UTC)
committer mickeyl <mickeyl>2002-11-03 13:35:57 (UTC)
commit3bc2ff91e60f23dd235599b3d83471bde8be1c8a (patch) (side-by-side diff)
tree9adf2c7c88228c78c2dc4c54f20986c56bfdb6c1
parent02d98447805cd4b413d4841eadb9ca14271cd015 (diff)
downloadopie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.zip
opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.gz
opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.bz2
Added a proposal for the daemon/gui communication.
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r--noncore/net/wellenreiter/docs/specification23
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
@@ -46,4 +46,8 @@ 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
@@ -59,5 +63,22 @@ 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.