LCDproc development and user support list

Text archives Help


[lcdproc] Re: lcdproc, More questions, etc.


Chronological Thread 
  • From: natey AT hcis.net (Nathan Yawn)
  • Subject: [lcdproc] Re: lcdproc, More questions, etc.
  • Date: Sun, 17 Sep 2000 21:20:57 -0500

> Well actually menus could be defined in ways very similar to regular
> screens -- just provide menuing widgets. There's not too many different
> kinds of menu items, really:
>
> * Individual item (does something when selected)
> * Submenu (displays submenu's contents when selected)
> * Checkbox (turns something on or off when selected)
> * Toggle (turns something on or off when selected, label in menu
> toggles between two choices instead of a checkbox filling or
> emptying)
> * Value (increases or decreases, controls a value)
>
> So you could just send something like this to the server to define your
> menus (and let the server run it), or if a client really wants to it can
> "take over" a display to do its menuing. Really I think if we make the
> built-in menuing robust enough clients won't *need* to handle it.

Yes, I think that's the right idea, allowing for either the client or
the server to handle the client's messages. At startup, the client can
either register all its menu screens, or it can just say "When I get
menus, gimme all input and output control."

I can see advantages to doing it both ways, but I'm not sure either is
decisive. When the server handles the client's menus, there would be a
speed advantage...the only server<==>client communication would be when
the user actually selects an item requiring action. There would be a
lot more startup communication to register the menu screens with the
server, but in my book anything under 60 seconds is good for startup.
the disadvantage here is complexity (but not overwhelming).

The advantage of having clients handle all their own menu stuff is
simplicity, on both client and server side. On the server side, it
doesn't have to worry about menu widgets or screens or complicated
menu+widget related communication (Volume +1, etc). On the client side,
you also do away with the complicated network communication, the client
only has to look for 4 things (Yes/+, No/-, Menu, Select). The
disadvantage is the slowdown, the client has to send new display data
for every keypress.

So, each has its advantages and disadvantages...I think allowing both
methods might be best?

> There's some "priority" stuff to work out -- what if a high-priority
> screen is running and another client at normal priority wants to pop up
> a menu? I'm guessing it gets told where to stick it. :)

Sounds pretty reasonable to me...


Nathan Yawn
natey AT hcis.net


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT lists.omnipotent.net




Archive powered by MHonArc 2.6.18.

Top of page