LCDproc development and user support list

Text archives Help


[Lcdproc] RFC: 0.4.3 key presses


Chronological Thread 
  • From: reenoo AT gmx.de (Rene Wagner)
  • Subject: [Lcdproc] RFC: 0.4.3 key presses
  • Date: Fri Mar 29 16:47:01 2002

> > At the moment the server sends all keys a client has requested
> > to that client.
> >
> > That behaviour doesn't work that well IMHO.
>
> I think there is more that is not right in that area. We have discussed that
> some time ago. Currently in 0.4.3 that code is far from complete. You
> can make a hack around some keystuff thinks, but maybe that brings up
> some new problem...

Indeed ...

>
> We need to have two ways of reserving a key:
> shared: for keys that should be usable by other clients too. Only if a
> client is in front it will receive the keypresses it has opted for.
> exclusively: this key can only be delivered to this client. The client
> can force itself to the front by inceasing priority, and can then also
> use other keys it has reserved shared.
>
> For 0.4.3 we can of course not introduce that yet.

But that's a good concept for 0.5

>
> > Should we make that a config file option?
> >
> > E.g. EnableServerMenu=yes|no
> >
> > Where yes also implies that the keys A, B, C, D are NOT
> > sent to clients?
>
> A, B and C can be send to clients, but only if the menu is not active.
> D is only for the menu, it forces it in front at any time. So if you
> make a fix for this, I think that is what is should do.

Well, no ;) I've thought about the whole thing once again.

A client might want to know when the server menu is activated.
With the 0.4.3 protocol the only way to achieve that is to send
"key D" to the client, right?

So, I'm no longer going to change input.c in that respect.

But, what if someone (like me without lirc ;) has only got
four keys, which are by default mapped to A, B, C, D?

He (or she?) might want to disable the whole input handling
of the server, right?

So the option in the config file should be

DisableServerInputHandling=yes|no
(default no)
yes: all keys are sent to the current screen or the first client
that has requested a key
no: current behaviour with one change:
Even if the current screen wants the key, send it to
the server anyway.
(Otherwise a client (screen_add_key) can disable the server
input handling, which would be a kind of DoS if you use
the server menu to shut down your system.)

> I'm for v0.5 I want to make a [menu] section in the config file. We could
> already start using this new section with an Enabled=no/yes option
> in 0.4.3.

Well, no ;)
See above.

If nobody objects, I'll apply the changes mentioned tonight (or
tomorrow).

Regards,

Rene

--
Experience is what you get when you didn't get what you wanted.





Archive powered by MHonArc 2.6.18.

Top of page