LCDproc development and user support list

Text archives Help

[lcdproc] LCDd suggestions

Chronological Thread 
  • From: Scott Scriven <toykeeper AT> (Scott Scriven)
  • Subject: [lcdproc] LCDd suggestions
  • Date: Fri, 22 Oct 1999 18:13:54 -0600 (MDT)

On Fri, 22 Oct 1999, Thomas Runge wrote:

> - tell lcdproc the position and size of the widget at _creation_time_,
> not when updating.
> -> I only have to update the value, not the positon, very handy IMO.

This is already taken care of in the new design. All commands
will take a similar form as command-line arguments, so instead
of this:
widget_set myscreen mywidget value1 value2 value3
It will look more like this:
widget_set myscreen mywidget -x 3 -y 7 -text "Foo!"
And that gives you the option of doing this:
widget_set myscreen mywidget -text "Foo!"

Sound good?

> - make LCDd a real daemon, so that we can start it at boot time and
> it will stay forever.

Eh, it is. There are still problems with it (can't change
drivers after startup), but those will be fixed by a planned
feature, which is what your next suggestion is about:

> - add some kind of admin mode. That means a special client can change
> global attribs like background light, contrast, brightness, the
> priority of certain clients etc. That even means it should be
> possible to request the actual state as well.
> -> imagine a nice windowmaker dock app for that ;)

Before adding this, it would probably be good to fix up the
protocol and add security. Even if it's a simple username /
password authentication, there should be *something* which
controls access to LCDd.

# Connect to LCDd
<= hello
# Request permissions
<= auth -pw my_name my_password
# Password checked out...
=> auth ok
# What functions do we have access to?
=> feature display
=> feature admin

Having a config file would really help here, too...

> I don't think, we need a threaded LCDd. Checking 8 times a second ...

The frame rate will eventually be adjustable. I should
probably make the server's input buffer size adjustable, too.
(It disconnects from clients who "talk too much"; it's kinda
funny to see it say "huh? Shut up!", though...)

> XML based protocol?!? NO, PLEASE! :-) Don't make client's programmers
> live more painful! ;-)

I don't really want to do it either. :)
It may be a well-used standard soon, though. So, I expect
we'll be seeing easy-to-use XML libraries which let you
configure programs through a central repository of XML files...
It also may become a sizable competitor to CORBA.

> CORBA? Sounds good. I like CORBA very much. But remember, that it
> blows your code by about 1 MB. And every client blows.

Heh. Yeah. Small size and few dependencies have been two of
the design goals I've been keeping in mind.. :)

> Well, if you need a helping hand, just split the project into small
> pieces and announce it on your webpage. I'll help you as well, but
> the LCD is just a toy for me and there are more important projects
> in my todo list...

Yes, I've tried (as much as I know how) to make the code depend
on "plug-in" modules or functions, so that it is easy to add
new features within the existing framework. Maybe I should
explicitly list the sections which should (hint, hint) be
expanded in this way...


_ _ _ _ ___ ___ ------------"Use the source, Luke!"---------
( \/ ( \/ (__ (__ ) | Scott Scriven (Toy Keeper / XYZZ) |
\ / \ / // // |
mailto:toykeeper AT
/ \ / / //_ //_ | |
(_/\_(_/ (___(___) | |

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page