93 lines
2.5 KiB
Plaintext
93 lines
2.5 KiB
Plaintext
LCDproc suggestion object hierarchy
|
|
|
|
Tdriver
|
|
TVirtualDriver
|
|
TMtxOrbDriver
|
|
TTextDriver
|
|
|
|
Tcomms
|
|
TSerial
|
|
TParallel
|
|
TSCSI
|
|
|
|
Tdisplay
|
|
Tclock_dsp
|
|
Tmail_dsp
|
|
Tcpustate_dsp
|
|
Tcpugraph_dsp
|
|
Tmeminf_dsp
|
|
Tuptime_dsp
|
|
Txload_dsp
|
|
Tcredits_dsp
|
|
Theartbeat_dsp
|
|
Tstub_dsp
|
|
Tusercfg_dsp
|
|
|
|
Tremote
|
|
Ttcpsockd
|
|
TUNIXsockd
|
|
|
|
Tchannel
|
|
Ttcpsocket
|
|
TUNIXsocket
|
|
|
|
Tconfig
|
|
|
|
Tfeedback
|
|
TMtxOrb_keypad
|
|
Tserial_buttons
|
|
|
|
Tschedular
|
|
|
|
---------------------------------------------------
|
|
|
|
Object brief descriptions
|
|
|
|
Tdriver (and decendants) provide manipulation of the physical
|
|
LCD panel including backlight, typeface loading, etc.
|
|
Tdriver will provide default methods for tasks such as
|
|
text centering
|
|
scrolling
|
|
screen clearing
|
|
etc
|
|
TVirtualDriver could act as a frame buffer / virtual display.
|
|
This would allow several display objects to access the (virtual)
|
|
display in a single cycle and then the virtual driver can flush
|
|
the changes from the last display (delta display) in a single pass.
|
|
This provides a portable way to implement display objects
|
|
(like the heartbeat which only changes one character at a time)
|
|
but overlap a standard full screen display
|
|
|
|
|
|
Tcomms (and decendants) transmit and receive all data to and
|
|
from the communications interfaces. Tdriver and Tfeedback will
|
|
use these objects directly.
|
|
|
|
Tdisplay (and decendants) generate the actual display information
|
|
by manipulating the Tdriver object which has been given to it.
|
|
The Tdriver object should usually be a TVirtualDriver descendant.
|
|
|
|
Tremote (and decendants) create, keep track of and ultimately destroy
|
|
Tchannel objects. Each Tchannel can potentitally be an external
|
|
connection to a remote client. The remote client can generate
|
|
either complete screens in a similar style to a Tdisplay object with
|
|
Tchannel using a Tstub_dsp to generate the screen based on info
|
|
supplied to it or it can feed data into an existing Tdisplay object
|
|
(Tchannel will do this by setting Tdisplay properties).
|
|
|
|
Tconfig is responsible for parsing the command line and reading/re-reading
|
|
the contents of a configuration file.
|
|
|
|
Tfeedback (and its descendants) may communicate with a Tcomms object to
|
|
retrieve information from a keypad or other input device.
|
|
|
|
Tschedular is responsible for the overall co-ordination of everything.
|
|
|
|
|
|
Other notes:
|
|
I can't decide things like "should scroll stuff be down to Tdriver
|
|
or Tdisplay?".
|
|
Some sort of Thash would be a useful way of passing data from
|
|
sockets to display objects as well
|
|
|