[lcdproc] The input part

[Andre Breiler]

On Wed, 28 Mar 2001, Joris Robijn wrote:

> > > Why multicast, though? How about we transmit reserved keypresses to
> > > the client that reserved them, and all other keypresses go to the
> > > client on the screen. Server-reserved keys, of course, get handled by
> > > the server.
> > 
> > Ok, again the example with the light :)
> 
> We could add an option in the config file that specifies a client 
> always receives a copy of keyevent.  All keys or a specified selection 
> of keys.

Hmm, I don't like the idea to configure any client specific thing in the
server.
 
> I think the config file is the best place to determine the complex key 
> sharing things, because there a human needs to think about it :)

No I think the config file is not the best place because the human who
have to think is the programmer (not the admin or user)

> > > > The client which registers the key first (as exclusive) is bound to
> > > > this key. The internal menu client is the first client which grabs a
> > > > key.
> > > 
> > > Right.
> > 
> > So here is no difference between a server reserved key and a client
> > reserved key.
> 
> Well, to scroll through the available screens you might want to give 
> one or two keys to the server.

Hmm, yes/no. This depens how many buttons are available and who is the end
user.
 
> > [killed sample conversation]
> > > > I think here should be priorities which have spacial meanings (e.g.:
> > > > stay in front forever == emergency, stay in front until
> > > > replaced/timeouts, never show me).
> 
> In my original example I meant two different possibilities. Both 
> TOFRONT (single time) and PRIORITY (stay in front). They operate 
> differently.

Yes I know see my comment to you sample.

> > > So:
> > > 
> > > priority is a signed int. If priority is positive, then the higher the
> > > value, the higher the priority. If priority is 0, the screen is never
> > > shown. If priority is -1, it needs to stay on screen until its
> > > priority is changed again.
> 
> The -1 part makes no sense logically (if I'm correct). The -1 could 
> just as well be 10 or some high number. 0=never is good idea.

I agree with the 0 but this is only a definition thing.
And yes you can split the thing in:
  -1 TOFRONT
   0 HIDE
  >0 PRI

See also my comments below to see the difference
between -1 and >0 (it's not the same).

> > Yes mainly. For the -1 case I understand "until its priority is changed
> > again" as the following:
> >  - timeout is reached -> screen pri is reset to old value
> >  - other screen requests this priority -> current screen goes to back,
> >  the timer stops
> >  -> after the other screen lost his pri this screen come to front
> >     again and the timer continues
> >  - screen pri is set by the client
> > So the "newest" screen is always in front.
> 
> OK a compromis, what about: rotate and show only the screens with the 
> highest priority. So when there are only priority 1 screens (default) 
> then they rotate. When one screen with pri=3 appears, this will be 
> displayed only. When a second screen with pri=3 appears, the two 
> screens rotate. When a screen with pri=4 appears, it will become the 
> only visible screen (of course until it drops its priority).

It depends on you idea how to bring screens to front. I would not like the
idea to rotate a menu and the mp3 title screen.
Note also that the client have to know what is the highest used pri
so he knows how to jump to front (I think after a while all non normal
screen will be on the max_pri).

> > Maybe we can use same general "dont show" function which also works for
> > widgets.
> 
> Can you explain what you mean here ? 

I have 3 widgets which are on the same position on the screen (say 3
scrollers). But only the 2nd should be shown, so i disable the 1st and
3rd). This saves me the hassle to delete and recreate them.
(it locks not funny if the second scroller is only 3 chars long and the
second 6 so you see both)

> > Yes, right but I think the mapping should be defined by the user.
> 
> User intelligence rules !

You are right.
If the user doesn't specify any mapping we should use a default mapping. 

> > e.g.:
> > [driver]
> >  name=MtxOrb
> >  keys="ABC"
> >  # this is a lcdd option but it's bound to this driver !
> >  map_key "A" "DISP1_+"
> >  map_key "B" "DISP1_OK"
> >  map_key "C" "CANCEL"
> 
> > Numbers or Strings. I would prefer string because these are easier to
> > remeber :)
> 
> Yes we need to be able to use long names for keystrokes, not just one 
> letter, especially for the keycombos on larger keypads.
> 
> > Ok, I'm happy now :)
> 
> 
> 

-- 
Andre' Breiler                       |   Tel: +44 1737 839532
BBC Internet Services                | Email: andre.breiler@rd.bbc.co.uk 
Kingswood Warren,Tadworth,Surrey,UK  |   URL: http://support.bbc.co.uk/
Mail me.  Don't phone if possible. And use a Subject line.



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