LCDproc development and user support list

Text archives Help


[Lcdproc] dbus interface to lcdproc


Chronological Thread 
  • From: lists at t3i.nl (theHog)
  • Subject: [Lcdproc] dbus interface to lcdproc
  • Date: Wed, 13 Oct 2010 21:27:04 +0200

Quoting Jannis Achstetter <kripton at kripserver.net>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 07.10.2010 17:33, schrieb Arne Zellentin:
>> Hi,
>>
>> has anybody ever devised a dbus interface to lcdproc? We have a customer
>> who
>> wants to send via dbus messages which get displayed on the lcd
>> until the user
>> presses a button to confirm the message. Other uses would include entry of
>> simple commands through the lcd's keys as well as date/time,
>> password or pin.
>> While there are no messages to display, lcdproc would be used to present
>> system information as it does now.
>
> Currently there is no dbus-support in lcdproc as Markus said. Of course
> support could be added to the lcdproc-daemon itself. Another way is to
> write a client for lcdproc that is also connected to dbus and reacts on
> dbus-messages, making lcdproc show them on the display. This way, dbus
> doesn't need to be in lcdproc's core.
> Please don't conclude that I don't want dbus in lcdproc - I would really
> like that but it should be done in a clean way with a specification and
> covering all of the features the TCP-connection has now. Doing this as
> "dirty hack for a custumer" might not have that much future.

Another consideration: dbus is not meant for extending interfaces, but
for providing services. If you write a client for lcdproc that
provides dbus services (like 'get pin', 'display this information',
'receive event x'), then your application could access those services
without bothering how to configure lcdproc screens and widgets. Other
apps can use those services too. One could even write a dbus service
provider that uses something else than lcdproc as user interface and
you application can use it without additional effort.

BW, is dbus still a desktop bus solution? I once looked at it and
decided to use ivybus instead (http://www2.tls.cena.fr/products/ivy)
since that one can be used over the network.

Richard.






Archive powered by MHonArc 2.6.18.

Top of page