LCDproc development and user support list

Text archives Help


[lcdproc] Suggested changes for client_add_key


Chronological Thread 
  • From: ppokorny AT penguincomputing.com (Philip Pokorny)
  • Subject: [lcdproc] Suggested changes for client_add_key
  • Date: Mon, 30 Apr 2001 09:14:42 -0700

Joris Robijn wrote:
> I haven't looked at your code, but have a sidenote.

I would appreciate the peer review of my code.

> We have discussed
> the topic of key handling for v0.5 a while back. I guess this is one of
> the points we haven't made up our democratic mind completely yet. And
> as v0.5 is a rebuild from scratch, your implementation will probably
> not be used in it.
>
> If you want to look up what we have said about this before, please have
> a look at the archive.

I have read all the archives for March and April. I didn't see any
discussion of key handling in v0.5. Was it further back? Can you
suggest a message title/subject or other keyword I might look for?
Approximate date of the discussion. I did see lots of discussion about
clients reserving keys (including the server.) Unfortunately, I
disagree. Keys are a very precious resource (2, 4 or maybe 6 keys total
on a display) and reserving a key for a client makes it very difficult
to implement a meaningful menu or control system on other clients. When
it comes time to document the design for v0.5, I'll make my case.

> If you meant if for v0.4, can you tell more about if/how it is
> compatible with current clients ?

I did mean for v0.4. That's a very good question.

Until now, client_add_key hasn't been implemented. So no existing
client has used it. Because key handling was only recently added to the
server, most clients don't expect keys, and just ignore the broadcast
key messages they now get. (This is true for the included lcdproc
client anyway). Clients that do want keys will now have to request them
with client_add_key, they will no longer be broadcast to all clients.
If this is an issue, then I can add a command line option to control the
broadcast behavior. I'll make it default to the existing broadcast
behavior, but allow you to disable the broadcasts to save network
messages, and overhead.

*** Can those on the list reply to me with info on how many clients
expect the broadcast key behavior and can't be modified to request keys
with client_add_key?

It's good to review changes like this for backward compatibility.
However, it seems that such questions have not been asked in the past.
Was a similar question/test made when the options to client_set and
screen_set were changed from "name" to "-name", when indent or some
other reformatter was run on the code base in CVS? Neither was a
"fatal" change, but both broke the code I had developed on the v0.4-pre9
code base.

> Anyway, you initative is appreciated. Maybe we'll have some real chunks
> of coding work when the implementation of v0.5 starts.

Thanks, until then, I intend to continue improving v0.4.

The CVS tree is really out of step with the pre9 code. I would like to
strongly suggest that we cut a pre10 or v0.4.1 version of the CVS stuff
so that users won't keep finding the same problems in/with pre9.

> > The idea here is that a client *must* request keys with either
> > client_add_key or screen_add_key. If requested using screen_add_key,
> > then if the current screen has requested a key, that screen/client will
> > be the only one to get that key event. Otherwise, all clients or
> > screens requesting a key will be notified.
> >
> > Perhaps that's wrong. Perhaps if keys were requested using
> > screen_add_key, they should only be sent if the screen is active.
> > client_add_key will cause "left-over" keys to be sent to all requesting
> > clients. That probably makes more sense.
> >
> > Comments?
> > :v)


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