LCDproc development and user support list

Text archives Help

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

Chronological Thread 
  • From: wwf AT (William W. Ferrell)
  • Subject: [lcdproc] Re: lcdproc, More questions, etc.
  • Date: Fri, 15 Sep 2000 08:00:56 -0600

* Nathan Yawn
(natey AT's
mailer blew these chunks:
> > --- NEXT IDEA :) ---
> >
> > *OR*, we could add a configuration directive to each driver instance:
> >
> > [driver]
> > driver = cfonts
> > display identifier = 1
> > ...
> >
> > *Then* we can guarantee a unique identifier (assuming the user is bright
> > enough to assign a *unique* identifier to each display ;)
> I think this wins, based on adherence to KISS...?

Hehehe cool :)

> > We could use integers (simpler) or use strings (harder to code but
> > easier on the user's brain) for the identifier string.
> I think strings would be straightforward to implemtnt, for significant
> gain (choosing a display by a descriptive name), but that's probably
> looking a ways down the road...ints would work fine for testing/beta.

Nah, beta isn't the time to add features :) We might as well use this
from the start.

> > Agreed; a scripted startup should be simple and easy, and everything
> > involved should have explicit configuration stuff, but we *need* to
> > provide some reasonable defaults too.
> I would think that anyone who just uses defaults isn't doing anything
> fancy (probably has a single display), and anyone who wants to do
> something fancy can RTFM. To determine a default, the server and client
> could have the verbose exchange of display parameters you described
> before, and the client could pick whichever (first, random, etc)
> matches. If it's not what the user wants, /then/ the user can read the
> docs.


> [Subject changes to nested menuing system here]
> > I *OFFICIALLY* like this idea a *lot*. I hadn't thought of this
> > combination -- I was worrying how to get the client's menus to the
> > server, and how to stop a client from "hogging" a display. If we do it
> > *this* way, the server can use its own timeout value, not even giving
> > the client a choice of whether to stop menuing or not when a user
> > doesn't touch anything for 30 seconds (or whatever)
> Sure, client menuing could end two ways: either the client tells the
> server "I'm done," or the server tells the client "'re
> done." I'm not sure how to get the menu screens to the server...I
> haven't really studied the protocol, I've been working on the driver
> side of things. I suppose this way, the server would know what was
> coming (client menu screens) and how to deal with them...

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
* 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.


> NEW MENU main_menu "XMMS Control"
< INFO: Menu created: main_menu "XMMS Control"
< INFO: Menu has no widgets, not displaying: main_menu
< INFO: Menu disabled: main_menu
> NEW MENU_WIDGET TOGGLE main_menu playbutton "Play" "Pause"
< INFO: Toggle created: main_menu playbutton "Play" "Pause"
< INFO: Menu has at least one widget. Enabling: main_menu
< INFO: Menu enabled: main_menu
> NEW MENU_WIDGET ITEM main_menu stop "Stop"
< INFO: Item defined: main_menu stop "Stop"
> NEW MENU_WIDGET VALUE main_menu Volume 0 100 0
< INFO: Value defined: main_menu Volume 0 100 0
> NEW MENU_DEFAULT main_menu playbutton
< INFO: Default defined: main_menu playbutton
> NEW MENU_WIDGET SUBMENU playlist "Playlist"
< INFO: Menu defined: playlist "Playlist"
< INFO: Menu has no widgets, not displaying: playlist
< INFO: Menu disabled: playlist
> NEW MENU_WIDGET ITEM playlist 1 "[Nine Inch Nails] The Fragile - Right
> (1999):
> Where is Every..."
< INFO: Item defined: playlist 1 "[Nine Inch Nails] The Fragile - Right
< (1999): Where is Every..."
< INFO: Menu 'playlist' has at least one widget. Enabling.
< INFO: Menu enabled: playlist

And so on. Then the client doesn't even have to worry in the slightest
about menu stuff until a user *does* something on it:

< INFO: Menu entered: main_menu
< INFO: Item selected: Play
< INFO: Value changed: Volume 1
< INFO: Value changed: Volume 2
< INFO: Value changed: Volume 100

(simulating a user hitting Play, then noticing the volume's at 0 for
reasons unknown, then scrolling up to 100)

< INFO: Toggle toggled: playstation "Pause"

(when a client wants to control/alter a menu itself)

> POPUP MENU main_menu
< INFO: Menu popped up: main_menu

(when a client wants to make its menu appear)

Does this sort of interaction seem reasonable? It seems a little
"verbose" but the menu creation stuff wouldn't happen more than a few
times in a client's life anyway.

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. :)

William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564

Public key available:
gpg --keyserver --recv-key 7478FC7A

Alimony is like buying oats for a dead horse.
-- Arthur Baer

Attachment: pgpewFI6k78cF.pgp
Description: PGP signature

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page