LCDproc development and user support list

Text archives Help

[lcdproc] LCDproc++

Chronological Thread 
  • From: Scott Scriven <toykeeper AT> (Scott Scriven)
  • Subject: [lcdproc] LCDproc++
  • Date: Wed, 8 Mar 2000 15:21:57 -0700

* Mindaugas Idzelis
<mai3116 AT>
> My name is Min Idzelis, and I'm designing LCDproc++, which
> could very well be the successor of LCDproc. It is going to be
> completely rewritten in C++ and feature flexibility and
> portability. I am looking for suggestion, volounteers,
> stimulating discussion, etc. Currently, I am debating using
> CORBA as the protocol middleware. What does everyone think
> about this? I have design documents, and UML made up, and it
> will be posted on the sourceforge web soon. Let me know what
> you all think.

Here's my view on design for LCDproc++:

LCDproc has a lot of parts which need to be redesigned and
rewritten -- especially in LCDd. Since it needs so much
reworking anyway, I'm not opposed to restarting it from
"scratch" in C++. (many pieces would be significantly easier
in C++) I've been avoiding using C++ due to size, overhead, and
reduced portability, but sticking to regular C is probably just
getting in the way of development. It makes the code harder
for people to modify / enhance.

However, many of the old design goals still seem applicable.
For example, LCDd should use as little CPU time as possible.
On my machine, it never uses a complete timeslice, so the
kernel counts it as using "0.0%" of the CPU. I'd like to keep
it that way.

Also, it would be nice to keep the dependencies down to the
bare minimum. I don't really want it to use CORBA to
communicate when it can do just as well with internet sockets.

There is still a lot to design and implement in the server...
The network protocol, screen geometry, priority handling, user
menus, client menus, user input, frame rates, dynamic drivers,
custom characters, graphic displays, config files, network
security, etc..

Min, would you be willing to make LCDproc++ a branch of the
original LCDproc project, instead of being completely split? I
think there is a lot to be gained from writing it, but project
fragmentation is usually bad news.

We seem to have been lacking a good "leader" for months now, so
not much has been getting done. I've found I don't have enough
time for LCDproc during the school year, and it makes me feel
like a complete ass if I just let the project stagnate. So I'm
trying to find a way to keep LCDproc flowing, and LCDproc++
seems like it's a pretty good idea right now.

What does everyone else think? What should happen in the next

_ _ _ _ ___ ___ ---"I don't get even - I just get odder."---
( \/ ( \/ (__ (__ ) | 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