[lcdproc] My patchs at last

[Glen Gray]

With all the talk of the API changes I realised that nobody responded to
this response of mine.

Whats the deal, do I make any changes, are the patchs to be included as
is ?

In the mood for over working and hacking late :-)
Glen

On 11 Jun 2001 09:57:58 +0100, Glen Gray wrote:
> On 08 Jun 2001 13:13:09 -0700, Philip Pokorny wrote:
> > So you got some timeout to do some timeout code...  Was that pun
> > intended? [grin]
> >
> Ha ha, very funny. No it wasn't intended but well spotted :-D
>  
> > If you've got CVS, you can use 'cvs diff' to diff your local changes
> > against the CVS tree.  That would probably be easier than keeping two
> > copies of the sources. (unless you don't have much bandwidth for the
> > compare...)
> > 
> Oh plenty of bandwidth, just new to the procedures, I'll give that a go
> today.
> 
> > >         screen_set #id [-]backlight <on|off|toggle|flash|blink>
> > 
> > Isn't there already a backlight command, that affects the global
> > backlight state?  
> Yep, it's still there though..in client_functions.c IIRC.
> 
> > In looking at your patch, it looks like you've
> > replaced the global backlight state with a per screen backlight state.
> Not replaced as such, the other code is still there, but in the current
> implementation of my patch effectively renders it pointless.
>  
> > I like the addition of a per-screen backlight state so that the server
> > can make sure to set the backlight to the appropriate state for a given
> > screen automatically, but it looks like you've disabled the global
> > backlight state.  Have I missed something?  If not, what do you think
> > about having a "default" per-screen backlight state that says "no
> > preference" and in that case, the server uses the current global
> > backlight state.  Also, if the server is started with the backlight in
> > the "locked" state, then that should override the per-screen backlight
> > settings just like it does the "backlight" protocol command.
> > 
> That would be fairly simple to do, off the top of my head we have two
> options on how to approach this.
> a) I could initialize the s->backlight field based on the global
> variable. If the program was started with backlight on then the screens
> would start out with their backlight state set accordingly. Then it's
> entirely up to the client to set the state to whatever they wish on a
> per screen basis.
> 
> b) We could have a new state, BACKLIGHT_NOTSET. The s->backlight
> variable would be initialized as this, if it wasn't set with the
> screen_set function then it would inherit the global value at
> draw_screen. Would need to modify the switch statement, perhaps setting
> a local variable, 
> 
> if (s->backlightstate == BACKLIGHT_NOTSET)
> 	switchvar=global_backlightstate 
> else 
> 	switchvar=s->backlightstate, 
> switch (switchvar) { ...
> 
> > Does that make sense?
> > 
> Does to me, how do those options sound to you.
> 
> > On the subject of timeouts, what about specifying the timeout in screen
> > ticks.  Most (all?) other time values in LCDproc are counted in ticks
> > (1/8th of a second)  The timeout should be as well.  This would mean it
> > could be an int. (Even though that really won't make any size difference
> > in most cases, it would be consistent with other parameters.)
> > Does that seem reasonable?
> >
> Not so sure about this one. It doesn't really make sense to have a
> screen viable for one TIME_UNIT. Screens are a visual medium, this would
> seem pointless. I should point out, in case it wasn't obvious from the
> patch, that the s->timeout value is in ticks, it's converted from
> seconds to TIME_UNITS
> 
> s->timeout = number * (TIME_UNIT * 8); // TIME_UNIT is 1/8th of a second
>  
> > > 2) In main.c after the timeout we check the timeout value of the screen,
> > > it's it's expired the screen is removed.
> > > 
> > > 3) I added two new startup parameters to allow you to choose the address
> > > and port to listen on. Very important for security, can limit to
> > > localhost etc.
> > 
> > Very cool.  Good idea.
> > 
> Thanks go to Paul Kelly here in work for that.
> 
> > Just feedback.  Overall, a good patch.  I'll hold on to it until I hear
> > from you.
> > 
> And appreciated.
> 
> > Good job!
> > :v)
> >
> Hurray for me :-)
>  
> Glen
> 
> 
> 
> -----------------------------------------------------------
> To unsubscribe from this list send a blank message to
> lcdproc-unsubscribe@lists.omnipotent.net
> 




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