| 1 | LCDproc suggestion object hierarchy |
|---|
| 2 | |
|---|
| 3 | Tdriver |
|---|
| 4 | TVirtualDriver |
|---|
| 5 | TMtxOrbDriver |
|---|
| 6 | TTextDriver |
|---|
| 7 | |
|---|
| 8 | Tcomms |
|---|
| 9 | TSerial |
|---|
| 10 | TParallel |
|---|
| 11 | TSCSI |
|---|
| 12 | |
|---|
| 13 | Tdisplay |
|---|
| 14 | Tclock_dsp |
|---|
| 15 | Tmail_dsp |
|---|
| 16 | Tcpustate_dsp |
|---|
| 17 | Tcpugraph_dsp |
|---|
| 18 | Tmeminf_dsp |
|---|
| 19 | Tuptime_dsp |
|---|
| 20 | Txload_dsp |
|---|
| 21 | Tcredits_dsp |
|---|
| 22 | Theartbeat_dsp |
|---|
| 23 | Tstub_dsp |
|---|
| 24 | Tusercfg_dsp |
|---|
| 25 | |
|---|
| 26 | Tremote |
|---|
| 27 | Ttcpsockd |
|---|
| 28 | TUNIXsockd |
|---|
| 29 | |
|---|
| 30 | Tchannel |
|---|
| 31 | Ttcpsocket |
|---|
| 32 | TUNIXsocket |
|---|
| 33 | |
|---|
| 34 | Tconfig |
|---|
| 35 | |
|---|
| 36 | Tfeedback |
|---|
| 37 | TMtxOrb_keypad |
|---|
| 38 | Tserial_buttons |
|---|
| 39 | |
|---|
| 40 | Tschedular |
|---|
| 41 | |
|---|
| 42 | --------------------------------------------------- |
|---|
| 43 | |
|---|
| 44 | Object brief descriptions |
|---|
| 45 | |
|---|
| 46 | Tdriver (and decendants) provide manipulation of the physical |
|---|
| 47 | LCD panel including backlight, typeface loading, etc. |
|---|
| 48 | Tdriver will provide default methods for tasks such as |
|---|
| 49 | text centering |
|---|
| 50 | scrolling |
|---|
| 51 | screen clearing |
|---|
| 52 | etc |
|---|
| 53 | TVirtualDriver could act as a frame buffer / virtual display. |
|---|
| 54 | This would allow several display objects to access the (virtual) |
|---|
| 55 | display in a single cycle and then the virtual driver can flush |
|---|
| 56 | the changes from the last display (delta display) in a single pass. |
|---|
| 57 | This provides a portable way to implement display objects |
|---|
| 58 | (like the heartbeat which only changes one character at a time) |
|---|
| 59 | but overlap a standard full screen display |
|---|
| 60 | |
|---|
| 61 | |
|---|
| 62 | Tcomms (and decendants) transmit and receive all data to and |
|---|
| 63 | from the communications interfaces. Tdriver and Tfeedback will |
|---|
| 64 | use these objects directly. |
|---|
| 65 | |
|---|
| 66 | Tdisplay (and decendants) generate the actual display information |
|---|
| 67 | by manipulating the Tdriver object which has been given to it. |
|---|
| 68 | The Tdriver object should usually be a TVirtualDriver descendant. |
|---|
| 69 | |
|---|
| 70 | Tremote (and decendants) create, keep track of and ultimately destroy |
|---|
| 71 | Tchannel objects. Each Tchannel can potentitally be an external |
|---|
| 72 | connection to a remote client. The remote client can generate |
|---|
| 73 | either complete screens in a similar style to a Tdisplay object with |
|---|
| 74 | Tchannel using a Tstub_dsp to generate the screen based on info |
|---|
| 75 | supplied to it or it can feed data into an existing Tdisplay object |
|---|
| 76 | (Tchannel will do this by setting Tdisplay properties). |
|---|
| 77 | |
|---|
| 78 | Tconfig is responsible for parsing the command line and reading/re-reading |
|---|
| 79 | the contents of a configuration file. |
|---|
| 80 | |
|---|
| 81 | Tfeedback (and its descendants) may communicate with a Tcomms object to |
|---|
| 82 | retrieve information from a keypad or other input device. |
|---|
| 83 | |
|---|
| 84 | Tschedular is responsible for the overall co-ordination of everything. |
|---|
| 85 | |
|---|
| 86 | |
|---|
| 87 | Other notes: |
|---|
| 88 | I can't decide things like "should scroll stuff be down to Tdriver |
|---|
| 89 | or Tdisplay?". |
|---|
| 90 | Some sort of Thash would be a useful way of passing data from |
|---|
| 91 | sockets to display objects as well |
|---|
| 92 | |
|---|
