From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: callback functions in Emacs Date: Wed, 05 Sep 2007 10:43:43 +0200 Message-ID: References: <87642qmb0g.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1188981833 27265 80.91.229.12 (5 Sep 2007 08:43:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2007 08:43:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 05 10:43:52 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ISqUI-0003wN-MG for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2007 10:43:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISqUG-0001Qo-S9 for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2007 04:43:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ISqU6-0001Fw-Ct for emacs-devel@gnu.org; Wed, 05 Sep 2007 04:43:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ISqU5-0001E3-Hg for emacs-devel@gnu.org; Wed, 05 Sep 2007 04:43:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ISqU5-0001Dl-Dl for emacs-devel@gnu.org; Wed, 05 Sep 2007 04:43:37 -0400 Original-Received: from mailrelay2.alcatel.de ([194.113.59.96]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ISqTz-0004jq-Fj; Wed, 05 Sep 2007 04:43:32 -0400 Original-Received: from slbhab.alcatel.de (slbhab.bln.sel.alcatel.de [149.204.63.218]) by mailrelay2.alcatel.de (8.13.4/8.13.4/ICT) with ESMTP id l858hPKO025997; Wed, 5 Sep 2007 10:43:26 +0200 In-Reply-To: (Richard Stallman's message of "Wed, 05 Sep 2007 02:16:29 -0400") User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (hpux) X-Scanned-By: MIMEDefang 2.51 on 149.204.45.73 X-Detected-Kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:77839 Archived-At: Richard Stallman writes: > I'm playing a little bit with integration of D-Bus(*) into Emacs. > > It isn't feasible for me to browse a web site--what is D-Bus? Why do > we want to control it from Emacs, and do it by adding C code? Quoting from the introduction on dbus.freedesktop.org: --- D-Bus is an inter-process communication mechanism--a medium for local communication between processes running on the same host. (Inter-host connects may be added in the future, but that is not what D-Bus is meant for). D-Bus is meant to be fast and lightweight, and is designed for use as a unified middleware layer underneath the main free desktop environments. Unlike more heavyweight conventional messaging middleware, D-Bus is non-transactional. It is stateful and connection-based, however, making it "smarter" than low-level message-passing protocols such as UDP. On the other hand, it does carry messages as discrete items--not continuous streams of data as is the case with TCP. Both one-to-one messaging and publish/subscribe communication are supported. D-Bus has a structured view of the data it carries, and deals with data in binary form: integral numbers of various widths, floating-point numbers, strings, compound types, and so on. Because data is not just "raw bytes" to D-Bus, messages can be validated and ill-formed messages rejected. In technical terms, D-Bus behaves as an RPC mechanism and provides its own marshaling. There are two major components to D-Bus: a point-to-point communication dbus library, which in theory could be used by any two processes in order to exchange messages among themselves; and a dbus daemon. The daemon runs an actual bus, a kind of "street" that messages are transported over, and to which any number of processes may be connected at any given time. Those processes connect to the daemon using the library, and it probably wouldn't make much sense to use the library for anything else. We'll be looking mostly at the situation where applications (or more generally, clients) connect to a full-blown bus. Multiple buses may be active simultaneously on a single system. D-Bus was first built to replace the CORBA-like component model underlying the GNOME desktop environment. Similar to DCOP (which is used by KDE), D-Bus is set to become a standard component of the major free desktop environments for GNU/Linux and other platforms. A GNOME environment normally runs two kinds of buses: a single system bus for miscellaneous system-wide communication, e.g. notifications when a new piece of hardware is hooked up; and a session bus used by a single user's ongoing GNOME session. A session bus normally carries traffic under only a single user identity, but D-Bus is aware of user identities and does support flexible authentication mechanisms and access controls. The system bus may see traffic from and to any number of user identities. --- If you run GNU/Linux (what I guess), you can see D-Bus messages by calling "dbus-monitor --session" or "dbus-monitor --system" from a shell (the latter one only if you're running Gnome or KDE). dbus-monitor is contained in the Debian package dbus-1-utils, for example. Linux' HAL and HotPlug are implemented on top of the D-Bus system bus, as interface org.freedesktop.Hal . For Emacs, the D-Bus session bus is more appropriate. Very rough examples how Emacs could use D-Bus: - Work as server. Register in the D-Bus session bus an interface org.gnu.emacs (which is derived from default interfaces org.freedesktop.TextEditor and org.freedesktop.FileHandler). The implementation is parallel to the emacs server, but would react on D-Bus messages towards such an interface instead of emacsclient events. This would allow applications to contact Emacs directly, without even knowing that Emacs is the text editor to be called. - Work as client. Communicate with the registered interface org.gnome.Keyring in order to retrieve passwords and keys from this data store on a reliable way. - React on bus signals. Register for the session bus interface org.gnome.ScreenSaver. The signal SessionPowerManagementIdleChanged toggles between true and false; depending on that signal there could be an extension of run-with-idle-timer. It wouldn't check only for user input, but runs when the session is really idle. A lot of other use cases are possible, this shall show you just the possibilities. Given, that D-Bus is used by Gnome and KDE, I believe Emacs would benefit from being plugged in into D-Bus. > One of the basic concepts od D-Bus is, that one could register a > callback function which is applied when there bis a signal on the bus > one has registered for. > > By "signal" do you mean the C-level signals that are handled > by `sigaction'? No. It is a special D-Bus message one can register for. > But that looks ugly to me. Isn't there another, more simple way to > evaluate Lisp code from inside a callback function? > > What do you mean by "a callback function"? That is not an Emacs > concept, so it doesn't specify the most relevant facts. What exactly > is going to call this function, when? There are two cases a callback function is used. You can offer an interface to the session bus, and register a service in the session bus which implements this interface. "Registering" means that you must specify a C function which is called when another application sends a message to this service. Let's say you implement a C function "open_file", and register it in the session bus as method "OpenFile" of interface "org.freedesktop.TextEditor". Another application, which wants to open a file, sends a message to that method, and Emacs opens the file. The file name to be opened is passed inside the message. Because the other application sends the message to the standard interface, it doesn't need to care _which_ editor will do the job. The other case is when you register for a dbus signal. A signal can be regarded as a multicast message send from an application to the session bus. Emacs could register the C function "idle_changed" to the signal "SessionPowerManagementIdleChanged" of interface "org.gnome.ScreenSaver". Whenever the Gnome screen saver changes its status, it sends the dbus signal (multicast message) "SessionPowerManagementIdleChanged" with the parameter true or false, and every registered function, including our "idle_changed", is called. > If you're talking about C-level signal handlers, the usual way for > them to run Lisp code is by queuing input events. That's the way I will go. Thanks to everybody who gave me information, and best regards, Michael.