LCDproc development and user support list

Text archives Help

[Lcdproc] New perl package and client

Chronological Thread 
  • From: wayne AT (Wayne Wylupski)
  • Subject: [Lcdproc] New perl package and client
  • Date: Tue Sep 17 16:53:01 2002

> I guess you have read the message from "Yiorgis Gozadinos",
> he was talking about a Perl wrapper for LCDproc, maybe he did not knew
> your project,
> maybe there is something you could reuse in what he did???

I did read his post; he wrote a C++ wrapper, if I'm not mistaken.

> I would like to know if your new version is API compatible with the
> version...
> I don't know much of Perl so you will have to explain slowly.
> But Does a client writen using the previous library work with your new
> library?

There is one change that would have to be made to existing programs: calls
to create
a "Widget" have to create the actual type of widget. So where you had:
Widget::new( type=>"String", ....)
you would now have to write:
String::new( .... )
It's more object-oriented in that String. Title, VBar are child classes of

This should be in the CHANGES (I'll look to be sure).

> Did you test other Perl client writen with the old now using the new?

I actually am not familiar with what other Perl clients use this package.
I'd be happy to try it if
someone can tell me which.

> Do you know about the small problem we had with our standalone perl client
> (not using
> the library) when they were not reading for the socket (or something
> similar)?

Yes, and that's what actually prompted me to make the "big" change. I've
added a routine,
Pump() whose purpose is to read messages. It's the main event loop of the
program. I'm strongly
encouraging that people use it, althought you don't have to. The benefit of
this is that the user
(writer of the client) can set up callback functions so if specific messages
come from the server,
the callbacks are invoked. The client should not have to worry about the
protocol anymore.
(I was inspired by Perl/Tk).

To illustrate, when you create an LCD object, you can specify a handler for
"bye" messages:
$lcd = LCDd::new( ..., -onBye=> \&myBye );

sub myBye { exit(0);} # will be called when LCDd shuts down

Similarly things happen with "listen", "ignore", "key" and the like.

I have included a couple of other routines which people can use to write
their own event
loop, if need be. I haven't tested this aspect of it, though, and would be
willing to hear of success or
failures with it.

This feature should alleviate the problem of the queued-up text from the

> Could you write a "demo" client that does not need external hardware (UPS)
> to be tested
> and learned from?

Yes, great idea -- I'll write that display program somepone earlier wanted,
a la : echo "foo" | lcdwrite
I'll post it tonight.

> Thanks anyway for whatever you already have done for LCDproc.

My pleasure; I'm looking forward to hearing people's opinions.


Archive powered by MHonArc 2.6.18.

Top of page