LCDproc development and user support list

Text archives Help


[Lcdproc] screen priority fix?


Chronological Thread 
  • From: mpatnode AT yahoo.com (Mike Patnode)
  • Subject: [Lcdproc] screen priority fix?
  • Date: Fri Mar 29 19:48:02 2002

Here are my thoughts:

1. Rotating screens within a client is a client issue, and should be
controlled by the client.

2. Rotating clients on the LCD is a user issue and should be controlled
by the user. The screen displayed is whatever the current user
selected client desires.

For #1 you need a simple window stacking mechanism. The current
priority flag works fine (with my patch) but you could also implement
this with a screen_set raise/lower command and then use priority for
#2.

For #2, you really want the user to decide which application is
displayed when. This could be done using menus and keys with a
screen/client manager (server built-in for now?) or by some rotation
schedule configuration parameters in the config file. You really don't
want to let the client decide, because clients have no idea what other
clients are running. There are a number of simple and sophisticated
policies you could implement. Which is why I recommend you NOT code
this into the server.

Of course, it takes a bit more work to implement #2 outside of the
server. You need a protocol command to list all client connections and
notify of new ones. I would also manage the input "focus" in this
manner, which also becomes a problem with multiple clients. Think how
irritating it would be to try to press a button on one client, only to
have the server switch clients on you before you completed your button
press. I think you get the picture.

Yes, this client could crash, just like your window manager may crash.
There are numerous ways to deal with that problem.

I'm personally much more concerned about #1. #2 is an ugly problem
with various time/benefit tradeoffs. I don't know how many people
actually run multiple clients on their LCDs, but I think the most
elegant solution is to put the capability in the protocol/server and
the policy in a client. I'm not saying this is the most practical
solution. :-)

mp

--- Joris Robijn
<joris AT robijn.net>
wrote:
> On 27 Mar 2002, at 19:59, Mike Patnode wrote:
>
> > In my application, I used multiple screens and occasionally I want
> to
> > put one on top of another. In theory I can do this by setting the
> > priority, BUT according to the code in main.c, you still have to
> wait
> > for the lower priority screen's duration to expire before your
> higher
> > priority screen is displayed. This doesn't seem to be in the
> spirit
> > of what the documentation says about priority.
> >
> > In anycase, within my application, I want to have absolute control
> > over which screen is being displayed when. When you have multiple
> > apps, you then have a window manager issue (but we don't want to go
> > down that alley :-).
>
> Yes this is a problem. The priority thing is a bit wierd. It seems it
>
> currently first show the screens with the highest priority and then
> lower and lower. That seems nice, but in practise you can't do much
> with the priority as you (Mike) also mentioned. We might need to
> think of an other mechanism. If we want to use things like priority
> in a client we want to know _absolutely_ what will be visible.
>
> Our usual clients do nothing with priority-like things. They don't
> need it, they just want to be rotated. But if you use priority you
> have a client that (seems to me) does not want to be rotated. It's
> either foreground (needs to be shown now!) or background (should not
> be shown usually).
>
> So I have a simple solution in mind:
> make only the priority=0 clients rotate.
> (I thought 0 was default)
>
> How about that ?
>
> Joris
>
> --
> Joris Robijn
> <joris AT robijn.net>
> Home: 053 4311 553
> Mobile: 06 288 41 964
>
> // To understand recursion, we must first understand recursion


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/




Archive powered by MHonArc 2.6.18.

Top of page